>Fundamentally, many inefficiencies were justified for developer productivity, and I'm not sure that makes sense anymore
Having lived through this period, I would disagree, quite the opposite we tended to develop in C and assembly specifically for runtime efficiency because we had to.
For developer productivity you could opt for Lisp or SmallTalk or some such, which ran much slower until high quality compilers for these became available, and even then your target machine might only have a C compiler.
I read GP's comment differently, that we ended up where we are today (bloated languages, IDEs and runtimes) due to chasing developer productivity at all costs.
Now, developer productivity is becoming less important as developers are factored out entirely.
This was my intended meaning -- the clearest advocacy of this was from DHH about Ruby on Rails, although he's changed his mind about big questions lately and suspect he no longer endorses that set of trade-offs (I don't either, _sort of_ -- I think developer productivity means having simple ways to enable large-scale testing and oversight while minimizing context switching costs, although I think we are all figuring out what that means in practice).
Having lived through this period, I would disagree, quite the opposite we tended to develop in C and assembly specifically for runtime efficiency because we had to.
For developer productivity you could opt for Lisp or SmallTalk or some such, which ran much slower until high quality compilers for these became available, and even then your target machine might only have a C compiler.
Now, developer productivity is becoming less important as developers are factored out entirely.