I think this is pretty well stated: There is no value in code being some kind of model or map of an imaginary world. I don't know why this one is so compelling

I think this is pretty well stated: There is no value in code being some kind of model or map of an imaginary world. I don't know why this one is so compelling for some programmers, but it is extremely popular. If there's a rocket in the game, rest assured that there is a "Rocket" class (Assuming the code is C++) which contains data for exactly one rocket and does rockety stuff. With no regard at all for what data tranformation is really being done, or for the layout of the data. Or for that matter, without the basic understanding that where there's one thing, there's probably more than one. Though there are a lot of performance penalties for this kind of design, the most significant one is that it doesn't scale. At all. One hundred rockets costs one hundred times as much as one rocket. And it's extremely likely it costs even more than that! Even to a non-programmer, that shouldn't make any sense. Economy of scale. If you have more of something, it should get cheaper, not more expensive. And the way to do that is to design the data properly and group things by similar transformations. It's from this blog post called "3 Big Lies": http://cellperformance.beyond3d.com/articles/2008/03/three-big-lies.html http://cellperformance.beyond3d.com/articles/2008/03/three-b... When I read it I thought: "That's a pretty common understanding isn't it? Not really a big lie." Then a few days ago I saw this: http://www.quora.com/What-is-the-best-mental-model-for-object-oriented-programming http://www.quora.com/What-is-the-best-mental-model-for-objec... Facepalm. Note the "M.S. degree in computer science." WTF? To me that describes exactly how not to think about OOP. I have Stepanov's book. It's only 240 pages, but 50% math. I haven't been able to get through it yet.