6 ms·

Having written C++ for 30 years now, which is 75% of my life, I don't disagree from a personal point of view. However, at one point I was teaching programming

Having written C++ for 30 years now, which is 75% of my life, I don't disagree from a personal point of view. However, at one point I was teaching programming at the university. At that point you realize that C++ is .. huge. It may be fine for me, but is it the right choice for someone starting out? That said I do love new languages personally. I like to study how they do things. I found that Clojure had nearly the exact concurrency model I prefer to use in C++, and much nicer metaprogramming. As a result, I use it for all web stuff these days.

pjmlp 5y ago
It is PL/I style of huge, however the more time I spend in other ecosystems, they aren't that small either. I would fail a C++20 pub quizz, but I surely wouldn't fair much better if the questions would be about Java 17, Python 3.9, C# 10, .... including runtimes and standard libraries during their existence.
- FpUser 5y ago
  >"I would fail a C++20 pub quizz" Same here. It does not preclude creating high quality products though. I learn / fish out of my memory features on on need basis. Due to writing software for the last 40 years I have very good understanding what should be available and where but remember everything in multiple languages in detail is pure insanity. And in my opinion that knowledge is not what defines being good programmer.
  - thrasumachos 5y ago
    The thing I find almost impossible to store in my own memory is which C++ version a feature was added in, so when working on a C++14 codebase, I write class template parameter deduction dependent code and then have to check CPP Reference to see why I was wrong. I agree that memorizing gobs of this stuff isn’t important.
    - pjmlp 5y ago
      Same here, but also applies to other languages as well, sigh.
- tonyedgecombe 5y ago
  I think the main difference is languages like C# don't have the foot guns that C++ does. You can start using them and write reasonable code straight away. I always felt with C++ you need to know a lot before you write your first line of code.
  - pjmlp 5y ago
    They do actually, like semantics of variables declared in foreach loops, how closures are captured, some of the runtime changes that require appconfig settigs for the old behavior, for example.
  - titzer 5y ago
    I've never used a programming language that is as hostile to programmers who have bugs as C++.
    - pjmlp 5y ago
      C is worse.
      - tialaramex 5y ago
        I'm not sure that's true. C's simplicity helps it out here. Ultimately when everything is on fire, what's running isn't C or C++ but machine code. So, worst case in either scenario you're looking at the machine code. But the correspondence between your C++ and the machine code is far worse than for C. In your C program a lot of closing curly braces don't result in any code being emitted, but in C++ lots of the machine code can be attributed to the innocuous looking closing curly braces. Every local leaving scope calls its destructors. C++ doesn't actually "de-sugar" syntactic sugar in a consistent way. So, while you know your ranged for is in some sense sugar for a traditional C-style indexed for loop, you can't show that loop and aren't intended to. But this means a further loss of correspondence. In both cases the compiler is going to emit the same code, it's not stupid, this is the same operation, with more or less sugar. But the machine code looks a lot more like the indexed for loop. I like for each type loops, iterator adaptors, and so on, if I never write another traditional indexed for loop in my life that'd be fine, but if the world is mysteriously on fire and I need to understand why, the nice sugar is not a good model for what the machine was actually doing. Also, template meta-programmed constants. Your C++ program may have a difficult to understand bug at compile time. Yes, the C-pre-processor is terrible here, but that's technically shared by both languages, I'm talking about constexpr template madness. For example maybe at compile time your C++ program should parse JSON and behave differently based on the results. That's a real thing.

pjmlp 5y ago

It is PL/I style of huge, however the more time I spend in other ecosystems, they aren't that small either. I would fail a C++20 pub quizz, but I surely wouldn't fair much better if the questions would be about Java 17, Python 3.9, C# 10, .... including runtimes and standard libraries during their existence.

FpUser 5y ago
>"I would fail a C++20 pub quizz" Same here. It does not preclude creating high quality products though. I learn / fish out of my memory features on on need basis. Due to writing software for the last 40 years I have very good understanding what should be available and where but remember everything in multiple languages in detail is pure insanity. And in my opinion that knowledge is not what defines being good programmer.
- thrasumachos 5y ago
  The thing I find almost impossible to store in my own memory is which C++ version a feature was added in, so when working on a C++14 codebase, I write class template parameter deduction dependent code and then have to check CPP Reference to see why I was wrong. I agree that memorizing gobs of this stuff isn’t important.
  - pjmlp 5y ago
    Same here, but also applies to other languages as well, sigh.
tonyedgecombe 5y ago
I think the main difference is languages like C# don't have the foot guns that C++ does. You can start using them and write reasonable code straight away. I always felt with C++ you need to know a lot before you write your first line of code.
- pjmlp 5y ago
  They do actually, like semantics of variables declared in foreach loops, how closures are captured, some of the runtime changes that require appconfig settigs for the old behavior, for example.
- titzer 5y ago
  I've never used a programming language that is as hostile to programmers who have bugs as C++.
  - pjmlp 5y ago
    C is worse.
    - tialaramex 5y ago
      I'm not sure that's true. C's simplicity helps it out here. Ultimately when everything is on fire, what's running isn't C or C++ but machine code. So, worst case in either scenario you're looking at the machine code. But the correspondence between your C++ and the machine code is far worse than for C. In your C program a lot of closing curly braces don't result in any code being emitted, but in C++ lots of the machine code can be attributed to the innocuous looking closing curly braces. Every local leaving scope calls its destructors. C++ doesn't actually "de-sugar" syntactic sugar in a consistent way. So, while you know your ranged for is in some sense sugar for a traditional C-style indexed for loop, you can't show that loop and aren't intended to. But this means a further loss of correspondence. In both cases the compiler is going to emit the same code, it's not stupid, this is the same operation, with more or less sugar. But the machine code looks a lot more like the indexed for loop. I like for each type loops, iterator adaptors, and so on, if I never write another traditional indexed for loop in my life that'd be fine, but if the world is mysteriously on fire and I need to understand why, the nice sugar is not a good model for what the machine was actually doing. Also, template meta-programmed constants. Your C++ program may have a difficult to understand bug at compile time. Yes, the C-pre-processor is terrible here, but that's technically shared by both languages, I'm talking about constexpr template madness. For example maybe at compile time your C++ program should parse JSON and behave differently based on the results. That's a real thing.