I recently read the Three Big Lies blog post and I am having a hard time justifying the second lie, which is quoted here:
(LIE #2) CODE SHOULD BE DESIGNED AROUND A MODEL OF THE WORLD
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.
Here are my problems with this lie in particular.
There is value in code being a model / map of an imaginary world as modeling the imaginary world helps (at least me, personally) visualize and organize the code.
Having a "Rocket" class is, to me, a perfectly valid choice for a class. Perhaps "Rockets" could be broken down into types of Rockets like AGM-114 Hellfire, etc. which would contain payload strength, max velocity, max turning radius, targeting type and so forth, but still every rocket fired would need to have a position and a velocity.
Of course having 100 Rockets costs more than 1 Rocket. If there are 100 Rockets on screen there must be 100 different computations to update their position. The second paragraph sounds like it is making the claim that if there are 100 Rockets, it should cost less than 100 computations to update the state?
My problem here is that the author presents a "flawed" programming model but doesn't present a way to "correct" it. Perhaps I'm tripping up on the analogy of the Rocket class, but I would really like to understand the reasoning behind this lie. What is the alternative?