4 ms·

Stroustrup has written quite a bit fighting against complexity: > There are two fundamental ways of approaching the unavoidable uncertainty in a design: > • a

Stroustrup has written quite a bit fighting against complexity: > There are two fundamental ways of approaching the unavoidable uncertainty in a design: > • add “improvements” until everybody feels well served > • cut until there is nothing left to cut and all there is left is principled and fundamental > After both approaches, experience will show the need for changes (pre-release) and additions (all we can do post-release). I clearly favor the second approach and consider it proper engineering based on principles and feedback. I consider the former hacking and politics. In a standards process, compromises are necessary, but we must try to ensure than compromises are not between irreconcilables or just union-of-features bloat. He continues: > Stability is a feature as well as a serious design constraint. [....] I can summarize most people’s attitude: > • “C++ is too complex. We need to make it smaller, simpler, and cleaner. > • And please add these two features. > • And whatever you do, don’t break my code!” Source: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1962r0.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p196...

weberc2 7y ago
> I can summarize most people’s attitude I’m skeptical that there is a significant body of critics that share these patently conflicting views. More likely there are different groups who each value one of these, or more likely still, lots of individuals like me who are fine with specific, entirely consistent concessions from each of these major categories. For example, I would like to see C++ support some sane build and package ecosystem and I’m ok if it breaks my projects. I would also be happy to do away with the C compatibility requirements. It would probably be too much to ask to re-evaluate every design decision that was predicated on C compatibility, but I would be okay with reevaluating them gradually over decades, deprecating language features here and there. In general we need to get rid of the idea that we only need to write software once and then every future version of the toolchain will support it. Instead I would like to see a world where the language changes gradually and project maintainers simply have to make small, almost mechanical changes every 5 years or so.
- d1zzy 7y ago
  > I’m skeptical that there is a significant body of critics that share these patently conflicting views. If I take a serious look at my own C++ needs I do find myself having those contradicting views. Essentially what I find is that for areas of the language that do not pertain much to my day to day work I'm fine with "simplifying" (even if it means removing features, because I don't need those features) but for the things I work on (which I'll be the first to admit are likely quite rare in the general C++ population) it would be a deal breaker if the features that I use but most other people don't get removed.
  - weberc2 7y ago
    Those aren’t contradictory views; you are consistent, but your views aren’t consistent with those of the “other people” you refer to, which is my point.
- matthewowen 7y ago
  I think it depends on how you frame it. "If we could just add this one feature, we could get rid of these five crufty features that I think are obviated by it" is a fairly common sentiment in my experience.

weberc2 7y ago

> I can summarize most people’s attitude I’m skeptical that there is a significant body of critics that share these patently conflicting views. More likely there are different groups who each value one of these, or more likely still, lots of individuals like me who are fine with specific, entirely consistent concessions from each of these major categories. For example, I would like to see C++ support some sane build and package ecosystem and I’m ok if it breaks my projects. I would also be happy to do away with the C compatibility requirements. It would probably be too much to ask to re-evaluate every design decision that was predicated on C compatibility, but I would be okay with reevaluating them gradually over decades, deprecating language features here and there. In general we need to get rid of the idea that we only need to write software once and then every future version of the toolchain will support it. Instead I would like to see a world where the language changes gradually and project maintainers simply have to make small, almost mechanical changes every 5 years or so.

d1zzy 7y ago
> I’m skeptical that there is a significant body of critics that share these patently conflicting views. If I take a serious look at my own C++ needs I do find myself having those contradicting views. Essentially what I find is that for areas of the language that do not pertain much to my day to day work I'm fine with "simplifying" (even if it means removing features, because I don't need those features) but for the things I work on (which I'll be the first to admit are likely quite rare in the general C++ population) it would be a deal breaker if the features that I use but most other people don't get removed.
- weberc2 7y ago
  Those aren’t contradictory views; you are consistent, but your views aren’t consistent with those of the “other people” you refer to, which is my point.
matthewowen 7y ago
I think it depends on how you frame it. "If we could just add this one feature, we could get rid of these five crufty features that I think are obviated by it" is a fairly common sentiment in my experience.