If you ask developers to write efficient code and give them the means to do it, they will write efficient code.
But unless they work in embedded software, this is rarely a priority. In fact, this tends to be actively discouraged : in the good shops, reliability, robustness and security is the goal, in bad shops, that's bullet-point features and meeting unrealistic deadlines.
To get an idea of how optimization is poorly regarded, look no further than the infamous Heartbleed exploit of OpenSSL. One of the contributing factor for this bug was that the team used a custom memory allocator for performance reasons. After the bug was discovered, the team was actually blamed for it more than anything else that lead to the bug. And FYI, it was a real performance improvement, at least on some platforms.
You seem to be under the impression that writing efficient code is at odds with writing reliable or robust code. Efficient does not mean unsafe. Efficient code does not have to shoot-from-the-hip. Efficiency means that the task is completed with the minimum wasted effort. To assume that you cannot have relieable code that is also efficient is absurd.
If reliability is the top priority for your project, it just means you factor that in to your optimizations. It doesn't mean you just ignore efficiency and write any old shit, as seems to be the custom today.
Your OpenSSL example seems to suggest the Heartbleed exploit was a result of developers daring to write performant code, and not that they simply wrote buggy or insecure code, performant or not.
I feel the problem here is what I imagine as this formula:
reliability * efficiency = developer skill
I.e. for a given level of reliability, you need more skilled[0] developers to be able to write efficient code. And I'm not thinking about premature optimizations here - just that the code an experienced developer will write the first time around will be efficient enough.
So in short, if you aim for certain level of reliability and employ cheap/unskilled developers, efficiency will suffer. And as long as companies don't really care about performance, developers will not gain the necessary experience to write efficient code with just-in-time optimizations.
--
[0] - for "skilled" meaning probably mostly some knowledge and experience in writing fast code; it's probably not the experience you'll get when all coding you've ever done is for the web.
I think he's referring to the pressures to produce working solutions. And there's a whole laundry list of attributes people attach to that process. And everyone has the opinion that they're ideals represent the best/most important subset of all the possibilities and/or that you should just meet them all or go work at McDonalds.
You can certainly write efficient code, that's reliable and robust and secure given the time and resources to do so. It usually comes down to money, and how no matter how efficient or high minded you are, crafting the optimal solution takes more time and resources. IE more money. If you can sell users and clients on the extra costs, great. Otherwise you need to figure out what you can do, with the time and resources you have, that will sufficiently satisfy your customers.
And yeah, the problem is with the gobs of resources available on modern computers writing efficient code matters less because most users aren't going to care if their music player is using 1% of the CPU or 10% of the CPU.
Of course I say that with the annoying exception I've experienced where the custom MP3 player in GTA V requires a relatively huge amount of resources and will easily reduce performance by 10-20FPS even on an overclocked i5.
>You seem to be under the impression that writing efficient code is at odds with writing reliable or robust code.
For a given amount of resources invested it is. From a business perspective this includes not just the time a developer spends on a given piece of code, but how good a developer one is willing to pay to work on the code. Perhaps those making the business decisions overestimate the cost of writing more efficient code and underestimate the costs of not writing more efficient code, but they there is a cost that will be taken into account.
>To assume that you cannot have relieable code that is also efficient is absurd.
Of course you can, but often it takes more time (or more expensive developers) than inefficient code, and the people paying the bill don't necessarily benefit from the efficiency.
I want to believe this. Evidence shows that people tend to grow their problem so that they are attempting to solve the problem of writing software with every other developer. Hence the rise of frameworks.
Sometimes, people get a knock out and do a good job. Bootstrap was seen that way for a while. (I've not heard much of it lately, so assuming it has waned in popularity?) By and large though, we all have different requirements for development. And none of them are shared by the customers/users of our software.
There's also this weird collectivist thing going on with software development, where not using frameworks is looked down upon. Or rather, frameworks are considered a best practice without taking project requirements into consideration. Sometimes, said developers then blog about how they used a nailgun to swat a fly, and the hype cycle continues.
Example: everybody wants their web pages to be smaller but nobody wants to part with massive JS frameworks for sites that everyone are using, even if their site is mostly text. Instead, endless amounts of blogging and engineering time are dumped into things like minification, compiler tech, and other esoterica to solve a problem created by developers. This is incidental complexity, and it lays waste to software systems.
In short, the zeitgeist selects what it wants to hear.
But unless they work in embedded software, this is rarely a priority. In fact, this tends to be actively discouraged : in the good shops, reliability, robustness and security is the goal, in bad shops, that's bullet-point features and meeting unrealistic deadlines.
To get an idea of how optimization is poorly regarded, look no further than the infamous Heartbleed exploit of OpenSSL. One of the contributing factor for this bug was that the team used a custom memory allocator for performance reasons. After the bug was discovered, the team was actually blamed for it more than anything else that lead to the bug. And FYI, it was a real performance improvement, at least on some platforms.