Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Evolving a language in and for the real world: C++ 1991-2006 (2007) [pdf]

stroustrup.com

Post reply on HN
Print view View original

21–27 of 27 posts

Re: Evolving a language in and for the real world: C++ 1991-2006 (2007) [pdf]

#21

Post by Argorak »

yanowitz wrote: post #18
pjmlp wrote: post #10

Another good read is the book "The Design and Evolution of C++". 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.

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).

"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...

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.

Re: Evolving a language in and for the real world: C++ 1991-2006 (2007) [pdf]

#22

Post by kyllo »

toolslive wrote: post #15
femngi wrote: post #12

Earlier quoted context omitted.

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 , 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…

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 e…

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.

Re: Evolving a language in and for the real world: C++ 1991-2006 (2007) [pdf]

#23

Post by AnimalMuppet »

kabdib wrote: post #20
otoolep wrote: post #3

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

Won't be the first time that I think Stroustrup has made a serious error, and is compounding his error by not repudiating the feature. Go read Sutter's _Exceptional C++_ or any of its follow-on books. It appears nearly impossible to write solid software when you allow exceptions into your set of control structures. The best response to an exception is: Restart. Catch the exception in something like main(), take a dum…

C++ is used in many environments where "restart" is not a viable option.

Re: Evolving a language in and for the real world: C++ 1991-2006 (2007) [pdf]

#24

Post by AnimalMuppet »

72deluxe wrote: post #16

"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…

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.

Re: Evolving a language in and for the real world: C++ 1991-2006 (2007) [pdf]

#25

Post by judk »

AnimalMuppet wrote: post #24
72deluxe wrote: post #16

"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…

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.

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.

Re: Evolving a language in and for the real world: C++ 1991-2006 (2007) [pdf]

#26

Post by judk »

kyllo wrote: post #22
toolslive wrote: post #15

Earlier quoted context omitted.

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 e…

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.

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)

Re: Evolving a language in and for the real world: C++ 1991-2006 (2007) [pdf]

#27

Post by AnimalMuppet »

judk wrote: post #25
AnimalMuppet wrote: post #24

Earlier quoted context omitted.

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.

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.

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.

Post reply on HN