3 ms·
"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 m
by lrobb 15y ago
"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.
- pjscott 15y agoIn case anybody was wondering: other things that Alexander Stepanov wrote, aside from that paragraph, include the C++ STL.
- JohnQPasserby 15y agoI agree with the statement about OOP, but fail to understand what one can proove when one has no axioms.
- Drbble 15y agoThe part about proofs and axioms is completely non-logical. for the past several centuries, proofs have relied on axioms. Euclid introduced axioms (postulates) in order to provide proofs (and precise formulations) for informal statements. So the math part is really more an argument in favor of classes as a sort of axiomitization of computing.
- pavpanchekha 15y agoThe majority of the proofs Euclid produced existed, both as theorem and proof, before his time. Similarly, few recent mathematical advances have started with formalizations and axioms. Calculus wasn't put on a rigorous basis until Lebesgue's time, hundreds of years after Newton and Leibniz. Category theory needed quite some work before it was formalizable. Differential geometry wasn't that rigorous until the twenties or so. Complex analysis was developed using many, many unnecessary assumptions because the formalities weren't there. I'm not picking-and-choosing math fields here; these are just the ones I'm familiar ones. It turns out, axiomatization and theory-building are two separate jobs rarely performed by the same mathematician. Usually, the theory-building makes the mathematician famous, and the axiomatization does not, but this is in many ways a tragedy. In any case, to the outsider of mathematics, it seems that axioms come first. This is false -- axioms come much later, because the work of axiomatizing isn't worth it before the theory proves itself useful. Axioms come first in a formal way, in the same way classes come first in a formal way. But the interesting thing isn't the class -- it's the instance. And in the same way, the axioms aren't interesting -- it's the resulting theories. I found the analogy very insightful.
- empthought 15y agoLakatos's [Proofs and Refutations](http://www.worldcat.org/oclc/258084194 http://www.worldcat.org/oclc/258084194) is good background on the mathematical ideas that Stepanov is alluding to. The short version is that you don't start with axioms, because they are generally uninteresting. You start with interesting theorems and if necessary revise the set of axioms needed to prove those theorems.
- skrebbel 15y agoThe 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. Taking software engineering advice from algorithm geeks is a mistake we've been making for decades over and over again. In my professional life, I've not had a need to engineer a single algorithm. I have had to make plenty fault-tolerant, maintainable and understandable control software, though. The same holds for most, if not all, of my colleagues. Common professional software engineering has nothing to do with sitting in a room on your own figuring out how to best store a dictionary in memory such that it is fast under insertions, removals and lookups.