lies about OOP

[H. S. Lahman]

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
hsl at pathfindermda.com
Pathfinder Solutions  -- Put MDA to Work
http://www.pathfindermda.com
blog (under constr): http://pathfinderpeople.blogs.com/hslahman
(888)-OOA-PATH