I’ve found that most no code environments that I’ve tried advocate that they have this capability but in practice it’s still nearly impossible to get what I need because their abstractions aren’t at the right level. Not saying this is impossible just that my personal experiences have made me skeptical of this approach.

I mean, that's pretty much how I program things. I start new web apps with an MVC framework that auto-generates new pages. When I want to do something, I try to use someone else's code as much as possible. If I'm doing a simple, well contained task, someone else has already thought of it and made a library for it. If I need to send an email, I just do something like calling _emailSender.SendEmail(message). Easy peasy.

But processing data is complicated and nothing can completely abstract it away.

I am a lazy programmer in that way. I'd rather autogenerate and use robust libraries as much as possible.

It's not lazy, it's just smart. The less code you write, the better it is.

I think the abstraction layers are important, they should not be leaky. You shouldn't have to go up/down the stack. If you can't build what you want with one tool, then choose another tool.

This is appealing, but I think it's important to recognize just how hard that is.

Abstractions by definition lose information. If that information becomes important, to any user, at any time in the tool's lifespan, somebody has to go and claw the thing open to find it.

Picking an abstraction that never leaks essentially means correctly predicting the entire scope of your problem. There are ways to improve on this, good abstractions try to offer contained 'leaks' that you can enable or access if needed, but that still means predicting the set of possible use cases.

(For a code-adjacent example, Excel is popular as an abstraction on an RDBMS, but it's low-level and even Turing complete. Higher-level tools which don't permit arbitrary data association constantly get scrapped or exported down to Excel because they don't cover every interesting relationship, and Excel data semi-regularly gets pushed back down to databases.)

In school, I learned a lot about the wonders of encapsulation, black boxing, and so on. Within a few years out of school, I realized that one of my most valuable skills was being able to move down the stack when those things inevitably break down. When I do have to go and a library's source, and very occasionally find a bug in it, it often feels like something that couldn't realistically have been anticipated.

Breaking abstraction layers will kill productivity. There's one article that gets posted to HN every year but I can't find it atm. It's about how long it would take to do something from scratch. Taking it into the extreme, including growing your own crops. For computers that would be like mining your own silicon in order to build a CPU, so you can build a PC, to build a boot-loader, a OS, a compiler, a web browser. It will take you years to write that "hello world" program. If you find a bug in a compiler, then that's one day of work gone to debug and path it. Same with libraries, having to write pull requests to the libraries will take time away from whatever you where working on. Leaky abstractions are worse then abstractions. If things are hidden, it will take extra time to dig them out, you could just as well have them all in the open.

Couldn't disagree more. Unless your job is unbelievably trivial, you should use a range of tools and use the best one available for the task at hand.

Lets say you call for pizza, but you need to know how to bake in order to use their self help service, then that's a leaky abstraction. As high levels of abstractions it's OK to only know the name of the different pizzas. And the baker doesn't need a master in chemistry or engineering to operate the oven. We humans are very good at abstracting things and take most abstraction layers for granted, even though the world around us is very complicated.

I fail to see at all how that relates to the question.

If I order a pizza, I’m using a communication channel (phone, internet) to place an order; one tool.

I deeply hope the pizza place is using chefs and an oven to make the pizza; completely different tools.

If I demanded the pizza chef make the dough, slice the ingredients, and bake the pizza with just a stand mixer... that’s just dumb.

Use the appropriate tool for the job and use the right level of abstraction at each step.

Yeah while I think one of the hardest parts if a software developer's job (working at multiple levels of abstraction), that's literally the job. You're translating between the business and the sillicon.

By all means restrict yourself to assembly but yhe rest of us will get more done by using things at convenient levels of abstraction for those specific units.

This is what I get from Pure Data (a graphical audio programming language). Once things get too unweildly, I write a C/C++ extension or Lua script.