[NTLUG:Discuss] Evil C++ (was Re: Evil GCC-2.96)

[Richard Cobbe]

WARNING: technical discussion of various language details ahead.  Those of
you not interested in this may wish to skip ahead to the next message now.

Lo, on Friday, June 15, Steve Baker did write:

> cbbrowne at ntlug.org wrote:
>  
> > The _big_ problem (to my mind) with C++ is that the standard document
> > is considerably longer than that for other standardized OO languages
> > like Ada or Common Lisp, even though there are substantial things that
> > those standards include which C++ does not.  [e.g. - stuff like STL
> > must be _added_ to the already daunting complexity in order to get
> > similar functionality to the other guys...]

Oh, absolutely.  If you read the specs, or any of the documents which have
grown up around the specs, it becomse very apparent that the C++ folks have
put a great deal of thought into dealing with all of the obnoxious issues
that come up as a result of the core features of the language and the way
in which they interact (like, say, exception handling and memory
management).  However, no amount of careful analysis can overcome the fact
that the language's core is, in many ways, garbage---it completely ignores
much of the language research of the last 25 years.

> > If the language definition was _so_ controversial as to require so much
> > description, that means it's got _big_ hairy edges, and the "fighting"
> > over which version of G++ should get released when, and the previous
> > longstanding serious deficiencies of G++ all come as a consequence of
> > this.

True.  In many ways, it's a lot harder to implement C++ both correctly and
efficiently than it is to implement something like Scheme correctly and
efficiently---in spite of the reputation that Scheme has for being a `slow'
language.  (Most of the problems in this area come from the fact that C++
exposes so much of the underlying implementation to the programmer.  This
is necessary and convenient in certain situations, but in general, it's
more of a hindrance than a help.)

The efficiency argument for C and C++ doesn't really hold up in the general
case anymore, either.  If you've got a good recent Lisp compiler, your
program's runtime will be comparable to a C++ translation.  Other
`advanced' languages have similar performance.  (And, if your developers
really understand the language, then your development and maintenance times
will be significantly shorter than with C++.)

Now, granted, advanced languages like Lisp do impose a certain amount of
memory overhead over mid-level languages like C++, primarily due to garbage
collection.  There may be some situations, like embedded systems, where
that overhead is unacceptable.  However, for desktop apps, memory is
cheap---use a little bit more memory to ensure that your program can
*never* segfault (as opposed to never segfaulting while you're testing,
which is about the best you can hope for in C++).  And, this memory
overhead is not the end of the story: the presence of a garbage collector
frees you from having to worry about object lifetimes.  This, in
conjunction with the decreased use of side effects, like assignment
statements, allows you to share complicated data structures rather than
copying them several times.

> You keep boldly asserting that this is some terrible language...but
> look at the facts.
> 
> C++ programmers *love* it.

True.  But so what?  Most people think Windows is the best alternative
around, too.  (And, IMO, for many of the same reasons.)

> In fact, most C++ users don't use all of the little bells and whistles
> that make for such a complex language spec.  Most C++ users I know are
> still writing C++ according to the original AT&T C++ translator spec.
> Mostly people treat C++ as if it were just C-with-classes and ignore all
> the exception handling, templates and such.

Also likely true.  You know *why* they avoid those parts?  Because many
developers don't understand them, and because most compilers don't
implement them correctly right now.  If you use those parts, you're asking
for trouble.  I prefer a language that's well-defined (as distinct from
well-designed, which is also generally a plus).

(The remainder of this article is based very heavily on `Beating the
Averages', by Paul Graham, available online at
<http://www.paulgraham.com/avg.html>.  Highly recommended.)

In brief:

It's become fashionable, for political reasons, to assume that all
`high-level languages' (i.e., all languages farther from the bare metal
than assembly language) have equal expressive power.  (Granted, they're all
Turing-equivalent, but that's not really what I'm talking about here.)  If
you look at this more closely, though, it's not really the case.  For
instance (to use one of Graham's) examples: Perl 5 adds lexical closures
and objects, two features not available in Perl 4.  Don't most people
consider Perl 5 to be more powerful than Perl 4?  If we can say that, then
why can't we say that Perl is more powerful than C, or C is more powerful
than Perl?  (Neither Graham nor I are positing the existence of a complete
ordering of languages by expressiveness, only a partial ordering.)

The trouble is that (to borrow a concept from linguistics), the strong form
of the Sapir-Whorf Hypothesis appears to hold true with respect to
programming languages: your primary language dictates the way in which you
view the world.  If a programmer looks *down* the language spectrum,
towards less expressive languages, they can easily see why those languages
are less expressive, because they don't have X---where X is some feature
of, say, C++ that you use on a regular basis.  However, it's difficult for
that same programmer to look *up* the spectrum: if they see something like
Lisp at all, they'll most likely think of it as a language that's about as
powerful as C++, but with a really weird syntax and with all this extra,
unnecessary stuff thrown in.  The only reason that this programmer will
consider these features (like macros, first-class closures, &rest
arguments, and garbage collection) to be unnecessary is that, by and large,
our hypothetical programmer has learned to live without them---or, perhaps
more accurately, never learned how to use them effectively.  "Lexical
closures?  Oh, those are too complicated, and I've never had to use them,
so why should I bother?"

(Answer to rhetorical question: they can, when used correctly, dramatically
decrease code size and maintenance time, because they cut down on repeated
code.)

(Oh, and answer to complaint caused by above feature list: yes, C++ has a
very primitive macro system, but compared to Common Lisp's, it's nothing.)

On the other hand, if someone like me, who's been trained in high-level
languages, looks down the continuum at C++, I'll say that it's less
expressive, because it doesn't have garbage collection and first-class
closures (to name the two features that I use most frequently).

The long and the short of all of this: of *course* C++ programmers love
C++.  They've been conditioned to.  And, as a result of this conditioning,
they tend not to be able to reason objectively about more expressive
languages.  (Correspondingly, I'll have a difficult time reasoning about
languages more expressive than Scheme/Lisp.  Lisp is so flexible, though,
and has incorporated features from so many other languages that there
really aren't too many of these.)

Therefore, the fact that C++ is immensely popular says NOT ONE THING about
the quality of the language design, the quality of the language definition,
or the quality of the implementations.

Richard