Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!rice!uw-beaver!apollo!mrst!sdti!wmm
From: wmm@sdti.com (William M. Miller)
Newsgroups: comp.lang.c++
Subject: Re: C++ Not Ready for Commercial Use
Message-ID: <1989Oct23.013434.18853@sdti.com>
Date: 23 Oct 89 01:34:00 GMT
References: <24.UUL1.3#913@acw.UUCP>
Reply-To: wmm@sdti.SDTI.COM (William M. Miller)
Organization: Software Development Technologies, Inc.
Lines: 98

In article <24.UUL1.3#913@acw.UUCP> guthery@acw.UUCP (Scott Guthery) writes:
>	1) C++ is *NOT* a superset of C.

In absolute terms, that is correct.  However, many (most?) well-written C
programs will compile under C++ with only minor changes like the addition
of function prototypes and casts.  These changes are improvements to the
program, IMHO.

>	2) C++ has been under development for over 10 years and it 
>           still isn't done.

Until X3J11 voted out the pANS, C was still ``not done'' (e.g., the flap
over whether noalias was going to be part of the language or not), and
C is substantially older than C++.  (And there's still no guarantee that
there won't be more evolution after the Standard is approved.)

>	3) An incompatible Release 2.0 just came out this year; existing
>	   C++ projects must either be rewritten or use two different
>	   incompatible compilers for the same langauge in their builds.

The incompatibilities aren't very severe, and ``conversion'' should be
trivial to nonexistent (except for fixing *warnings* about the future
disappearance of certain features like assignment to ``this.''

>	4) C++ experts are still arguing about how many features of C++ 
>           do work and should work.

There are many such discussions for C and Ada as well, and those languages
have been through the considerable refinement of the standardization
process already!  Except for dark, cobwebby corners, most of C++ is well-
understood and agreed upon.  And, since C++ is now entering the standards
arena, most of those corners should be swept and illuminated in the near
future as well.

>	6) C++ violates much of Wirth's advice about how programming languages
>	   should be designed & developed; programming languages are not just
>	   bags of tricks and features to be added to at will but this is how
>	   C++ is being developed.

Wirth is not the ultimate font of wisdom on such matters.  It is at least
arguable that a language designer who, on the basis of the principle of
parsimony, provides an ODD function but not EVEN, is somewhat out of touch
with real-world programmers.  C++ features overlap and duplicate sometimes,
but it is clearly a real-world language of real-world utility.  The history
of the language shows clearly, furthermore, that Bjarne has done an excellent
job of resisting the calls from users to throw in features that just solve
their specific problem and has instead developed broadly-useful additions
that integrate very well with the existing language.  There is much to be
said for the idea of getting real-world experience with the language and
then deciding what needs to be done to improve it instead of pontificating
from one's ivory tower in academia.

>	8) There is no software management methodology for inheritance,
>	   overloading, or persistent state among other C++ features.

I'd be very interested in proposals to rectify those omissions.

>	9) The current version of the language has only a operational 
>	   definition; the final version has no definition at all.

Perhaps you're unaware of the reference manual shipping with the 2.0
translator.  While it's not perfect, it is better than anything that
existed in print for the C language until the publication of Harbison &
Steele.  (My feeling is that K&R and Stroustrup's book provide roughly
the same level of documentation of their respective languages.)  That
doesn't address the ``final version'' issue, true, but a good portion of
that definition has been or is about to be published (parameterized types
and exception handling), and X3J16 should be sufficient impetus to do the
rest.

>I've got to wonder about the software engineering skills of 
>someone who would even think about committing a project to an undefined
>programming language.

Well, I would, too.  C++ as it stands now does not fall into that
category.  The language is quite well defined, and based on past
performance, I have every reason for confidence that future versions
of the language will invalidate little, if any, of the current
definition.

>While you wait for Release 3.0, read "The Dark Side 
>of C++" in the Proceedings of ECOOP '88.

I've read it; I certainly wouldn't claim that the language was perfect,
but obviously I was less persuaded by that paper than you.

>
>							Cheers, Scott
>
>+*+*+*+*+*+*+*+*+*+*+*+*+ Austin Code Works +*+*+*+*+*+*+*+*+*+*+*+*+*+*+**+*+

And to think, I just bought some stuff from you folks! :-)

-- 
Non-disclaimer:  My boss and I always see eye-to-eye (every time I look in
the mirror).

wmm@sdti.sdti.com