I'd go further and say that readability and/or ease of use _often_ trumps efficiency. I/O tends to be the bottleneck at least as often as CPU, apart from anything else.

I agree with the point about writing in assembly language. This rant is basically arguing for speculatively micro-optimising _every line of code_ by choosing a supposedly faster language.

I'm the author of the original post. The article isn't about optimizing every line of code, it's about not being lazy and choosing a language that you might have to do a little more work in for a massive decrease in bloat and execution time. One tool isn't always the right one for every problem. Don't use a hammer to screw in a screw. Sure, the screw will go in, but with just a little more effort (using a screwdriver) the task will be done much better. It's about wasting money & resources because a programmer doesn't want to write a little extra code to manage memory or watch return codes.

I'll put it another way. Most code isn't performance-critical. If you choose to write everything in, say, assembler, most of it will give you little or no gain. Assembler's harder to write than Java, so every line is costing you money, whether it actually runs faster or not. The _effect_ is the same as speculatively optimising every line: substantial cost, uncertain benefit, potential to introduce bugs, etc etc.

The thing about efficiency is that efficiency from one person's perspective is not the same as efficiency from another's. It may _run_ more efficiently, but maintenance efficiency decreases and extendability efficiency increases. So, you've traded a marginal short-term gain for long-term decreases in efficiency.

C and assembly can be written very legibly.