But this ignores, as in my example, who pays for the complexity.
I want a bagel. Is it simplest for me to start tilling the land and looking for wild wheat relatives to breed, or to drive my incredibly complex car built in centuries of industrialization to the corner store and buy (using money, one of the most complex concepts we've developed!) a bagel, bring it home in a plastic (!!!) bag, and stick it in the toaster?
If I should, during my lifetime, succeed in completing a bagel with the former, I have reasonable confidence it can't be reduced further without changing the output.
But I disagree that it's the simplest way /for me/ to get breakfast.
It's a requirement for making a bagel… the question is whether I do it, or someone else. Part of the irreducible complexity of bagelness is the production process of wheat.
At the risk of beating an analogy to death... this is exactly the mental model that gets us leftpad. Outsourcing of complexity is /not/ elimination of complexity. I may go my whole life without having to debug the lower-level steps in the process that put a bagel on my table, and if that's the case then treating dependencies as zero-cost makes sense -- but also, I may not be so lucky. When the supply chain collapses, I have to go without my bagel, or dig deeper. Either of which may be fine, depending on my requirements -- but the exported complexity is now present and impacting my experience.
There's nothing wrong with leftpad as a library concept. The problem was that it got hacked, not that it does something useless that everyone should write on their own.
leftpad was incorporated into ECMAScript in 2017 for a reason.
> Outsourcing of complexity is /not/ elimination of complexity.
This is technically true but functionally false. You're literally arguing against the concept of abstraction layers, while writing text into a form built on top of hundreds of them.
There are two thoughts I have regarding this:
1) Leaky Abstractions seems like what you're trying to point out, and accurately so [0] but,
2) you can still rely on even leaky abstractions. You must, in fact, to function in this world. In some ways the quote, "In preparing for battle I have always found that plans are useless but planning is indispensable" [1] applies to abstraction as well.
It is a good way to consider the extremes of the problem-space, which often is a good way to come at a problem.
But a more practical, analogous situation might be: should I buy a nice, warm bagel at the local bagel shop, or should buy it a store and toast it myself? In that trade-off I can take for granted that I'm getting a bagel, but the delivery mechanism, the quality, the integration options, the cost, are things I need to consider.
The decision will depend upon your requirements. If you are organizing an event, maybe I get some bulk catering from the bagel-shop. If you want to use your aunt's bespoke berry jam, maybe you use the store-bought bagel so you easily can use your home spreads.
Identifying the optimal simplicity can be a hard problem, but that shouldn't preclude narrowing down choices with some rough heuristics so that you don't need to investigate the combinatorial explosion of all possibilities, or rethink the system dependencies back to: "first we have a big bang."
I want a bagel. Is it simplest for me to start tilling the land and looking for wild wheat relatives to breed, or to drive my incredibly complex car built in centuries of industrialization to the corner store and buy (using money, one of the most complex concepts we've developed!) a bagel, bring it home in a plastic (!!!) bag, and stick it in the toaster?
If I should, during my lifetime, succeed in completing a bagel with the former, I have reasonable confidence it can't be reduced further without changing the output.
But I disagree that it's the simplest way /for me/ to get breakfast.