2 ms·

No... there's more to programming than just having a shiny new compiler. VS2017 for example had problems that held me back at VS2015, so I couldn't upgrade unti

No... there's more to programming than just having a shiny new compiler. VS2017 for example had problems that held me back at VS2015, so I couldn't upgrade until I got to VS2019, but meanwhile projects moved on. The 1-year period you're imagining was really a ~4-year period where the language syntax had changed, the stdlib had changed, and projects had moved on, so I couldn't even compile things. Heck, I couldn't even read the language anymore, let alone worry about all the new stuff in stdlib. And it's not like they've been only adding small features every 3 years. If they were then my position would be different too. But small features being small, people can live without them. Not having them is a lot better than not being able to use the language at all.

shaklee3 7y ago
Please give some specific examples and not just vague "problems".
- mehrdadn 7y ago
  Huh? What would that accomplish for you?
  - olliej 7y ago
    You just said, 'I had a whole bunch of problems', and that's why I believe the standard should change more slowly. You didn't actually say what those problems were, you didn't provide any evidence that any bugs you hit were as a result of an increased standardization rate. You're also assuming that somehow spending more time with unstable language features will result in fewer problems, which is something where we know you're wrong. Because we've seen what happens when a longer cycle exists, we know your claim that the compilers will be less buggy is exactly wrong.
    - mehrdadn 7y ago
      > you didn't provide any evidence that any bugs you hit were as a result of an increased standardization rate. You misunderstood the argument. The claim was not that the VS problems were due to the increased standardization rate. They weren't C++-related at all. Rather, the problem was that I couldn't move onto 2017 due to unrelated VS problems, even though I needed to move onto it in order to be able to work on C++ projects that had already started using C++17. > You're also assuming that somehow spending more time with unstable language features will result in fewer problems, which is something where we know you're wrong. Because we've seen what happens when a longer cycle exists, we know your claim that the compilers will be less buggy is exactly wrong. Again, I was not saying compiler bugs increase when you rush the standard. See above.

shaklee3 7y ago

Please give some specific examples and not just vague "problems".

mehrdadn 7y ago
Huh? What would that accomplish for you?
- olliej 7y ago
  You just said, 'I had a whole bunch of problems', and that's why I believe the standard should change more slowly. You didn't actually say what those problems were, you didn't provide any evidence that any bugs you hit were as a result of an increased standardization rate. You're also assuming that somehow spending more time with unstable language features will result in fewer problems, which is something where we know you're wrong. Because we've seen what happens when a longer cycle exists, we know your claim that the compilers will be less buggy is exactly wrong.
  - mehrdadn 7y ago
    > you didn't provide any evidence that any bugs you hit were as a result of an increased standardization rate. You misunderstood the argument. The claim was not that the VS problems were due to the increased standardization rate. They weren't C++-related at all. Rather, the problem was that I couldn't move onto 2017 due to unrelated VS problems, even though I needed to move onto it in order to be able to work on C++ projects that had already started using C++17. > You're also assuming that somehow spending more time with unstable language features will result in fewer problems, which is something where we know you're wrong. Because we've seen what happens when a longer cycle exists, we know your claim that the compilers will be less buggy is exactly wrong. Again, I was not saying compiler bugs increase when you rush the standard. See above.