From: ian@syacus.acus.oz.au (Ian Joyner)
Subject: Re: good and bad points of C++ (was: C++ Critique (1 of 4) (long))
Organization: ACUS Australian Centre for Unisys Software, Sydney
Date: Wed, 15 Apr 1992 13:27:39 GMT

tmb@ai.mit.edu (Thomas M. Breuel) writes:

>My conclusion is that you would probably be happier with Eiffel. It
>seems to address all your complaints. But I think some of the
>suggestions you make, which you claim are more in an OO-style and
>actually have been adopted in Eiffel, would make C++ much less useful.

You are quite right, I would be happier with Eiffel, it is quite an
achievement.  However there are two disclaimers to this.  Firstly,there
are lots of potential languages I may be happy with.  I am not going to
therefore choose one, even if it is as good as Eiffel, and pretend that
it is the only language for me.  Well trained computer people should be
able to adapt to many different languages.  Learning a programming
language is not in itself a difficult thing, it is learning how to
program that is difficult, and something I am still learning, and I
think the whole industry is still learning.  Secondly, I don't think
that any language is beyond criticism.  But hopefully, such criticism
may be accessed and adopted into the language if any good.  I had a
really long introduction to the critique written on this at one point,
that such critiques could be written on all languages, so that the
language itself may be improved, and that secondly, future languages may
not make the same mistake.  However, as the critique grew some stuff had
to be left out. 

I think that the C++ experiment has been necessary, but now the results
are in, it is becoming more apparent that a clean break from the past
of C is necessary.

>On the other hand, the large number of small syntactic and semantic
>quirks that C++ undoubtedly has, and which figure so prominently in
>the complaints of many people about C++, don't really bother me that
>much. I care primarily about the functionality that a programming
>language provides; learning where to put parens and semicolons is
>pretty trivial.

However, the number of quirks does build up to become annoying, and
furthermore, more than annoying, counter-productive. You often have
to reference the ARM or similar reference to check up on these
quirks. A language should implement the concepts behind it cleanly.
If it cannot be trusted in this, then maybe the concepts weren't that
clear to the language designers. If you can't be trusted in small
matters, then you cannot be trusted in large matters.

>What makes C++ useful to me is the fact that it generates code that
>performs acceptably, that it supports true polymorphism (in the form
>of templates), exceptions, and overloading (which is very useful for
>numerical programming), and that it has a convenient "foreign function
>interface".

I am not sure what 'you' mean by 'performs acceptably', but I assume,
that you mean executes efficiently. This to me is a secondary concern.
What is more important is that the program performs correctly. It
does not matter how fast the program runs if it comes up with the
wrong answer, or provides a kludgy user interface, etc. However, just
because I said efficiency is a 'secondary' concern, does not mean
that I consider it unimportant. I think the measure is that people
are more important than computers. If we are saving processor cycles,
but expecting a person be put to more inconvenience to do this, then
the system is worse than useless. Computers are to serve people, not
vice versa. In fact the old 1950s, 60s view that people were perihperal
units to mainframes is totally obnoxious.

>Interestingly, the OO component of C++ is of little importance to me.
>After having programmed both in OO and non-OO programming languages
>for many years, I have come to the conclusion that inheritance and
>virtual functions are not very useful for most kinds of programming.
>The major exceptions are graphical user interfaces, simulations, and
>certain kinds of data bases; however, such applications are probably
>better served by a concurrent, message-passing approach, rather than a
>strict OO approach.

To be somewhat contrary here, I contend that there are very few if not
no systems that cannot be implemented in the OO paradigm. For very
simple systems, it may not be necessary, or an overkill, but there are
few systems these days so simple. Inheritance is of course not necessary.
It is merely a compile time concept, that helps us deal with complexity.
However, there are many disciplines that have benefited from hierarchical
classification, and inheritance, and many insights have been gained into
the real world by classification. It is not the only way we may reason
about the real world, but it certainly has been most useful outside the
computer science world. Even in a library, classifications are made on
non-fiction, fiction and periodicals. It is interesting to contemplate
a world devoid of such classifications. Classification is often
used without being concious of it. Would the library be so useful, if
the entities were not classified. Would we be able to find anything
in the supermarket, if they did not classify the items on the
shelves. The answer is yes, but it would be very much more difficult.

>Furthermore, the OO approach to ADT's leads to monolithic type
>hierarchies and very unpleasant name conflicts that actually inhibit
>software reuse. I think these fundamental problems with the OO
>paradigm will ultimately spell the end for C++ and many other OO
>languages that are being touted as the solution to the "software
>crisis". Personally, I suspect that a functional approach together
>with a powerful module system (along the lines of SML) is a much
>better approach to ADT's. But for the time being, C++ is an acceptable
>compromise and a very useful tool.

I would encourage you to enumerate these problems with reuse, so that
the researchers can either correct the OO paradigm, or develop a new
paradigm that solves these problems. Or perhaps we need to modify the
way we do things within the OO paradigm to avoid these reuse problems?
Unfortunately, as more and more are jumping on the C++ bandwagon, there
seems to be becoming less and less opportunity for other such approaches
to be tried and to become successful. Or are these only to be researched,
so they can be later absorbed into the ever expanding C base. I thought
we learnt this lesson in the 1960s, that large and unwieldy languages
like PL/1 and COBOL that incorporated everything were not the way to go.
-- 
Ian Joyner                                     ACSNet: ian@syacus.acus.oz
ACUS (Australian Centre for Unisys Software)   Internet: ian@syacus.acus.oz.au
Tel 61-2-390 1328      Fax 61-2-390 1391       UUCP: ...uunet!munnari!syacus.oz