4 ms·

> Maybe it’s time to stop blaming devs and instead blame the language? Ah, blaming the tools: the Hallmark of a master. Take a moment to think about the probl

> Maybe it’s time to stop blaming devs and instead blame the language? Ah, blaming the tools: the Hallmark of a master. Take a moment to think about the problem. You're in a multi-team project, with a few millions lines of code. You're paid to deliver results and meet the client's requirements, and you're already behind schedule. Suddenly the C++ standard committee releases a new C++ standard. What are you going to do? Are you going to a) continue working on your tickets, or b) are you going to drop everything to spend weeks updating tooling, projects, dependencies, and put up a series of workshops with the purpose of getting everyone onboard the new shiny toy? And did you noticed that option b) adds absolutely no value at all? It's great that you can flip a flag and turn your hello world project into a C++20 project with no work at all, but real world teams that are in the business of outputting real world production-ready code requires a bit more caution. For instance, I still recall from a previous project I worked with how a n upgrade to C++14 led a dependency to over-eagerly jump head-on to constexpr which caused weird and non-trivial linking errors that took a week or so to sort out. And constexpr wasn't a new addition in C++14.

tux3 4y ago
Upgrading to C++14 - a minor release compared to C++11 and C++17 - caused a weeksworth of weird, nontrivial linking errors. Do you think that's an unavoidable law, or is it something accidental that could have gone better? Would you say a similar minor upgrade of the language version in other languages would have also caused a week of similar hard to debug errors, for a project of the same size? I'm curious who you blame, if you don't blame the tools. You could try to blame people. Or one might say it's just how things are and we can't do better. I'm just not sure if you see this as unavoidable, or if it's something else that makes you say that? You got me curious.
- arinlen 4y ago
  > Do you think that's an unavoidable law, or is it something accidental that could have gone better? It was the result of having to develop production code in the real world, reusing real world production code developed by third-parties. In my particular case it just so happened that the upstream dependency exported interface headers that conditionally defined stuff with C++14 features in spite of what shipped with their binaries. Stuff using constexpr ultimately resulted in tons of hard to track linking errors. > Would you say a similar minor upgrade of the language version in other languages would have also caused a week of similar hard to debug errors, for a project of the same size? This was not a C++ problem. This was a problem caused by the way this particular project was designed to toggle C++14 features when they should not be toggled. Just because problems emerge when updating a project to the next language version, that does not mean the language is held to blame. This is one of the reasons why I firmly believe half the people in this thread talking crap about software updates and bumping programming language versions are quite frankly talking about stuff they know nothing about and have zero real world experience. There's far more stuff going on in a language upgrade than flipping a switch and rebuilding a project, specially if upstream dependencies made some less-than-advisable decisions on how to release their work.
  - tux3 4y ago
    Thanks, appreciate the perspective
  - tcoff91 4y ago
    So you were linking against prebuilt libraries, and you had third party headers for those libraries that were doing some constexpr stuff that was breaking linking because the prebuilts no longer matched the headers? In C++ if you aren’t able to build your entire stack of dependencies from source you are gonna have a bad time like this at some point. Any prebuilt libraries you depend on better be pure C, headers included.
plorkyeran 4y ago
My experience with migrating real-world projects incrementally from C++98 -> C++20 has been that it is typically closer to a day of work to get everything working with the new standard, and that the benefits have been enormous. `if constexpr` is a particularly standout example of something which has turned things which would have been a week's worth from a C++ expert into something doable in an hour by a junior developer.

tux3 4y ago

Upgrading to C++14 - a minor release compared to C++11 and C++17 - caused a weeksworth of weird, nontrivial linking errors. Do you think that's an unavoidable law, or is it something accidental that could have gone better? Would you say a similar minor upgrade of the language version in other languages would have also caused a week of similar hard to debug errors, for a project of the same size? I'm curious who you blame, if you don't blame the tools. You could try to blame people. Or one might say it's just how things are and we can't do better. I'm just not sure if you see this as unavoidable, or if it's something else that makes you say that? You got me curious.

arinlen 4y ago
> Do you think that's an unavoidable law, or is it something accidental that could have gone better? It was the result of having to develop production code in the real world, reusing real world production code developed by third-parties. In my particular case it just so happened that the upstream dependency exported interface headers that conditionally defined stuff with C++14 features in spite of what shipped with their binaries. Stuff using constexpr ultimately resulted in tons of hard to track linking errors. > Would you say a similar minor upgrade of the language version in other languages would have also caused a week of similar hard to debug errors, for a project of the same size? This was not a C++ problem. This was a problem caused by the way this particular project was designed to toggle C++14 features when they should not be toggled. Just because problems emerge when updating a project to the next language version, that does not mean the language is held to blame. This is one of the reasons why I firmly believe half the people in this thread talking crap about software updates and bumping programming language versions are quite frankly talking about stuff they know nothing about and have zero real world experience. There's far more stuff going on in a language upgrade than flipping a switch and rebuilding a project, specially if upstream dependencies made some less-than-advisable decisions on how to release their work.
- tux3 4y ago
  Thanks, appreciate the perspective
- tcoff91 4y ago
  So you were linking against prebuilt libraries, and you had third party headers for those libraries that were doing some constexpr stuff that was breaking linking because the prebuilts no longer matched the headers? In C++ if you aren’t able to build your entire stack of dependencies from source you are gonna have a bad time like this at some point. Any prebuilt libraries you depend on better be pure C, headers included.

plorkyeran 4y ago

My experience with migrating real-world projects incrementally from C++98 -> C++20 has been that it is typically closer to a day of work to get everything working with the new standard, and that the benefits have been enormous. `if constexpr` is a particularly standout example of something which has turned things which would have been a week's worth from a C++ expert into something doable in an hour by a junior developer.