>> In the bigger picture of things these abstractions have costs. They're not free despite the C++ propaganda machine telling us otherwise. It's important to know what those costs are in order to make effective decisions about whether to include them in your project.
Based on years of writing all kinds of software I can only disagree with this. Even in games there's such a tiny amount of code that would really benefit from going all the way down to the bare metal to avoid some constant-factor overhead of higher-level abstractions, that it rarely makes any sense to even think about these things before you have working code you can run through a profiler. Almost always, spending your time and effort finding and using higher-level abstractions pays off much more than tinkering with your ghetto-hashmap implementation 'to make it faster'.
>> It may not be a style of programming that agrees with you but it's one that has a growing number of proponents from Casey to Mike Acton, Jonathan Blow, and others. It's not a new idea either... but it certainly distinguishes itself as a reaction to the normative notion of programming by abstraction. It's a philosophy that proscribes programming by mechanical sympathy; using machines to manipulate data to get the results you desire.
Philosophically, that's all nice and dandy. Practically speaking, it doesn't make much sense though, except for educational purposes (and even then, only up to the point of showing how things work, then moving on and settling on a proven, battle-tested version of the same thing that you don't need to maintain and debug yourself. At least that's my opinion...