Unless efficiency regulations take hold for protection against excess emissions, chip shortages, etc.

Seems unlikely, but at some point it might make sense. Of course if the resources (electricity, silicon, etc.) required by developers to implement such efficient code exceeds the estimated savings, then doing it would actually be worse. But think about all the build scripts constantly being invoked, for example. The energy used to develop them must be extremely overshadowed by the energy to execute them.

Yes, I posted this as part of a comment some time ago:

> Software used by a certain minimum number of users, and software used in certain fields (like medicine, transport, and finance) need to be subjected by regulatory agencies to certain objective (hence automated?) tests to ensure they meet some minimum reliability, usability, security, and performance requirements. In this regime, small-time SaaS software, or hobby projects, would not need any regulation, but flagship software products of Facebook, Google, SAP, Oracle, Tesla, etc would need it.

I program on old hardware in order to keep me in check.

Oh yes. I've seen that in my day job where a current project is a custom ASIC with a luxurious 1 megabyte of RAM. At the beginning of the project we were all optimistic, and people spent RAM with wanton abandon. But kilobyte by kilobyte, allocation by allocation, function by function, we started running into those limits for both code and data.

When you're in a custom ASIC though, there is no "just plug more RAM in", so I've had to jump through hoops to eliminate excessive allocations and push to other parts of the system the computations that require significant scratch space. But it all takes time and effort. The last two major refactors that restored our buffer took 6 months to complete. They did nothing to improve system functionality, they just bought us the space to implement new features.

That's a lot of developer time to burn for something that will help in the future, but isn't delivering value now.

And that's undoubtedly why we're always in a RAM crunch. We value tools for the speed in development and flexibility, but do not care about how much storage or power they waste. Otherwise JavaScript wouldn't be running the web.

I work on a <500kB RAM embedded project currently (and similar constraints in previous ones), and I can pretty much mirror what you said. The current project is in the planning/early development phase, and it's like everybody forgot the multi-month entire-app refactors we had to do twice to save some small fraction of total RAM in the previous project. But when you're pushing for another release with another too-tight release schedule, suddenly RAM savings are not an immediate but a future problem.

For us the day will come where we atone for our sins and have to again put off feature updates for months of RAM optimization. But in the PC/server/mobile space, that day gets pushed off whenever people move on to better hardware. So why not continue to bloat your applications, really? There's little incentive to do otherwise. If clunky abstractions make your developers ever so slightly happier, what's the reason not to embrace them?

I do consider RAM use when writing programs. Unfortunately, sometimes it is difficult, but sometimes it can be done. (Further improvements also may be made (sometimes without making the program too complicated); they are not necessarily perfectly efficient as they are.)

I think about consumption quite often, because nobody likes it when a memory hog mobile app pushes a more important app out of memory (or if the important app is the memory hog, also leading it to get pushed out). Also because it's increasingly common for users to not be carrying the latest model phone and thus be strapped for RAM.

My work isn't the best out there in that regard, but by simply making the more obvious optimizations as you go you're already doing better than the majority, and I'm confident that any effort beyond that puts you in the top 10%.