I like this description. It is similar to the concept of "no-code" where the code is definitely there, but it is abstracted away to the point that the user theoretically doesn't ever notice it.
Good observation. Code is also a Jenga tower of abstractions from High level language (Python) -> Low level language (Assembly) -> CPU microcode. No code is just yet another layer on top. The higher up you go, the more difficult it can be to debug issues, and the more locked in you will be in the infrastructure. I like to stay somewhere in the middle. Not too low such that I am wasting a bunch of time with implementation details, but not too high where I don't understand enough about the technology to fix issues. The industry, as an aggregate, is steadily and relentlessly moving up the abstraction tower.
This also reminds me of something C programmers have all witnessed at least once: inline assembly.
Outside of bare metal programming, pretty much anything done with inline assembly can already have been done with straight-up C. BUT by using inline assembly, the coder has (nearly) direct control over what the compiler spits out.
And the reason I say "nearly," before someone corrects me, is that there are multiple ways to express the same operations in assembly.
For example, ADD AX,BX can be compiled as C303h or D801h... the end result is exactly the same, but the binary code is not at all the same. Incidentally, this is one of a few methods forensic agents heuristically determine what compiler was used for a given malware sample.
It's abstraction all the way down. Even at the Assembly Language level.
That is an interesting comparison. I think it highlights that engineers may need to constrain the design a few levels of abstraction lower than where they typically operate at any given time. I think performance constraints is a key motivating factor for when we need to peel back the layers of abstraction and tweak something under the hood(s).
I think another analogy is like building a skyscraper. The construction worker needs to worry about the floor below him and the floor he is working on. Everything below him is an implementation detail from his perspective.
If N is the cutting edge level of abstraction, N+1 is what research is doing, N-1 is where I like to operate at while I wait for N to stabilize.
Take a stack of AWS services for example. AWS comprehend medical is an abstraction built on a bunch of NLP building blocks. AWS health lake is an abstraction on top of AWS comprehend medical. At this point I don't care about the NLP underlying AWS comprehend but I don't want to use AWS health lake until it has a chance to stabilize and another abstraction is built on top of it.
