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.
> You're literally arguing against the concept of abstraction layers, while writing text into a form built on top of hundreds of them.
Sorry, I see how what I said could have been interpreted this way. That's /definitely/ not my intent, and I'd like to clarify.
I am arguing that abstraction layers have cost, and (independently) that third-party dependencies have cost. (Abstraction layers are a great tool for isolating third-party dependencies, so they tend to go together, but they're independent things here.)
Also, lack of abstraction layers has cost, and building everything in house has cost.
These costs need to be traded. In some cases, leaning on external dependencies is the right choice. In other cases, it's not.
If complexity (opposite of simplicity) under an abstraction layer is neglected (estimated at zero), using simplicity as a guideline for making engineering decisions will lead you to the wrong decision some of the time. Similarly, if complexity under an abstraction layer is treated as just as non-simple as complexity above the abstraction layer, using simplicity as a guideline will lead you to the wrong decision some of the time.
Therefore, "the simplest thing that can possibly work" is too naïve a metric to be used for making decisions (as opposed to just for justifying decisions you already want to make). It takes a more nuanced discussion of types of simplicity, and whether complexity is being eliminated or just hidden, and if it's hidden how likely it is to stay hidden, to make this rule useful.
For the record: I buy my bagels from a store. When the roads are closed due to snow, I don't have a bagel. That's the right decision for me, unsurprisingly, for this problem.
Finally, I'll argue that there /was/ a problem with leftpad as a library concept. There is an inherent minimum complexity to a dynamically linked external dependency. The reduction in complexity of the implementation must be at least as large as this cost. One can argue about where the line lies (and it depends on the maturity of your ecosystem, etc), but I'd take the stance that leftpad is too simple to implement directly for pushing it to an external dependency to ever e the right choice.
If your point is, "abstractions don't have zero cost" point taken. But if your point is, "abstractions have meaningful cost", I'd rephrase that as, "The better an abstraction is, the closer to zero its cost becomes."
Irrelevant point of order: leftpad didn't get hacked, the owner took it down to prove a point and broke every package that depended on it as npm allowed packages to just be completely removed by the authors at that time.
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."
