Comment by mehrdadn
7 years ago
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.
Please give some specific examples and not just vague "problems".
Huh? What would that accomplish for you?
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.
1 reply →