NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/object/5079

Text File | 1993-01-28 | 5.4 KB | 120 lines

Newsgroups: comp.object
Path: sparky!uunet!ukma!gatech!news.ans.net!cmcl2!panix!fhd
From: [e-mail] (Frank Deutschmann)
Subject: Re: Maintenance and OO -- the problems of C++
Message-ID: <[e-mail]>
Organization: PANIX Public Access Unix, NYC
References: <[e-mail]> <harvey.728148390@regina> <[e-mail]>
Date: Thu, 28 Jan 1993 04:22:59 GMT
Lines: 109

In <[e-mail]> [e-mail] (Bjarne Stroustrup) writes:
>Let's try to keep discussions of programming and programming languages
>technical.

OK, let's go!

In <harvey.728148390@regina> [e-mail] (Harvey Reed) writes:
>[e-mail] (Paul Keddie) writes:

>>1) Are 00 programs harder to maintain than normal functional programs?
                            ^^^^^^^^^^
I assume that PKeddie really meant traditional structured programs.

>IMO a well written OO program is much easier to maintain.
[...]
>Maintaining OO (and C++) requires a more global understanding
>of the system than with C.
>[...]
>so the end result
>is that fixing a line of code can have impact throughout the system.
>[...]
>IMO debugging an OO system is more tedious than traditional C.

Isn't this exactly the OPPOSITE of what the goals of OO are?

But I agree that with C++ this is definitely the case, though that is
not so with languages more in the Smalltalk and CLOS vein.  Now,
before you hit the Flame key on your keyboard, let's look at why this
is so; specificly, what are the differences/defects of C++ that cause
this to be so?

The major flaw of C++ which causes the rippling change effect is that
C++'s requirement for strong type checking leads to heavy base
classes, while the Smalltalk/CLOS approach leads to lightweight super
classes.  In more specific terms, C++ base classes must effectively
define as their interface the UNION of all behavior of their derrived
classes, while Smalltalk/CLOS super classes tend towards the
INTERSECTION of subclass behavior.  Using mix-in style programming can
lessen this, though the basic problem still exists, as it is a
"feature" of type-safety.

(As an aside, it would seem to me that this problem would prevent any
sort of mathematical model of OO from covering both Smalltalk/CLOS and
C++ environments.  In other words, while we may talk about all of
these languages being OO, they really embody entirely different
and incompatabile concepts of what OO is.)

This problem is the dirrect cause of maintainence headaches: to add
behavior, the maintainer needs to chase inheritance towards the
ultimate base class, causing ripling type problems along the way.
Hence, the need for deep knowledge of the system.  In Smalltalk/CLOS,
the situation is entirely the opposite: there is no need to look at
superclass behavior; rather the maintainer is free to change the
behavior of subclasses without affecting the behavior of superclasses.
I do not need intimate knowledge of the entire view heirarchy (or even
source code access) just to add some new behavior to a specific view
class.

Another major contributor to the rippling maintainence problem is the
fact that C++ is effectively a dual-type heirarchy environment; in
other words, there are two distinct categories of objects: those which
are atomic types, and those which are aggregate types.  The fact that
the behavior of the atomics and aggregates can not be made equavallent
leads to an inconsistent language.  Intrestingly, C does not have this
problem -- while C presents aggregate types to the programmer,
internally they are handled simply as collections of atomics.  No
matter how the programmer writes the element/pointer reference, it is
still handled in a consistent way by the compiler, always in terms of
simple pointer arithmetic.  A good demo of C++'s problems in this area
is the pointer to member: with the introduction of this special type,
C++ has created a pointer which is address arithmetic incompatabile
with other pointers.  This is not a good situation!

Additional C++ maintainence problems include the idea that typedef's
are not real types, but rather simply synonyms (thereby providing
transparent but rather confusing unless you are intimate with the
system type promotion), while enum's are real types.  This is all
compounded by the notion that the atomics and certain base operations
not be modifiable as an "escape hatch/safety mechanism" -- a seriously
flawed idea that prevents people from building consistent type
heiarchies in C++.

IMO, these problems lead not only to maintainence problems, but also
prevent the original goals of OO: simplified systems maintainence to
keep up with evolving systems needs, and reuse of completed
development effort.

>I've been using C++ since 1987-88, Modula-2 before that. I enjoy the
>C++ language, but understand peoples frustrations. I would never
>go back though.

This, I have to agree with.  If we get used to the concept of C++ as a
better C (as I read Bjarne Stroustrup state in one of his articles),
then C++ is much easier to swallow.  However, I think we are deluding
ourselves if we attempt to place C++ in the same category as languages
like Smalltalk and CLOS.

>++harvey
>===========================================================================
>internet:       [e-mail]  /  [e-mail]  /  [e-mail]
>voice/fax:      [phone]    /  617-965-7599

-frank

(OK, *NOW* you can hit the Flame key on your newsreader! :-)
--
EMail: [e-mail]         |  Do or do not, there is no try.
Phone: 1 - 212 / 765 - 2050  |                                 -- Yoda