The author highlights an interesting point. There are a couple variables in action:

A- The difficulty to publish the tool

B- The difficulty to create the tool

C- The usefulness of the tool to others

D- The social reward for publishing the tool

E- The negative incentive of adding a dependency

Difficulty to find a canned solution goes up with A (because someone needs to create it) and B (someone needs to figure out how to publish it), but, the more useful it is to the community (C), the easier it gets to find it, because people will tell you.

If A and B are substantially different, if A is much higher than B, people will tend to write their own and forget about it. If B is lower, there will be fewer solutions to your problem. If A and B are low, and the social reward (C) for A is higher than the price of depending on something else (E), you'll have a leftpad situation. A lot of NPM is made of packages with high C and D and low E.

In the case of Emacs Lisp, A used to be high, but now is low, B (once you climb the learning curve) is low, C, D, and E aren't high either way. This can lead to a scenario where you build the tool before you even look if there is a tool that does it (unlike it is with VSCode, and with Eclipse before it - both have a high B).

I see a thesis someone younger than me will want to bring out to this world.

That’d be awesome. What is the current tallest ship that could damage a bridge? You can count on someone eventually doing that.

QBasic is already a couple levels of abstraction above GWBasic and other 8-bit ROM-based BASIC interpreters (BBC excepted).