Responding to Beliavsky...
Les Hatton "Does OO sync with the way we think?", IEEE Software, 15(3), p.46-54 "This paper argues from real data that OO based systems written in C++ appear to increase the cost of fixing defects significantly when compared with systems written in either C or Pascal. It goes on to suggest that at least some aspects of OO, for example inheritance, do not fit well with the way we make mistakes."
Try and find and experienced OO developer who would advocate that large, complex generalizations are a good practice. You can write lousy programs in any paradigm. The likelihood increases when you use the most technically deficient of all the OOPLs. (If those developers had used Smalltalk, I'll bet their defect rates would have been substantially lower even if they weren't very good OO developers.)
His comments under "invited feedback" are amusing and confirm my impression that OOP is partly (but perhaps not entirely) hype:
"I should not that this paper because it criticised OO had an unusually turbulent review period. 2 reviewers said they would cut their throats if it was published and 3 said the opposite. The paper was only published if the OO community could publish a rebuttal. I found this very amusing as my paper contains significant data. The rebuttal had none. This sort of thing is normal in software engineering which mostly operates in a measurement-free zone."
Part of that criticism was that his experiments were uncontrolled. There was no attempt made to ensure that the programs under either paradigm were of high quality for the paradigm. There were other experimental issues, such as the scale of the programs, that make the data anecdotal at best and a stacked deck at worst.
What papers have scientific evidence for OOP?
I don't know of any large, controlled studies but there must be some buried in PhD theses somewhere. There is substantial anecdotal evidence to the contrary, though. For example, where I worked before retiring we ran a number of experiments to determine whether we should adopt OO development. One experiment was for exactly the same MLOC application (originally written in BLISS) that was rewritten in C and then in C++ using good OOA/D. The same developers, who were domain experts, were used. Both C and C++ were new languages for most of them. [While they were proficient at procedural development, OO was OJT. However, extensive OOA/D training was provided.]
The initial development times were about the same, probably due to the OO learning curve. The released defect rates for the OO version were about 1/2 those of the C version. The big difference, though, was in maintenance time, which was nearly an order of magnitude less for the OO version. One of the first major rounds we estimated to take 6 engineering months using the established techniques we used for procedural development (which were accurate to -5/+15%). Three people turned the changes on the OO version in a week -- to the amazement of everyone, including ourselves. Besides hard comparative data on time spent, the permanent maintenance staff for the application dropped from 8 full-timers for the C version to one guy half-time for the OO version.
While this is anecdotal (among other things, it is dependent on the OOA/D methodology employed), it was done with a whole lot more control than Hatton's experiments. [We were a very process-oriented shop that insisted on hard experimental data before instituting any process change. We also collected data religiously. Not a lot of shops can tell you immediately how much time the average developer spends in meetings or the average time it takes to diagnose a memory over-write problem. B-)]
Paul Graham's skeptical comments on OOP are at http://www.paulgraham.com/noop.html .
If OOP is so beneficial for large projects, why are the Linux kernel, the interpreters for Perl and Python, and most compilers I know written in C rather than C++?
The main reason is performance. All those examples are very performance sensitive. C will be ~twice as fast as C++ and C++'s design compromises were made specifically to enhance its performance! In addition, physical coupling is a much bigger problem in the OOPLs than in procedural languages, so build time can become an issue for larger applications.
[The OO translation-based approaches that do full code generation from OOA models usually target straight C as the implementation language for performance sensitive situations in R-T/E. (Also, translation code generators can usually generate OOPL source code faster than it can be compiled, but that is usually not true for C.)]
************* There is nothing wrong with me that could not be cured by a capful of Drano.
H. S. Lahman [EMAIL PROTECTED] Pathfinder Solutions -- Put MDA to Work http://www.pathfindermda.com blog (under constr): http://pathfinderpeople.blogs.com/hslahman (888)-OOA-PATH
-- http://mail.python.org/mailman/listinfo/python-list
