4 ms·

I'm surprised that many comments here seem to have missed this bit of context: > One thing you need to know about me is that despite working on SumatraPDF C++

I'm surprised that many comments here seem to have missed this bit of context: > One thing you need to know about me is that despite working on SumatraPDF C++ code base for 16 years, I don’t know 80% of C++. I'm pretty sure that most "why don't you just use x…" questions are implicitly answered by it, with the answer being "because using x correctly requires learning about all of it's intricacies and edge-cases, which in turn requires understanding related features q, r, s… all the way to z, because C++ edge-case complexity doesn't exist in a vacuum".

throwaway2037 1y ago
I agree: This quote is the star of the show. I'll troll a little bit here: I thought to myself: "Finally, a humble C++ programmer. Really, they do exist... well, at least one."
- uncircle 1y ago
  There's two: > Even I can’t answer every question about C++ without reference to supporting material (e.g. my own books, online documentation, or the standard). I’m sure that if I tried to keep all of that information in my head, I’d become a worse programmer. -- Bjarne Stroustrup, creator of C++
  - vanderZwan 1y ago
    Bjarne has his moments - I like his saying that somewhere buried underneath all of C++'s complexity there's an elegant language struggling to get out, and I'm sympathetic to his frustrations and believe he does have good intentions there. But he can also contradict himself sometimes in this regard, because he also often uses a variation of calling C++ a language for "people who know what they are doing" as a sort of catch-all dismissal of critiques of its footguns. The whole problem is that very few people can claim to truly "know what they are doing" when it comes to all of C++' features and how they interconnect, dismissing that by (implicitly) telling people to just "git gud" is missing the point a bit. But again, he's only human and I do get the urge to get a bit defensive of your baby.
    - nxobject 1y ago
      There’s another slogan that also acts as catch-all dismissal - “easy things should be easy; hard things should be possible”. Yes, but the bar for “hard things” just happens to be frustratingly low compared to other languages - ie library programming that has enough genericity and robustness. To wit, this example.
      - throwaway2037 1y ago
        > easy things should be easy; hard things should be possible From many years ago, this was a Perl motto from Larry Warry. Is the original pontificator... or was it someone before him?
    - favorited 1y ago
      He also seems completely uninterested in finding that, "elegant language struggling to get out." He just asserts that it's there, as if its mere existence is a virtue. I think Herb Sutter is at least trying to find that elegant language, with his "syntax v2" project. It's one way to preserve compatibility with the incalculable amount of C++ in the wild, while also providing a simplified syntax with better defaults and fewer foot-guns. Of course, Herb isn't immune to making hand-wavy claims[0] of his own, but he seems to bring forward more good ideas than bad. [0] https://herbsutter.com/2025/03/30/crate-training-tiamat-un-calling-cthulhutaming-the-ub-monsters-in-c/ https://herbsutter.com/2025/03/30/crate-training-tiamat-un-c...
    - throwaway2037 1y ago
      > elegant language Are there any languages that would qualify and are in common use in industry? I'm not interested in some PL fantasy language that no one outside of academia uses. JavaScript, Python, Ruby, PHP (see double-ended hammer!), C, C++, C#, Java, Go, Rust all have numerous warts, but are heavily used in industry. None of them are particularly elegant in 2025. In the modern era, it is impossible to separate the language itself from the standard library. Even if the language is elegant, I am sure the standard library will have all kinds of awful warts (probably date/time) -- or vice versa.
jahnu 1y ago
30 year c++ veteran here. Also don’t know 80%. I used to know more but a combination of way better tooling and “modern” c++ and most importantly realising that thinking more about things other than the language details led to better software meant I have forgotten stuff I used to know.
- vanderZwan 1y ago
  Sounds like the 80/20 rule but applied to mastering C++ features. Which honestly makes sense to me, and doesn't even feel C++ specific, really. It just becomes more applicable the bigger and more complicated a language gets.

throwaway2037 1y ago

I agree: This quote is the star of the show. I'll troll a little bit here: I thought to myself: "Finally, a humble C++ programmer. Really, they do exist... well, at least one."

uncircle 1y ago
There's two: > Even I can’t answer every question about C++ without reference to supporting material (e.g. my own books, online documentation, or the standard). I’m sure that if I tried to keep all of that information in my head, I’d become a worse programmer. -- Bjarne Stroustrup, creator of C++
- vanderZwan 1y ago
  Bjarne has his moments - I like his saying that somewhere buried underneath all of C++'s complexity there's an elegant language struggling to get out, and I'm sympathetic to his frustrations and believe he does have good intentions there. But he can also contradict himself sometimes in this regard, because he also often uses a variation of calling C++ a language for "people who know what they are doing" as a sort of catch-all dismissal of critiques of its footguns. The whole problem is that very few people can claim to truly "know what they are doing" when it comes to all of C++' features and how they interconnect, dismissing that by (implicitly) telling people to just "git gud" is missing the point a bit. But again, he's only human and I do get the urge to get a bit defensive of your baby.
  - nxobject 1y ago
    There’s another slogan that also acts as catch-all dismissal - “easy things should be easy; hard things should be possible”. Yes, but the bar for “hard things” just happens to be frustratingly low compared to other languages - ie library programming that has enough genericity and robustness. To wit, this example.
    - throwaway2037 1y ago
      > easy things should be easy; hard things should be possible From many years ago, this was a Perl motto from Larry Warry. Is the original pontificator... or was it someone before him?
  - favorited 1y ago
    He also seems completely uninterested in finding that, "elegant language struggling to get out." He just asserts that it's there, as if its mere existence is a virtue. I think Herb Sutter is at least trying to find that elegant language, with his "syntax v2" project. It's one way to preserve compatibility with the incalculable amount of C++ in the wild, while also providing a simplified syntax with better defaults and fewer foot-guns. Of course, Herb isn't immune to making hand-wavy claims[0] of his own, but he seems to bring forward more good ideas than bad. [0] https://herbsutter.com/2025/03/30/crate-training-tiamat-un-calling-cthulhutaming-the-ub-monsters-in-c/ https://herbsutter.com/2025/03/30/crate-training-tiamat-un-c...
  - throwaway2037 1y ago
    > elegant language Are there any languages that would qualify and are in common use in industry? I'm not interested in some PL fantasy language that no one outside of academia uses. JavaScript, Python, Ruby, PHP (see double-ended hammer!), C, C++, C#, Java, Go, Rust all have numerous warts, but are heavily used in industry. None of them are particularly elegant in 2025. In the modern era, it is impossible to separate the language itself from the standard library. Even if the language is elegant, I am sure the standard library will have all kinds of awful warts (probably date/time) -- or vice versa.

jahnu 1y ago

30 year c++ veteran here. Also don’t know 80%. I used to know more but a combination of way better tooling and “modern” c++ and most importantly realising that thinking more about things other than the language details led to better software meant I have forgotten stuff I used to know.

vanderZwan 1y ago
Sounds like the 80/20 rule but applied to mastering C++ features. Which honestly makes sense to me, and doesn't even feel C++ specific, really. It just becomes more applicable the bigger and more complicated a language gets.