4 ms·

Can't speak for Rust, and I imagine it makes more sense for them since it's a young language, but I wish the C++ folks would chill a bit and take their time a l

Can't speak for Rust, and I imagine it makes more sense for them since it's a young language, but I wish the C++ folks would chill a bit and take their time a little more; it's getting kind of ridiculous. They don't need to move fast and break things (which they literally have; see e.g. result_of and invoke_result). By the time the tooling across various platforms has finally had a chance to take a breath, they've already got the next version of the standard out, and it's getting hard to keep up with all their changes. I feel there's a better balance between the 13 years ('98->'11; '03 wasn't really a new standard) and the 3 years we have now. Maybe every 5-6 years?

usefulcat 7y ago
So maybe choose not to use the very newest features? That's what I've always done and it's worked quite well.
- mehrdadn 7y ago
  That's exactly what I do on my end, but it's more than annoying when I have to deal with other projects and I suddenly can't even compile them anymore until I upgrade my toolchain and learn what's basically a new language.
steveklabnik 7y ago
I don’t think that making the cycle time longer helps; I think making it shorter helps. There’s less pressure to put something in a specific release when they happen less frequently. You can, counter-intuitively, take your time. I know less about the exact details, but I also think that having something to play with helps; I believe that this is what’s going on with with the move towards more TSes before shipping spec text, right? Being able to try things out in nightly helps us a lot.
- mehrdadn 7y ago
  If your goal is to help improve C++, sure, a shorter cycle time is better. If your goal is to use the language as a communication mechanism... having it change constantly underneath you isn't helpful in my experience. And it's not necessary to release a new standard to let people try things out; you can let people play around with new features without iterating on them as formal standards.
  - steveklabnik 7y ago
    “Change constantly” is too broad; there are different kinds of changes. Stability is paramount.
    - mehrdadn 7y ago
      If you find it too broad then just narrow it down in your mind. You won't be left with the null set.
- weberc2 7y ago
  > There’s less pressure to put something in a specific release when they happen less frequently. I think this phrasing contradicts your point. Do you mean "more frequently", or am I missing something?
  - steveklabnik 7y ago
    I did, my mistake!
olliej 7y ago
You’re missing one of the major points in the post: making release cycles take a long time means that small features aren’t finalized for that long period either. You seem to be thinking that the compiler devs wait until a release is done to start implementing a release, which is not what happens. Part of the big benefit of releasing every three years is that it makes continuous development actually possible: compiler devs have a better idea of how stable things are, and so which things aren’t going to need to be completely reimplement in another 3 years. I do not understand where you get a “catch their breath” mentality - none of the modern c++ compilers have a three year cadence, most run with approximately annual major releases.
- mehrdadn 7y 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.
  - 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.

usefulcat 7y ago

So maybe choose not to use the very newest features? That's what I've always done and it's worked quite well.

mehrdadn 7y ago
That's exactly what I do on my end, but it's more than annoying when I have to deal with other projects and I suddenly can't even compile them anymore until I upgrade my toolchain and learn what's basically a new language.

steveklabnik 7y ago

I don’t think that making the cycle time longer helps; I think making it shorter helps. There’s less pressure to put something in a specific release when they happen less frequently. You can, counter-intuitively, take your time. I know less about the exact details, but I also think that having something to play with helps; I believe that this is what’s going on with with the move towards more TSes before shipping spec text, right? Being able to try things out in nightly helps us a lot.

mehrdadn 7y ago
If your goal is to help improve C++, sure, a shorter cycle time is better. If your goal is to use the language as a communication mechanism... having it change constantly underneath you isn't helpful in my experience. And it's not necessary to release a new standard to let people try things out; you can let people play around with new features without iterating on them as formal standards.
- steveklabnik 7y ago
  “Change constantly” is too broad; there are different kinds of changes. Stability is paramount.
  - mehrdadn 7y ago
    If you find it too broad then just narrow it down in your mind. You won't be left with the null set.
weberc2 7y ago
> There’s less pressure to put something in a specific release when they happen less frequently. I think this phrasing contradicts your point. Do you mean "more frequently", or am I missing something?
- steveklabnik 7y ago
  I did, my mistake!

olliej 7y ago

You’re missing one of the major points in the post: making release cycles take a long time means that small features aren’t finalized for that long period either. You seem to be thinking that the compiler devs wait until a release is done to start implementing a release, which is not what happens. Part of the big benefit of releasing every three years is that it makes continuous development actually possible: compiler devs have a better idea of how stable things are, and so which things aren’t going to need to be completely reimplement in another 3 years. I do not understand where you get a “catch their breath” mentality - none of the modern c++ compilers have a three year cadence, most run with approximately annual major releases.

mehrdadn 7y 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.
- 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.