7 ms·

I went back and forth over email with Jonathan Blow a while back and my opinion is that C++ is moving in a direction where it addresses most of his concerns abo

I went back and forth over email with Jonathan Blow a while back and my opinion is that C++ is moving in a direction where it addresses most of his concerns about its suitability for game programming, though he doesn't agree. I wrote a few blog posts elaborating on why, starting with: http://blog.mattnewport.com/why-c17-is-the-new-programming-language-for-games-i-want/ http://blog.mattnewport.com/why-c17-is-the-new-programming-l... I should revisit the topic in light of the latest progress with C++ and to correct some errors in those posts but I continue to believe that C++ is getting better as a language for games. There is a somewhat legitimate argument that C++ is too complex but I don't believe you can make a convincing case that it justifies creating a whole new language (which will inevitably come with its own quirks, idiosyncracies and complexities) rather than engaging with the development of C++ itself.

interestingcpp 9y ago
Interesting; i think it’s fairly clear by now engaging with C++ is not going to lead to reduced complexity at all. When was the last time it removed support for a feature? That’s not what the language needs because it’s more interested in preserving existing code bases than it is at improving them (the latter being a huge effort, truly massive, so i understand the decision and don’t mean it as a slight in the least).
- mattnewport 9y ago
  Major influential figures in the C++ community (notably Bjarne Stroustrup and Herb Sutter) are very explicit about having a goal of simplifying everyday usage of C++ (make simple things simple). Watch any of Bjarne's talks over the last few years to see this is one of his main focuses. It's also recognized that backwards compatibility / not breaking existing code are very important however. Yes, that's a hard set of requirements to meet but I find it bizarre when I keep seeing people state that the C++ standards committee and the community in general don't care about simplicity and ease of use when those are literally the major topics of keynotes at every C++ conference of the last few years.
  - interestingcpp 9y ago
    Simplifying every day usage is entirely a different thing than simplifying the language. I’m not denying the inprovement in usage, just that you should expect the complexity of the language to continually increase because that’s the needs of the c++ community.
    - mattnewport 9y ago
      My question then is why should I care about "increased complexity" by this definition more than about "simpler usage"? Adding well thought out language features that simplify my every day usage is a good thing and the sense in which it increases complexity is not a sense that particularly concerns me. I think C++ is generally making good choices about what features to add. Generic complaints about new features tautologically "increasing complexity" are not interesting. Specific concerns about particular features not carrying their weight in terms of simplifying usage are interesting (and a big part of what the C++ standards process is engaged in).
      - corysama 9y ago
        Agreed. You have to choose between "large scale removal of features from the language" vs "30+ years of back-compat". You can't have both. A huge strength of C++ is it's legacy and the maintainers would be foolish to throw that away in a C++ 2.0 movement. Instead, they add new features that lets new code be written in new ways without requiring you to toss out your old code. Your old C code is full of mallocs and frees. Your old code still works when you partially update it using the newest features. But, once C++ added new and delete, you rarely ever needed to type malloc or free any more unless you were overloading new and delete. Your old C++ code is full of news and deletes, but new language features added in C++11 made unique_ptr and shared_ptr possible. And, now you rarely need to type new or delete unless you are making your own unique_ptr/shared_ptr variant.
      - interestingcpp 9y ago
        Why would you care? Well the complexity makes tooling difficult, the engineers expensive, and arguably ongoing development could be slower depending on how many c++ features they have to deal with in one code unit. Are these any strikes against the language itself? No, of course not, but one can see why e.g. using go instead might afford more flexibility if the underlying c++ distinguishing features aren’t necessary. The language complexity is still something to consider even if c++ is sufficient. I am by no means arguing that C++ committees are making any mistakes.
- kccqzy 9y ago
  C++17 removed trigraphs. C++17 removed dynamic exception specification which is deprecated since C++11. C++17 removed operator++ for bool which is deprecated since C++98. C++17 removed the “register” storage class.
  - a_e_k 9y ago
    C++11 removed the original meaning of "auto".
- jcelerier 9y ago
  > When was the last time it removed support for a feature? why should it ? Adding features is enough for simplifying stuff. eg take the following code: for(auto& val : {1,3,12,17,20}) { val++; } it leverages three new features: auto, range-based for, and braced initialization. How would it look in cpp03 ? Two possibilities: std::vector<int> v; v.push_back(1); v.push_back(3); ... v.push_back(20); for(std::vector<int>::iterator it = v.begin(); it != v.end(); ++it) { (*it)++; } Or int v[] = {1,3,12,17,20}; for(int i = 0; i < (int)(sizeof(v)/sizeof(int)); i++) { v[i]++; }
fulafel 9y ago
Given the C++ commitment to backwards compatibility, I think the case for a new language in order to reduce complexity is very straightforward. A minimal case would be a C++ subset I guess.
- mattnewport 9y ago
  But the backwards compatibility is taken so seriously because it is so valuable, much more valuable in practice in my experience than the supposed benefits of creating a new incompatible language with fewer features.

interestingcpp 9y ago

Interesting; i think it’s fairly clear by now engaging with C++ is not going to lead to reduced complexity at all. When was the last time it removed support for a feature? That’s not what the language needs because it’s more interested in preserving existing code bases than it is at improving them (the latter being a huge effort, truly massive, so i understand the decision and don’t mean it as a slight in the least).

mattnewport 9y ago
Major influential figures in the C++ community (notably Bjarne Stroustrup and Herb Sutter) are very explicit about having a goal of simplifying everyday usage of C++ (make simple things simple). Watch any of Bjarne's talks over the last few years to see this is one of his main focuses. It's also recognized that backwards compatibility / not breaking existing code are very important however. Yes, that's a hard set of requirements to meet but I find it bizarre when I keep seeing people state that the C++ standards committee and the community in general don't care about simplicity and ease of use when those are literally the major topics of keynotes at every C++ conference of the last few years.
- interestingcpp 9y ago
  Simplifying every day usage is entirely a different thing than simplifying the language. I’m not denying the inprovement in usage, just that you should expect the complexity of the language to continually increase because that’s the needs of the c++ community.
  - mattnewport 9y ago
    My question then is why should I care about "increased complexity" by this definition more than about "simpler usage"? Adding well thought out language features that simplify my every day usage is a good thing and the sense in which it increases complexity is not a sense that particularly concerns me. I think C++ is generally making good choices about what features to add. Generic complaints about new features tautologically "increasing complexity" are not interesting. Specific concerns about particular features not carrying their weight in terms of simplifying usage are interesting (and a big part of what the C++ standards process is engaged in).
    - corysama 9y ago
      Agreed. You have to choose between "large scale removal of features from the language" vs "30+ years of back-compat". You can't have both. A huge strength of C++ is it's legacy and the maintainers would be foolish to throw that away in a C++ 2.0 movement. Instead, they add new features that lets new code be written in new ways without requiring you to toss out your old code. Your old C code is full of mallocs and frees. Your old code still works when you partially update it using the newest features. But, once C++ added new and delete, you rarely ever needed to type malloc or free any more unless you were overloading new and delete. Your old C++ code is full of news and deletes, but new language features added in C++11 made unique_ptr and shared_ptr possible. And, now you rarely need to type new or delete unless you are making your own unique_ptr/shared_ptr variant.
    - interestingcpp 9y ago
      Why would you care? Well the complexity makes tooling difficult, the engineers expensive, and arguably ongoing development could be slower depending on how many c++ features they have to deal with in one code unit. Are these any strikes against the language itself? No, of course not, but one can see why e.g. using go instead might afford more flexibility if the underlying c++ distinguishing features aren’t necessary. The language complexity is still something to consider even if c++ is sufficient. I am by no means arguing that C++ committees are making any mistakes.
kccqzy 9y ago
C++17 removed trigraphs. C++17 removed dynamic exception specification which is deprecated since C++11. C++17 removed operator++ for bool which is deprecated since C++98. C++17 removed the “register” storage class.
- a_e_k 9y ago
  C++11 removed the original meaning of "auto".
jcelerier 9y ago
> When was the last time it removed support for a feature? why should it ? Adding features is enough for simplifying stuff. eg take the following code: for(auto& val : {1,3,12,17,20}) { val++; } it leverages three new features: auto, range-based for, and braced initialization. How would it look in cpp03 ? Two possibilities: std::vector<int> v; v.push_back(1); v.push_back(3); ... v.push_back(20); for(std::vector<int>::iterator it = v.begin(); it != v.end(); ++it) { (*it)++; } Or int v[] = {1,3,12,17,20}; for(int i = 0; i < (int)(sizeof(v)/sizeof(int)); i++) { v[i]++; }

fulafel 9y ago

Given the C++ commitment to backwards compatibility, I think the case for a new language in order to reduce complexity is very straightforward. A minimal case would be a C++ subset I guess.

mattnewport 9y ago
But the backwards compatibility is taken so seriously because it is so valuable, much more valuable in practice in my experience than the supposed benefits of creating a new incompatible language with fewer features.