lies about OOP
H. S. Lahman
h.lahman at verizon.net
Wed Dec 15 20:10:38 CET 2004
Responding to Beliavsky...
> Les Hatton "Does OO sync with the way we think?", IEEE Software, 15(3),
> "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
> 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
[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
hsl at pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
blog (under constr): http://pathfinderpeople.blogs.com/hslahman
More information about the Python-list