And is the juice even worth the squeeze? We're using astronomically more computing power to enable developer conveniences that are (however you define or measu

And is the juice even worth the squeeze? We're using astronomically more computing power to enable developer conveniences that are (however you define or measure it) not astronomical improvements. I've heard the developer time argument since I started coding in the 90s and have been skeptical of it just as long. I think it's a post hoc justification for practices we already do. Software development is partly fad and fashion driven, is passed on by imitation, and code is often easier to write than to read. Almost all of the effort has gone towards expanding the numerator in that write/read ratio, and there's neither sufficient incentive to making tools to cut out layers nor widely accepted practices for how that works comparable to those we have for adding layers. All this adds up to a strong entropic gradient toward software inefficiency, independent of whether or not it actually makes developers more efficient, but leading to a worse experience for users either way. Bucking the trend to make software more efficient can also improve developer time, as Linus Torvalds' argument why it was worthwhile to make git fast. I contend the justification that producing bloated software saves developer time is only true when selectively applied. My axe to grind here is I question whether we wouldn't have similar improvements if we'd put the similar effort into making better tooling, education, and API design for native (and/or) compiled software ecosystems that we do towards things-that-we-use-because-they-are-there (whether or not they're the best tool for the job in a broader sense).