3 ms·

Varies, but it is a layer of stress. I have around 10y in a field where getting rid of C++ is close to impossible and I'm more excited about maybe changing area

Varies, but it is a layer of stress. I have around 10y in a field where getting rid of C++ is close to impossible and I'm more excited about maybe changing areas than spending ten more working with C++ codebases. The things that affect me the most are: - No standard / user friendly tooling: there is no package manager, getting dependencies "as easy as copying a header from this github repo" is messy, is a liability, generates toil, etc. - The language is very complex, i.e. there are 7 different ways just to declare a variable (I'm not even discussing templates, optionals and what not) and more often than not C++ projects spans years or decades, there is a natural mix of styles from people across different generations on what is "modern" and it's a sore to my eyes. At every release rarely things are removed from the language, but there is always something added. At every company, the subset of what features are reasonable to use, understood and well maintained can change drastically. That might be a company problem, not a language one, but it's something sistematic enough that I would say it's a language thing. - Every language has its gotchas, but with beginners interested in using fancy features of the language, the surface area is just too big. I've read once on the blog of a former member of the C++ technical steering committee, that at his best, when actively working with the committee and focused on this, he maybe knew 50% of the language spec. What are the odds of the common folk knowing the pitfalls and good practices of the language and that staying relevant in 5-10 years? Even though C++ is the language programmed the most in my career and I can appreciate how nice it is at the right conditions, I've come to accept that the tenets of the language, the way the TSC sees it (stability, backward compatibility, performance) no longer resonate with me and I come to appreciate the consistency, simplicity and ease of use of other projects, there is a bigger world out there and the pond of C++ issues is a place I would rather leave behind.

protomolecule 3y ago
"I've read once on the blog of a former member of the C++ technical steering committee, that at his best, when actively working with the committee and focused on this, he maybe knew 50% of the language spec." This isn't relevant. The standard is for compiler writers and library writers who use advanced meta-programming. "What are the odds of the common folk knowing the pitfalls and good practices of the language and that staying relevant in 5-10 years?" That depends. Some pitfalls just disappear like std::auto_ptr but I doubt anyone complains. Big changes came with c++11 and c++20, that is once in 10 years. While c++11 added move semantics and new initialization syntax that are somewhat complicated and hard to ignore, c++20's additions only make you glad that your life has become easier.
- DoctorDabadedoo 3y ago
  "This isn't relevant. The standard is for compiler writers and library writers who use advanced meta-programming." It is. It is a metric of how ungodly complex the language is. You can infer by this that having a comprehensive mental model of the language is difficult, do's and don'ts are all over the place and even a thing "simple" as a cast can lead to UB, but this flies under the radar of a lot of developers. You don't need to be a compiler engineer to make good use of such information. "That depends. Some pitfalls just disappear like std::auto_ptr but I doubt anyone complains. Big changes came with c++11 and c++20, that is once in 10 years. While c++11 added move semantics and new initialization syntax that are somewhat complicated and hard to ignore, c++20's additions only make you glad that your life has become easier." True, but it takes time to be proeficient with the changesets, for the projects to be transitioned to newer versions, if they are at all, and then to map what is valid in which version if there are reworks everywhere (e.g. I'm involved with some that are still c++14, "Do we have structured bindings available here? Oh, no, too bad."). I appreciate thing gettings better/easier, but c++ seems to be all over the place (just checked the compiler support for c++20 and there is still partial support for some features in major compilers, even though work on c++23 has already started).
  - protomolecule 3y ago
    It is ungodly complex, but no one needs to understand all this complexity just to use the language to write application code. "do's and don'ts are all over the place and even a thing "simple" as a cast can lead to UB" And most of these things were present in the first revision of the C++ standard or even in C. "You don't need to be a compiler engineer to make good use of such information." Why do you think that a programmer has to learn C++ by reading the standard? One does need to have a good mental model of what's happening but it's enough to have a much much simpler mental model than the standard. "and then to map what is valid in which version" That's where skills acquired 5-10 years ago are most relevant)
    - DoctorDabadedoo 3y ago
      Application devs don't need to know the spec, but someone in the committee having a hard time of knowing the language in full is an interesting fact of how complex the language itself is. "Why do you think that a programmer has to learn C++ by reading the standard?" If your application seg faults due to an ill type deduction caused by `auto`, why did it fail? What kind of type deductions auto covers? Experience by trial and error will hardly help you here. End user developers will acquire that knowledge probably by reading digested material from experts either focused on language tidbits or working closely to the standard (Effective C++, Effective Modern C++, blogs, etc.), the root source is still the spec, the more complex the spec is, by transitivity, the more complex is anything that comes out of it. I guess the bottomline is that we agree the language is complex and I'll leave it at that.

protomolecule 3y ago

"I've read once on the blog of a former member of the C++ technical steering committee, that at his best, when actively working with the committee and focused on this, he maybe knew 50% of the language spec." This isn't relevant. The standard is for compiler writers and library writers who use advanced meta-programming. "What are the odds of the common folk knowing the pitfalls and good practices of the language and that staying relevant in 5-10 years?" That depends. Some pitfalls just disappear like std::auto_ptr but I doubt anyone complains. Big changes came with c++11 and c++20, that is once in 10 years. While c++11 added move semantics and new initialization syntax that are somewhat complicated and hard to ignore, c++20's additions only make you glad that your life has become easier.

DoctorDabadedoo 3y ago
"This isn't relevant. The standard is for compiler writers and library writers who use advanced meta-programming." It is. It is a metric of how ungodly complex the language is. You can infer by this that having a comprehensive mental model of the language is difficult, do's and don'ts are all over the place and even a thing "simple" as a cast can lead to UB, but this flies under the radar of a lot of developers. You don't need to be a compiler engineer to make good use of such information. "That depends. Some pitfalls just disappear like std::auto_ptr but I doubt anyone complains. Big changes came with c++11 and c++20, that is once in 10 years. While c++11 added move semantics and new initialization syntax that are somewhat complicated and hard to ignore, c++20's additions only make you glad that your life has become easier." True, but it takes time to be proeficient with the changesets, for the projects to be transitioned to newer versions, if they are at all, and then to map what is valid in which version if there are reworks everywhere (e.g. I'm involved with some that are still c++14, "Do we have structured bindings available here? Oh, no, too bad."). I appreciate thing gettings better/easier, but c++ seems to be all over the place (just checked the compiler support for c++20 and there is still partial support for some features in major compilers, even though work on c++23 has already started).
- protomolecule 3y ago
  It is ungodly complex, but no one needs to understand all this complexity just to use the language to write application code. "do's and don'ts are all over the place and even a thing "simple" as a cast can lead to UB" And most of these things were present in the first revision of the C++ standard or even in C. "You don't need to be a compiler engineer to make good use of such information." Why do you think that a programmer has to learn C++ by reading the standard? One does need to have a good mental model of what's happening but it's enough to have a much much simpler mental model than the standard. "and then to map what is valid in which version" That's where skills acquired 5-10 years ago are most relevant)
  - DoctorDabadedoo 3y ago
    Application devs don't need to know the spec, but someone in the committee having a hard time of knowing the language in full is an interesting fact of how complex the language itself is. "Why do you think that a programmer has to learn C++ by reading the standard?" If your application seg faults due to an ill type deduction caused by `auto`, why did it fail? What kind of type deductions auto covers? Experience by trial and error will hardly help you here. End user developers will acquire that knowledge probably by reading digested material from experts either focused on language tidbits or working closely to the standard (Effective C++, Effective Modern C++, blogs, etc.), the root source is still the spec, the more complex the spec is, by transitivity, the more complex is anything that comes out of it. I guess the bottomline is that we agree the language is complex and I'll leave it at that.