
Evolving a language in and for the real world: C++ 1991-2006 (2007) [pdf] - otoolep
http://www.stroustrup.com/hopl-almost-final.pdf
======
pjmlp
Another good read is the book "The Design and Evolution of C++".

[http://www.stroustrup.com/dne.html](http://www.stroustrup.com/dne.html)

It does provide a very clear rationale why C++ became the way it was (C++98),
given the design goals and the constraint of being C compatible as much as
possible, both in language and compiler toolchains.

~~~
yanowitz
It was also a fantastic way to learn the language.

Going through all the design decisions, the underlying implementation, the
trade offs helped me build a mental model that massively increased my
productivity and intellectual happiness.

I yearn for similar works for other languages (e.g., clojure).

~~~
Argorak
"The Ruby Programming Language" by Flanagan and Matsumoto may not have that as
it's main goal, but gives a very good overview on why features are how they
are and even gives some advice from the creator of the language himself and
some commentary on them (e.g. flip-flops are considered an implementation
oddity kept around for backwards compat).

[http://www.amazon.com/Ruby-Programming-Language-David-
Flanag...](http://www.amazon.com/Ruby-Programming-Language-David-
Flanagan/dp/0596516177)

I think it's the most relevant Ruby book, because it documents the basic
thinking and mental approach of the language, which is actually very stable.

------
pbiggar
This is a great paper! It was given at HOPL 3 (History of Programming
Languages, a conference which runs every 15 years). I'd recommend all of the
HOPL 3 papers to aspiring language nerds, but especially the ones on C++, Lua,
Haskell and Self.

~~~
otoolep
Yeah, for a somewhat longer paper, it's eminently readable. Very human in
tone.

~~~
zura
It's Bjarne's style - long but readable texts.

------
castell
The chapters _C /C++ Compatibility_ (7.6), _Sun and Java_ (7.7), _Microsoft
and dotNet_ (7.8) and _Retrospective_ (9) were very informative. It's a
history lesson every programmer should read.

------
72deluxe
"It is more important to allow a useful feature than to prevent every misuse."

That's from his "Design Support Rules" section early on in the paper. I am
still going through the paper, but this seems like a good rule and a reason
why pointers are still allowed despite the protestations of people who hate
C++. Sure, you can get into a pickle with them but that's not the language's
fault.

Of course, there has been the rule "use references where you can, pointers
where only absolutely necessary" but it's a difficult habit to break...

~~~
AnimalMuppet
Two that jumped out at me: "C++'s evolution must be driven by real problems"
and "Don't get involved in a sterile quest for perfection."

Arguably, that philosophy is why C++ went on to rule the world, and Lisp and
Haskell remain niche languages.

~~~
judk
Interesting tat Go has the same philosophy yet is anti-C++ many ways.

The difference is that Go doesn't believe "useful" is enough justification--
usefulness is balanced against clutter and complexity.

~~~
AnimalMuppet
Go has a different perspective on the cost of clutter and complexity - how
much it costs in terms of compile time when you maintain a million line code
base over two decades. Going from a 45 minute compile to a 10 second compile
adds up over a couple decades.

But it is still the same philosophy - Go's design is being driven by real
problems that people ran into.

------
otoolep
"Exceptions are typically — and correctly — seen as a control structure". So
much for those who say using exceptions for flow control is _bad_.

~~~
femngi
Yeah, I'm just going to go ahead and disagree anyway. Not only are they a poor
structure for flow control they are an inefficient and slow one too, as Andrei
mentions in his 2012 talk on expected<T>, a talk which also nicely illustrates
the shortcomings of using them for their intended purpose as error handling.

In fact exceptions as implemented in C++ has to be one of my last favourite
things about the language. They are an all or nothing proposition and yet were
put in half heated and unchecked. Many years later the result I see is some or
most programs have a catch(...) at some high level. Something went wrong, who
knows what, can't even set the debugger to break at exceptions because they're
being thrown everywhere all the time for flow control.

~~~
toolslive
The heuristic is that if the case is more frequent than something like 1/1000
then you don't use exceptions in these languages (C++, Java, ...). As they are
a lot cheaper in languages like ML, people there tend to use them more for
early exits out of things like folds.

A simple example:

    
    
      let prod = List.fold_left (fun acc a -> acc * a) 1.0 xs
    
    

should not fold over the whole list if a factor is 0.0 so they tend to use
exceptions for that (or delimited continuations)

~~~
kyllo
Java doesn't really give you a choice though, because so many of the standard
library classes have exceptions baked in. Any code you write related to file
I/O for example will have to have either a "throws" or a "try/catch" on it, or
else it won't even compile.

~~~
judk
Checked exceptions are much closer to "error codes" than unchecked exceptions.
Checked exceptions just loosen the constraint a bit and let you defer handling
to anywhere the caller's remaining function scope (or explicitly continue the
throw)

------
otoolep
Straight from the man himself, Bjarne Stroustrup. Really interesting for any
C++ programmer.

