That linked blog post was one of the most enjoyable things I've read in a while.
Some things I didn't see anybody mention yet (sorry if you did):
The familiarity factor tends to trump resource efficiency, and even ease of use, quite a lot when companies choose what to build on top of (libraries, frameworks, platforms, etc) or with (tool chains, programming languages, etc).
In the quest for abstraction, modularity, and whatnot, we've made quite a lot of tools that are easier to use than they are efficient to run.
Abstraction tools are just so much better nowadays, we get lulled into thinking all of them are as good as the best ones. Optimizing compilers can, in a lot of cases, out perform assembly programmers; garbage collectors add negligible penalty in a lot of use cases (contrived examples, don't eat me). But, just because they're not a problem a lot of the time, doesn't mean they can't screw you over some of the time. We tend to forget that more and more as tools become better and better.
On a related note, one of my college teaches shared a quote with us that went something like this:
The only problem that can't be solved with a layer of indirection is too many layers of I direction.
On the flip side though, I do believe there are new people entering the field who are very interested in efficiency, and the screeching halt of transistor miniaturization will certainly force everybody to optimize more.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
That linked blog post was one of the most enjoyable things I've read in a while.
Some things I didn't see anybody mention yet (sorry if you did):
The familiarity factor tends to trump resource efficiency, and even ease of use, quite a lot when companies choose what to build on top of (libraries, frameworks, platforms, etc) or with (tool chains, programming languages, etc).
In the quest for abstraction, modularity, and whatnot, we've made quite a lot of tools that are easier to use than they are efficient to run.
Abstraction tools are just so much better nowadays, we get lulled into thinking all of them are as good as the best ones. Optimizing compilers can, in a lot of cases, out perform assembly programmers; garbage collectors add negligible penalty in a lot of use cases (contrived examples, don't eat me). But, just because they're not a problem a lot of the time, doesn't mean they can't screw you over some of the time. We tend to forget that more and more as tools become better and better.
On a related note, one of my college teaches shared a quote with us that went something like this:
On the flip side though, I do believe there are new people entering the field who are very interested in efficiency, and the screeching halt of transistor miniaturization will certainly force everybody to optimize more.