Re: Is C++ really used ?

pjmlp@students.si.fct.unl.pt (Paulo Jose Pinto - LEI) wrote:
> Is C++ so bad for compilers, after all I'm using it and it seems
> that everyone else is, so why aren't the books ?


"Programming languages should be designed not by piling up feature
  on top of feature, but by removing the weaknesses and restrictions
  that make additional features appear necessary."
        The Revised(4) Report on the Algorithmic Language Scheme, which
        then goes on to define Scheme, including rigorous denotational
        semantics for the exact meaning of its constructs, with many
        examples, in 45 pages.


C++ has many problems, a few quite severe. The lack of a garbage
collector, and the immense complexity of the language, are but two of
the tips of the iceberg. (Even members of the ANSI standardization
committee bemoan the language's complexity.) There are lots of other
reasons to complain. For instance, the early versions of the
language, under cfront, had neither templates nor exceptions nor a
standard library. Thus users had to come up with their own ways of
dealing with the problems caused by these omissions. In the case of
templates, many users had home-grown preprocessors that would crank
out copies of source files for specified types, so when real templates
came around, they could simply discard their own programs and upgrade.
So, although some still have such programs, most have moved over to
the native template facility -- mostly because the native facility is
much nicer.


        But exceptions, and no standard library, are a different story.
The entire original runtime library was written without there being
exceptions, and there are billions of lines of code that depend on
that implementation. So, now, belated, we have exceptions, but we
can't use them in even the most obvious situations (like, say, running
out of memory in new()) without tossing the standard runtime. The
committee wanted to do that, I heard, but were shouted down by the
real-world guys. So there are exceptions now, but they are kind of
crammed into the language, and they aren't used much because you don't
need them with the normal runtimes; and since programming with
exceptions is a different way of thinking, most haven't switched over
to the new facility. In a way it's kind of like C, back when the
facility of passing structs to functions and returning them was added;
it was a new way of thinking, and few people made the shift because
there was no reason to.


      Same with the standard library. Stroustrop says that releasing the
language to the world without a standard set of collection classes was
the thing he regrets the most; not having garbage collection was the
next down on his list. The library we finally have, STL, I think
stands for "Slow Template Library". It's elegant and kind of clean,
but tricky and error-prone and has lots of overhead. Again, since it
was so late in being released, there are billions of lines of code
that use other collection classes (like MFC's, to name just one set).
So now we have dueling collections, with no clear winner. If STL were
categorically superior, that would be one thing. But it's not. So we
have multiple paths spreading out into the future: more and more
complexity, not less and less. C++ has made the job of programming a
tedious, convoluted, and error-prone endeavor. It didn't have to have
turned out like this, but because we all wanted OOP and C
compatibility and raw speed, this is what we got. I think future
historians of computer science will look at this decade, and the next,
as the working out of a tragedy of a scale that we probably can't
imagine now, in the middle of it.


      Perhaps the greatest casualties of this tragedy are the bright new
compsci students, excited about becoming programmers, who are given
C++ as their first serious language. I've seen it myself, the
downtrodden looks, the sense of defeat, the utter bewilderment at some
new unforseen complexity that sprang from the ground and bit them yet
again. I've seen two promising youths just quit in despair, saying
"if this is what programming is all about, then I'm not interested."
Early success is the best way to teach, and it is pretty much
impossible to structure C++ learning so that there is early success.
I could go on about this, and give you many detailed examples of what
I mean, but you can see it for yourself: take a look at the standards
committee's report on C++. It's a monster, filled with legalese and
special cases. I understand that there are many inconsistencies and
places where is is ambiguous at best (from a compiler writer friend of
mine who is working on a commercial C++ compiler) but mainly, it's
just *huge*. Everything but the kitchen sink is in there. So it
rewards "language lawyers" rather than normal programmers.


      There are other ways of doing things. There are ways of
programming in which you never have stack overflows, never have
pointer problems, never have a memory bug, period. There are strong
programming paradigms that avoid many of the problems that C++
programmers think are just a way of life. There are fast and
efficient languages that are light-years ahead of C++ in elegance,
expressivity, clarity, facilities, and power. Small is beautiful; C++
is big. Elegance is beautiful; C++ is special-cased to death.


      Are there better languages for writing compilers? I think the way
to ask this is, why would anyone ever want to write a compiler in C++?
You may be forced to by your boss; you may only know C++ and Pascal
and Basic so you have no real choice; maybe the only fast language you
have around is C++. These might all be reasons to use C++.
Noticeably absent are "because it is the best language for the job"
and "because C++ provides the compiler writer with just the right
feature set."


      I'm writing my current compiler (a domain-specific language
translator for an actuarial company) in a variant of ML called
Objective Caml. I think it is an astoundingly beautiful language, and
the performance is nearly that of C++. This morning I had to write
code for the assignment statement semantics, and it took about eight
lines. I laughed when I wrote it, as I was thinking of how many pages
of C++ code would have been needed to do the same task. It is as
though ML's designers had me personally in mind when they decided on
the features that they would provide. You know how lex and yacc
provide support for scanning and parsing? Well, ML itself feels like
that, but for all stages of the compilation process. Building the
abstract syntax tree, making and accessing the symbol table, walking
and annotating the trees, generating code -- all along the way ML
helps me, gives me facilities and constructs and ways of doing things
that make my job easier. (Caml has its own lex and yacc too, of
course.) Take garbage collection, for example. Imagine if you never
had to call "free", if the runtime system would just free stuff up for
you. (Actually, Boehm's collector will do just that, if you want to
go through the pain of getting it up and running.) That would make
your entire effort easier, wouldn't it? Well, Caml's lists and
exceptions and pattern matching and tail recursive optimizations and
first-class functions and parameterized types all work like that: they
work in concert to make your life easier. And the library -- is
simply astounding. Caml is a very mature product, and the library is
clean and elegant and has just about everything you would ever want.
Yet my reference for the library is exactly eight pages long; I keep a
shrunk xerox of it with me as I work. I am still amazed at it.


      Caml also has a full set of object-oriented features to it, but you
know, I find them not so useful as with C++. There are other ways of
managing complexity than OOP, and I'm finding a real attraction to the
functional style of programming. It's a different way of programming,
a revolutionary way, I think, and it's a shame that more people don't
know about it. It's a way of bringing beauty back into the job at
hand.


      So, to finally answer your question: C++ isn't so bad for compilers
specifically, it's just that C++ is big and hairy and dangerous in
general. You want a better alternative? Try Java. It's not Caml,
but it's three giant steps in the right direction, and native Java
compilers will be out soon that exceed 90% of C++'s runtime speed.
You get garbage collection, you get pointer safety, you get OOP, you
get thread safety, you get the right way of doing inheritance (single
inheritance for implementations, multiple inheritance for interfaces)
instead of the wrong way (only single inheritance, or full multiple
inheritance ala C++). You'll like it, I bet.


      You want a language made in heaven just for compiler writers? Try
Caml. It's free! http://pauillac.inria.fr:80/caml/ Be forewarned:
there is a significant learning curve.


      Dwight
--

Return to the comp.compilers page.
Search the comp.compilers archives again.