[smsm42]

The thing that is wrong with OO in general is that is is not a silver bullet. I disagree that OO is useful only for simulation - I've done virtually no simulation work and I've found using OO useful in many contexts. Maybe if I used functional style or hypertyped dynamic agile mumbojumbo style or whatever is the fashion de jour - I would save some time, but OO worked fine for me and allowed me to do what I needed efficiently. Would I use it everywhere? Definitely no. Does it have a prominent place in my tool belt? Definitely yes. I reject the false dichotomy of "OO is Da Thing, should be used for everything" and "OO is useless except in very narrow niche". My experience is that OO is very useful for reducing complexity of projects of considerable size with high reuse potential and defined, though not completely static interfaces.

[gruseom]

Of course you find OO useful in many contexts, since you know it and like it. But the argument is not that OO is useless. The argument is that it provides no compelling advantage and that it comes with costs that people don't count because -- owing to familiarity -- they don't see them. It would be interesting to know how much of the "considerable size" of the systems you refer to is owed to the paradigm to begin with. The cure is often the disease.

[smsm42]

No compelling advantage over what? Over random bag of spaghetti code? You bet it does. Over some other methodology? Bring up the example and we'd see. I am sure you can replace OO with something else - so what? I explicitly said OO is not the panacea - you like something else, you do it. So what's your proposal?

Considerable size of the system is because of considerable complexity of the task at hand. I don't see how you can write 1000-page book of requirements into 2 screens of code. And if you need the system that is able to be customized to satisfy different books with minimal change - you need more complex code.