Dconf 2014 Day 2 Keynote: The Last Thing D Needs -- Scott Meyers
Why Hacker News recommends it
HN commenters bring it up whenever C++ complexity or the pitfalls of language design come up, as a witty and authoritative warning.
What it is
Scott Meyers' keynote at DConf 2014, drawing on 25 years of C++ experience to offer the D language community a plea about what it should avoid. It centers on the accumulated complexity and pitfalls of C++ as a cautionary tale.
Recommended by 4 HN commenters across 5 different months, 2018 to 2025.
What Hacker News said
Strong rec jejones3141 · 2021-07 · on “Modern C++ for C Programmers (2018)”
Yes, and everyone should watch Scott Meyers's awesome presentation at a D conference with the title "The Last Thing D Needs". (tl,dr version: The last thing D needs is someone like him, really to be so insanely convoluted, as C++ is, as to need someone like him.) Link to the video: [this video]
Recommends nordsieck · 2018-04 · on “Ask HN: What is your favourite tech talk?”
We Really Don't Know How to Compute: Gerry Sussman - [LINK] Zebras All the Way Down: Bryan Cantrill - [LINK] Jonathan Blow on Deep Work: Jonathan Blow - [LINK] Simple Made Easy: Rich Hickey - [LINK] Effective Programs - 10 Years of Clojure: Rich Hickey - [LINK] The Last Thing D Needs: Scott Meyers - [this video]
Recommends SloopJon · 2018-05 · on “Meta Crush Saga: a C++17 compile-time game”
> C++ developers .. don't seem to be interested in actually improving the language In his talks at the 2014 and 2017 conferences for the D programming langue, Scott Meyers noted the difference between what individual C++ committee members say they value, and what the process actually produces. Will a new standard every three years make this better or worse? They do seem open to deprecating things that don't work. You might enjoy the 2014 talk, called "The Last Thing D Needs." I don't want to spoil the punchline, which actually struck me as kind of bittersweet, but Scott talked about the distinction that Fred Brooks made in "No Silver Bullet" between essential and accidental complexity. C++ d
Recommends noselasd · 2022-11 · on “Rust in the 6.2 kernel”
> You cannot say the same thing about Rust. At least not yet. My fear is it's _very_ easy to fall in to the same trap as C++ has, and become a big mess. Scott Meyers have a very nice talk here: [this video] about all these traps and pifalls that we have to deal with in C++. That said, I'm starting a bit with rust and enjoy it so a lot, especially the tooling alone is worth it - and if I never have to write another line of C++, I would be very happy (ofc the real world argues I have a lot of C++ code that will need maintenance).
Recommends nordsieck · 2023-06 · on “Never trust a programmer who says they know C++”
I'll just leave this fantastic talk here: The Last Thing D Needs - Scott Meyers (2014) [this video] The C++ type system really is quite... complicated.
Cites mananaysiempre · 2023-07 · on “Why I use the D programming language for scripting (2021)”
It is definitely related to C++ (both in ideology and in participants) and AFAIU even more features, but, for example, Scott Meyers views it[1] as having less random stupid inconsistencies than C++. [1] [this video]
Cites Kranar · 2023-12 · on “Talking with the Inventor of C++”
I'd say a lot of this is a form of survivorship bias. I've programmed in C++ since the mid 90s so I am used to a lot of C++'s issues, but I also run a company and have to train new engineers and I see first hand the absolute nightmare that a lot of people encounter learning this language and it's demoralizing. While to me a lot of this is stuff I managed to figure out, I also understand that for many new developers this is just crap that no one should have to deal with in 2023. Lack of a good way to build third party libraries, build times that are astronomical and a true productivity killer, error messages that are entirely unhelpful and can produce giant walls of text for the most trivial
Cites vlovich123 · 2024-03 · on “C++ Safety, in Context”
Instead of defensiveness, why not talk about the ways in which the C++ committee is changing how they're operating (or even leaving ISO) and changing their culture to shore up these things. Look at past Scott Meyers talks (e.g. [1]). He highlights how the committee has arbitrary set of principles that can be applied to justify or reject any proposal and the inconsistencies in the language are a reflection of this. This isn't a problem of the language itself but rather that it's design by committee with 4 major front-end implementations (Intel, MSVC, Clang, GCC although I believe Intel is standardizing on the Clang front-end at least). Organizational issues like that are tough to spot but it'