Hacker News Reader

Comment by dmunoz | Hacker News Reader

I watched the talk live. I'll throw this out there just to see if anyone disagrees or has a different perspective.

It's basically Scott bashing C++ in his incredibly informed style. He shares some of the parts of C++ that everybody hates: the gotchas. This is what he has been doing for a few decades now with his Effective C++ series.

The conclusion was that the last thing D needs is someone like him. Someone to explain D like he has had to in his Effective C++ series and talks. Some of the crowd comments that D doesn't need this because it has less gotchas.

I admit to being let down by the talk mostly due to my expectations of what this talk could be about. I was massively excited to see Scott give a presentation about D. In the end, it was hardly about D.

View on HN

I think the higher-level point is that the D community needs to actively work to avoid needing someone like him. Changes to the language need to be evaluated not just on whether they improve things in the short run, but also on if they're adding things that in the long run will interact in weird and confusing ways with seemingly unrelated features.

Not at all ! The conclusion is D does not need him. If fact, D should not need someone like him. C++ needs Scott because C++ is not consistant, and with this talk he wanted to show us that if D makes the things the right way, we will not need him.

Wow, I am pleasantly surprised to hear that Scott Meyers agrees with me on this. I've read 2 of Meyers books (a long time ago, granted), and recently it occurred to me that the reason C++ needs Scott Meyers is that C++ is such a clusterfuck (edit: my word, not Scott's -- I'm in no way trying to put words in his mouth).

In no way is that to take away from Meyers. There'd be no hope without him. (And, as he apparently said in this talk, he agrees with me).

This is why I place so much hope in Rust. I want a language that lets me control memory that is not a clusterfuck. C will do, actually. But if Rust can pull off its goals, it will be a home run. (D is in the mix too, but from what I hear, the standard library uses relies on GC so much that it's not practical to do much without GC).

I think that's what "the last Thing D needs" means. Not the final piece. Rather, what people mean when they say "The last thing X needs is Y", they mean that X does not need Y. I make mention of this because the GP comment says the last thing D needs and you say "Not at all" and then go on to say effectively that the last thing D needs is Scott.

So, a lot of confusion in terms of wording, I think.

It's one of those tricky phrases that throws off foreign speakers. Many English learners would assume "the last thing X needs is Y" would mean "eventually X will need Y".

Indeed, my bad, there is a misunderstanding.

I remember when I did C++ for a few years, long ago. I used to reread the Effective series of books every few months. I realize that C++ has use cases, but the pain... I'll buy Meyers a beer if I ever see him.

The frustrating thing about this type of talk is that early on, you get the point that there's a lot of confusing and counterintuitive rules about how C++ behaves, and you spend the rest of the talk waiting for the litany of point-proving gotchas to finish. I figured that at the end, there would be some insight as to a particular language feature or design principle that was behind all these gotchas, but the primary insight appears to just be "C++ is hard, D shouldn't be."

He did provide the design behind "these gotchas." It is at 43:40

As for the specific examples which he brings up, those also get the specific goal stated as to why C++ has that strange condition.

Essentially, I don't know what you are complaining about.

Well, I'll fess up to not making it to 43:40. I got about 20 minutes in and, wondering if the whole talk was going to consist of examples of unpredictable C++ behaviors, I came to this comment thread and saw dmunoz' summary, so I gave up.

I just loaded it up again and went to 43:40 and yes, that's a good conclusion: the thing D doesn't need is an overly-broad list of design principles. I do think he could have come to that conclusion a lot quicker and with a LOT fewer examples.

Well, the examples were the content of the talk. He didn't need the examples at all, but they demonstrate a severity of the problem. And to that point the talk needed to be slow so that one can try and answer the question, if the answer was just given it is harder to see the difficulty presented.

I also must confess, I didn't watch the video. I was there, so there is a good chance the presentation doesn't translate well to video in terms of speed of content.

Reply on news.ycombinator.com