Re: What is wrong with OO ?

[jsa@alexandria (Jon S Anthony)]

In article <E3I8GL.AuH@research.att.com> bs@research.att.com (Valerie Torres) writes:

> Jon S Anthony (jsa@alexandria) writes:
>  > Private data member stuff was in various languages
>  > before "C with classes" was even conceived (e.g., CLU, Ada83).  It
>  > certainly existed in Eiffel before C++ was christened.  Protected
>  > capability was certainly in Eiffel-1 which predates C++.  Same with
>  > overload resolution (e.g., Algol68 had this as did Ada 83 compilers
>  > that were in the field before CWC or C++).  MI was in Eiffel from the
>  > start and that predates its appearance in C++ for sure.

> First of all, we must be careful about dates. C with classes had "private"
> in 1979 and protected around 1981. Data abstraction language (such as Ada83)
> tends to have private only (you need inheritance for the private/protected
> distinction to be meaningful) whereas OO language (such as Smalltalk) tends
> to have protected only (whatever it may be called).

Fair enough and I certainly can basically agree with this.  It is also
no big deal IMO if the features are _not_ "innovative" or new.  If
they are good and correct and well integrated - who cares (well some
do, but from many points of view, it just doesn't matter).  For
example, private stuff is basically captured in M2 by opaque types,
which according to Wirth was around '77-'78.  As you point out,
Smalltalk had the equivalent of protected and that was early '70s.
Shrug...


> I don't know if any language having both before C++ and I don't know of
> any earlier language expressing the dinction between implementation
> inheritance (private base) and interface inheritance (public base,
> subtyping).

You talking C++ or "C with Classes"?


> This pre-dates Liskov's formulation of her substitution
> principle by about 8 years. It is of course possible that some language
> had equivalent facilities at the time I designed those features for
> CwithClasses/C++ or that someone somewhere wrote a paper discussing

Well, what time frame are you really refering to here?  The
79-early-8x stuff of CwithClasses or the latter 80's C++?


[Various other stuff snipped on co/independent discovery etc.]

Well, sure, all this sounds perfectly sensible and believable.


> There are literally hundreds of details that one could examine to try
> to determine their exact antecedence and give credit where credit is
> due.

Absolutely.


> C++ was designed to allow design and programming techniques from Simula
> to be used in the context of systems programming and other applications
> where run-time and space were critical. On way of looking at the task
> I set myself was to make data abstraction and object-oriented techniques
> affordable and accepted in a community that mostly didn't know of them
> and to the extent it did couldn't afford to apply those techniques
> given the languages available.
> 
> To the extent that C++ succeeded at that, C++ was ahead of the wave,

Ah, this is the "_implementation_ innovation" aspect that I originally
refered to as something that I would acknowledge C++ "leading" in the
"OO world"...


> of C++ that are currently emphasized in the MS Windows world). The speed
> and compactness of code generated from C++ depends on a few fundamental
> design decisions that I think were novel at the time:

Some of these are novel (in a very narrow context - existing C) but
most are not.


> 	The ability to use user-defined types and built-in types in the
> 	same way. In Simula - as in most data abstraction and OO language -
> 	every object of a user-defined type must be on the heap; this
> 	leads to overheads compared to stack-allocated objects. Similarly,
> 	C++ pointers work uniformly for both user-defined and built-in
> 	types.

This certainly exists in Ada83 (sans virtual stuff).


> 	C++ offers objects of user-defined types with zero space overhead
> 	compared to C structs.

Same here.


> 	C++ offers calls of member functions with zero time overhead
> 	compared to C functions.

Same here.


> 	C++ offers inline member and non-member functions with zero
> 	overhead compared to macros.

Same here.


> 	C++ offers its form of dynamic (run-time) resolution, virtual
> 	functions, with low and fixed overhead compared to ordinary
> 	function calls (20% to 100% dependent of implementation).

This is a very good example - quite possibly the most important one.


> 	C++ can be used without a significant run-time-support system
            ^^^
> 	and without significant libraries.

Most statically compiled languages could and can be so used - it
"just" requires intelligent binders (not necessarily linkers...)


> This combination of feature was - and to some extent still is - unique
> and important to many.

This is not currently believable.  However, in the past, the efficient
runtime dispatch ability was at one point clearly a plus.


> This efficiency is a large part of the reason why C++ was able to
> blaze a trail into areas where data abstraction and object-oriented
> languages had made essentially no headway.

This is not particularly clear or believable.  It probably did have
something to do with it, but how much is not obvious.  The C heritage
(and its _presumed_ efficiency by association) is still the single
most likely reason for the demonstrated popularity.  Of course, in
those early days, there was no reason to believe that this would be a
real factor.  Sort of like having the insight/luck to buy into MS
before they were anything.


> By demonstrating applicability and efficiency in new application areas
> and in new communities C++ opened opportunities to other languages
> with a different balance of tradeoffs. Both where C++ was successfully
> used and where problems were found, it opened a door to alternatives.

Actually, I think a closer reading would be that people started out
thinking, "hey, we C folk can get on this <hated> OO/abstraction
bandwagon with our own C++!  It's basically just a better C which you
can sometimes use for OO stuff if you want.  Heck, you can even
compile most of your old C stuff with a C++ compiler."  What happened
next was that some of the more savvy realized that there really _was_
some good in this sort of approach after all - irrespective of any
language issue.  These folks no longer are wedded to the C++ language
and in fact many have moved on to, shall we say, more pleasent just as
capable/efficient alternatives.


> from a perceived competitor. C++ evolved within its own framework to
> meet the needs of its users. I don't think that can be fairly labelled
> "being a follower."

OK, but don't think it can be fairly labelled a "leader" either.  I
suppose we can say that it just "is"...


> language relying on static type checking. You can do without it of
> course (just like you can do without single inheritance and without
> classes), but the resulting code is contorted.

I don't want to go into this, suffice to say we can simply agree to
disagree.


> In the area of exceptions, C++ may have added something important:
> C++ exceptions can be of arbitrary type and inheritance is taken
> into account when catching an exception.

I see this as an approach or refinement to an already known and
(reasonably) understood facility.  I suppose that means I have a
somewhat more stringent notion of "innovation".


> Templates are an interesting case. Naturally, many languages have provided

Same here.  Note that in both of these cases you don't get something
for nothing.  Both exceptions and templates are IMO rather more
convoluted in C++ than the (more or less) equivalents in alternatives.

> Should something like this be considered innovative? Would it be fair

Depends on your point of view.  Some would probably say "yes" - for
example, you - I would tend to say "no".

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com