4 ms·

Scott Meyers: The Last Thing D Needs [video]

37 points by andralex 12y ago

lmm 12y ago
I gave this 10 minutes and there wasn't any content up to that point. Anyone have a transcript of the actual meat?
- dmunoz 12y ago
  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.
  - Munrek 12y ago
    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.
    - jasonlotito 12y ago
      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.
      - Munrek 12y ago
        Indeed, my bad, there is a misunderstanding.
      - yongjik 12y ago
        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".
    - charlieflowers 12y ago
      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).
  - plorkyeran 12y ago
    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.
  - hamburglar 12y ago
    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_the_great 12y ago
      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.
      - hamburglar 12y ago
        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.
        he_the_great 12y ago
        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.
  - BugBrother 12y ago
    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.
- he_the_great 12y ago
  3:55 "It is important to have some information on someone's perspective when they speak, because obviously that is going to color the opinions that they have."
kolev 12y ago
Nice and entertaining! I will definitely use this talk as an example of why kids shouldn't start learning programming with C++ (just in the last couple of months I had both my sister and a friend consider it for their kids). Although, maybe those who survive will become outstanding developers.
nly 12y ago
Great talk, and a satisfying introspective side to Meyers compared to his usual "Meyers explains it all" talks and books (which frankly, have been controversial in some respects in glossing over the "tool use" complexity to enable readers/viewers to reach the "tool application" side of C++). That said, you can never win... a couple of the C++ examples in this talk could have used a few extra words of explanation and rationale, but he erred on the side of not losing the audience, which is good.

37 points by andralex 12y ago

lmm 12y ago

I gave this 10 minutes and there wasn't any content up to that point. Anyone have a transcript of the actual meat?

dmunoz 12y ago
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.
- Munrek 12y ago
  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.
  - jasonlotito 12y ago
    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.
    - Munrek 12y ago
      Indeed, my bad, there is a misunderstanding.
    - yongjik 12y ago
      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".
  - charlieflowers 12y ago
    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).
- plorkyeran 12y ago
  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.
- hamburglar 12y ago
  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_the_great 12y ago
    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.
    - hamburglar 12y ago
      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.
      - he_the_great 12y ago
        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.
- BugBrother 12y ago
  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.
he_the_great 12y ago
3:55 "It is important to have some information on someone's perspective when they speak, because obviously that is going to color the opinions that they have."

kolev 12y ago

Nice and entertaining! I will definitely use this talk as an example of why kids shouldn't start learning programming with C++ (just in the last couple of months I had both my sister and a friend consider it for their kids). Although, maybe those who survive will become outstanding developers.

nly 12y ago

Great talk, and a satisfying introspective side to Meyers compared to his usual "Meyers explains it all" talks and books (which frankly, have been controversial in some respects in glossing over the "tool use" complexity to enable readers/viewers to reach the "tool application" side of C++). That said, you can never win... a couple of the C++ examples in this talk could have used a few extra words of explanation and rationale, but he erred on the side of not losing the audience, which is good.