Going Native 2012 Keynote Stroustrup
savage3092 HN recommenders · 2012–2025
33K views · talk · dated · Uploaded 2012-02-05
Bjarne Stroustrup's keynote at Going Native 2012 covers the ideas behind C++11, including using types to prevent errors and simplifying code with the STL.
Cited as a good talk on the thinking behind C++11 and on using the type system to prevent bugs; some other mentions quote it critically.
49:55How Python was Shaped by leaky Internals, Armin Ronacher, Flask framework
Видео с мероприятий {speach!
1:12:27CppCon 2015: Andrei Alexandrescu “std::allocator...”
CppCon
51:18Lexical Scanning in Go - Rob Pike
GoogleFOSSSydney
46:09Why Isn't Functional Programming the Norm? – Richard Feldman
Metosin
1:03:29Maybe Not - Rich Hickey
ClojureTV
7:48Conway's Game Of Life in APL
Dyalog
1:12:56Lecture 1A | MIT 6.001 Structure and Interpretation, 1986
MIT OpenCourseWare
1:42:09Crockford on JavaScript - Volume 1: The Early Years
YUI Library
5 comments from Hacker News
This sounds like the kind of problem that puts really expensive robots into craters. [VIDEO] There's a salient point in that talk where he describes a mission that failed due to a human error. Someone forgot to convert an internal representation of a unit in some algorithm which led to a miscalculation and a loss of some millions of dollars. Apparently the error made it through all of the code reviews and tests that were written. Bjarne then shows some pretty simple code that might have avoided such a disaster by specifying your types up front and letting the compiler do the work of converting them. Seems like a pretty simple concept and I wonder why it's so often missed.
GoingNative 2012 - Bjarne Stroustrup talks about C++ 11. Very good talk about the ideas behind C++ 11 [VIDEO]
"I understand what you are trying to say and I think that you are wrong." --Bjarne Stroustrup, to a chorus of razzes, jeers and laughter at a question in going native a few years back. [VIDEO] about 1:09:30 But hey don't take my word for it, my reputation is nothing and I'm as anonymous as a wrong number whether I like it that way or not. How about Ken Thompson? His doesn't seem to be similar, if you like an argument from authority - and I think such argument has a place if not used exclusively. "I would try out the [C++] language [at AT&T] as it was being developed and make comments on it. It was part of the work atmosphere there. And you'd write something and then the next day it wouldn't work because the language changed. It was very unstable for a very long period of time. At some point, I said, no, no more. In an interview I said exactly that, that I didn't use it because it wouldn't stay still for two days in a row. When Stroustrup read the interview he came screaming into my room about how I was undermining him and what I said mattered and I said it was a bad language." Ken Thompson; cited in Seibel, Peter (2009). Coders At Work. p. 475. Alexandrescou openly criticises Alasdair Meredith at cpp con in a way that isn't really friendly or respectful. He also finishes all his talks with "Destroy!" as an open acknowledgement of the defensiveness he feels about the naked hostility that exists in the C++ world. I like his stuff and the bulk of his attitude, I hate the context
What I mean is anything that is showing off, has a lack of humility and implicitly disparages others in a way that is totally unneeded while producing lower-quality, less-maintainable, less robust code. Being clever for the sake of appearing clever. That kind of thing. if(condition) I_am_tough_so_I_do_not_brace(); The un-braced block is a classic "macho" pose in code. leaving out a '{' and a '}', two characters, has no benefit in any way, shape or form. It is decrying "I will never make a mistake with this loose razor blade if you do maintaining it is because you suck" There is literally no reason to do it ever, under any circumstances. Yet I have, and we do. We can change. Now watch the arguments presented when you bring un-braced blocks up. They're insanely ridiculous. (vertical space, need static analysis, etc.) If you were betting your retirement savings on no bug in the line of code now or in the future, you'd be very nervous about it sure. And then you would brace it. Unbraced blocks are a minor thing that mostly don't matter. I wouldn't fight too hard over it. It's just that it's so very, very clear that one way is bugs for zero benefit while the other isn't. Meh. So here's Bjarne being "Uber-Macho" to the delight of the conference crowd. Note the quote: "I think I understand what you're saying and I think you happen to be wrong." (crowd whoops in glee). [VIDEO] This is a pretty ugly way of saying "I disagree and this is why..." But the crowd loves it. That attitude ge
The talk: [VIDEO] Sadly the 25-line original code isn't presented; the code that is presented is the 5-line replacement using the STL's `find_if` and `rotate`. Bjarne sketches the idea that those five lines can be further condensed into two lines with the non-STL `gather` algorithm: auto dest = std::find_if(v.begin(), v.end(), contains(p)); stdx::gather(v.begin(), dest, v.end(), [](const auto& elt) { return &elt == &*source; }); But this is overkill — replacing an O(distance(source,dest)) non-allocating rotate with an O(v.size()) potentially-allocating stable_partition — and more importantly it re-complicates the code. Now, I think part of his point is that `stable_partition` is "simpler" than `gather` only because it's in the STL. If we add `gather` to the STL too and everyone learns what it means, then there's no objection to using `gather` for "simplification" like this: it would be a straightforward simplification in almost the same way that `std::equal_range(first, last, x)` is a straightforward simplification of `std::make_pair(std::lower_bound(first, last, x), std::upper_bound(first, last, x))`. The "almost" is that actually there is an algorithmic advantage to `std::equal_range`: when you're looking for the upper bound, you don't have to consider any of the elements to the left of the lower bound you already found. You get a (very slight) performance boost by using the combined `equal_range` algorithm. `gather`, on the other hand, has no such advantage; and (as we've