I find OOP technically unsound. It attempts to decompose the world in terms of interfaces that vary on a single type. To deal with the real problems you need multisorted algebras - families of interfaces that span multiple types. I find OOP philosophically unsound. It claims that everything is an object. Even if it is true it is not very interesting - saying that everything is an object is saying nothing at all. I find OOP methodologically wrong. It starts with classes. It is as if mathematicians would start with axioms. You do not start with axioms - you start with proofs. Only when you have found a bunch of related proofs, can you come up with axioms. You end with axioms. The same thing is true in programming: you have to start with interesting algorithms. Only when you understand them well, can you come up with an interface that will let them work.
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.
I've seen that quote in a number of threads criticizing OO, and I don't think I fully understand it.
Could someone explain what the practical edge of his argument is here? Or is it just a theoreticians complaint, taking a (perhaps simplistic) definition of OO and declaring it unsuitable?
Everyone agrees in theory that proofs and generic code are great, but in practice it seems that most programs (at least, the ones that I've seen) aren't conglomerations of mathematically reasonable abstractions, but fairly monomorphic domain-specific actions that would benefit more from what OO offers than from proofs and generic regular types.
This is especially true when you step outside of the code and look at the problems being solved: if you don't already have a proof of concept, and even before that, if you don't have a sound problem to solve, you will not be able to produce intelligible proofs and axioms will be difficult if not impossible.
Mechanically, I'll prove to myself something works the way I want or need to in a REPL and then implement the axiom from that... which is sorta in the right direction :)
Only starting with algorithms bugs me. A focus on data structures seems much more natural. (On the other hand, data structures are intimately tied to algorithms. What would a red-black tree be without insert, delete, look-up?)
I find OOP technically unsound. It attempts to decompose the world in terms of interfaces that vary on a single type. To deal with the real problems you need multisorted algebras - families of interfaces that span multiple types. I find OOP philosophically unsound. It claims that everything is an object. Even if it is true it is not very interesting - saying that everything is an object is saying nothing at all. I find OOP methodologically wrong. It starts with classes. It is as if mathematicians would start with axioms. You do not start with axioms - you start with proofs. Only when you have found a bunch of related proofs, can you come up with axioms. You end with axioms. The same thing is true in programming: you have to start with interesting algorithms. Only when you understand them well, can you come up with an interface that will let them work.
-Alexander Stepanov
edit : interview here http://www.stlport.org/resources/StepanovUSA.html