[strangetortoise]

Not sure if you're familiar with Mike Acton (as mentioned in the article). One of his key points of focus is data-oriented design, and that when designing software, ignoring the architectural realities of the hardware is ignoring one of your responsibilities as an engineer to deliver performant software.

Now, it's possible to argue that writing performant software is not important. The prevailing modern sentiment definitely seems to be "The compiler / interpreter takes care of that". But given his track record of delivering high performant running software, and the trend in computing towards sluggishness, I'm trending more and more towards his camp, than the "don't micro-manage the runtime" camp (which is starting to feel more and more like a thinly-veiled "I don't want to have to think about it").

Edit: A summary post he wrote as a source https://cellperformance.beyond3d.com/articles/2008/03/three-...

[dtdynasty]

I don't think it's thinly veiled at all. Some people might be deluding themselves into thinking they aren't losing something by abstracting away the intricacies of the runtime but I imagine most are actively thinking they are okay with this tradeoff. Instead they are allowed to focus more on the domain problems and let their users tell them when it gets to be too slow. Whether it's the right trade off probably depends on what their goals are.

[feoren]

> Now, it's possible to argue that writing performant software is not important.

The quote I'm arguing against is "I can articulate how all the data I use is laid out in memory." Indeed, writing performant code is not important, most of the time. It is critically important a small amount of the time (actual percentages heavily dependent on the type of software), and yes, in those times, understanding the architectural realities of the hardware is somewhere on the list of things you need to understand to do so, just below a solid understanding of complexity analysis, a wide knowledge of useful data structures, proper design of queries and use of indexes (if relevant), etc. A good software engineer does not say "I always know exactly how all my data is laid out in memory", they say "I know when and how to care about that, and the rest of the times I ignore it." Just like they do with many, many other concerns. Anything else is just premature optimization. The most important problem solving skill by far is knowing what you can safely ignore.