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