6 ms·

I'm naive about the language development process. I have no area of expertise in C++. But coming from a background in Python I've seen people complain about Pyt

I'm naive about the language development process. I have no area of expertise in C++. But coming from a background in Python I've seen people complain about Python getting bigger and bigger, and people have been complaining about C++ being huge for even longer. In my naive opinion, It seems to me that both C++ and Python have reached a point where most people are satisfied with the features the language has. Most of the complaints are around warts in the language itself that people wish could be fixed (but can't due to backwards compatibility). My question is why the need to keep adding features? Sure if something comes out that C++ is desperately lacking, add it in. But it seems like that hasn't been the case for a while. My other question. Would it be possible for a language to work like an OS? Where there is a LTS version of the language that is supported for X years, and then a new version comes out that contains potentially (but not always if it's unnecessary) breaking changes? I guess Python was kind of an example of that with Py2 to Py3, but no one who started using python after 1.0 expected there to be a shift like that. But if from the outset there is that expectation that after 5-10 years there will be a new version that removes warts in an old version would people accept that? It seems to me that the lifecycle of a language that is successful is 1. Be the new hotness and solve a problem in the programming space 2. Gain traction and users 3. Release version 1.0, become bound by decisions that might haunt you for the rest of the programs life 4. Accumulate features, bloat and warts 5. Have people complain about warts that you can't fix due to breaking changes 6. A new language develops that fixes your warts. 7. Repeat It seems like the cognitive load from "upgrading" a language as opposed to learning an entirely new language from scratch (even if it fixes a lot of your gripes) would be a lot easier. Having been playing around with Rust for a bit, I've seen the conversation come up about warts in Rust, and I think people fear if it will eventually become another C++. I think the answer is probably yes, if it endures for a similar amount of time that C++ did

ilkkao 5y ago
I don't know what the situation is with the C++ development. But in general, based on my experience on standardization work, it's really hard to stop a committee from inventing new features when the members get paid to participate and make an impact. Maybe exaggerated but sometimes I got the feeling that some proposal existed only so that the presenter was able to justify a week in a nice meeting location like Hawaii.
- 2iP1zbR 5y ago
  > it's really hard to stop a committee from inventing new features when the members get paid to participate and make an impact. This could also explain most awful, unnecessary GUI updates, unprovoked by any customers, throughout software.
nsajko 5y ago
> people wish could be fixed (but can't due to backwards compatibility) This is actually not completely true. The only example I can think of right now is how C++20 deprecated some uses of volatile, but the standards definitely do deprecate features and break backwards compatibility. This is done with care, only when it makes sense. The standards and individual papers/proposals are public, so feel free to take a look, they include rationales in such cases. > My question is why the need to keep adding features? Sure if something comes out that C++ is desperately lacking, add it in. Well, that already is how it works. Just because you don't know about some change doesn't mean it wasn't worthwhile. There are often some complaints regarding the standardization process itself though, I think that, e.g., the coroutines proposals situation with the multiple competing proposals was pretty controversial. But that's just how it is with C, C++ (and Ada, Pascal, Basic, ...). It seems like the days of ISO reigning over programming languages are over though, in that newer programming languages aren't given over to ISO.
- pjmlp 5y ago
  When not ISO, it is ECMA. Many industries won't touch a language if it doesn't come with a standard and multiple implementations. Even languages like Java, C#, F#, have their standard documents, or foundation with working groups that are hardly any different from either ISO or ECMA, as means to be taken into those industries.
secondcoming 5y ago
New features get added to C++ only when people vote for them. I believe anyone gets to cast a vote. You have to write a paper that explains the rationale for your idea. So, features get added because they're considered good ideas.
jcelerier 5y ago
> In my naive opinion, It seems to me that both C++ and Python have reached a point where most people are satisfied with the features the language has. most definitely not. C++ still doesn't have reflection ffs, which I am reminded every time I have to type the name of an enum or class twice
- Gibbon1 5y ago
  Idle question, if you could toss everything added to C++ in the last 20 years in return reflection would that be worth it?
  - jcelerier 5y ago
    I'm of the opinion that powerful enough reflection + metaclasses (e.g. with the ability to synthesize almost arbitrary code ) would be able to transform a lot of language features (noexcept, coroutines, ...) into library features. But it's not possible for all, and you'll pry auto, range-based for, atomics semantics, lambdas, restructuring bindings, and brace-init... from my cold dead hands
- spacechild1 5y ago
  Reflection is also one of the things I miss the most.
qalmakka 5y ago
The main issue I have with C++ is that you basically have to relearn it from scratch every time a standard comes out. C++11 threw away decades of best practices, and C++17 again changed so many things it's hard to keep track of them (for instance, stuff like `string_view` has had a _huge_ impact on how I write code and how I reason about strings, making `const char *` almost disappear from some of my codebases). C++20 with concepts and ranges will revolutionise everything, again, because those features are so big and pervasive they make lots of patterns and "older" parts f the language suddenly feel like "legacy". For instance, I see concepts vastly reducing the need for inheritance in lots of cases, massively simplifying what lots of folks like me were already doing with SFINAE and templates.
- tsimionescu 5y ago
  As far as I understand, that is the whole point of many of these changes: there are patterns that people have to bend their code into and unsafe constructs that need to be used with care, and the newer standards seek to replace patterns with language features (e.g. concepts more or less instead of SFINAE), or bring safe alternatives to the previously necessary unsafe ones (string_view instead of `char*`). Now, the major concerns that some have is that this will not be successful, and that instead of replacing X with Y, you'll be left with both X and Y in the language as still necessary constructs for new code, making the language ever more complicated even if you can disregard the legacy. C++ already suffers somewhat from the strong ties between many of its features (for example, many people would like to use C++ without exceptions, but then you can't use `new` or constructors that can fail, and without constructors you can't use RAII, and so on).
  - spacechild1 5y ago
    Just FYI > but then you can't use `new` You can certainly use new without exceptions, see https://en.cppreference.com/w/cpp/memory/new/nothrow https://en.cppreference.com/w/cpp/memory/new/nothrow or https://stackoverflow.com/a/15292148 https://stackoverflow.com/a/15292148 > and without constructors you can't use RAII, and so on). I think RAII is more about destructors (which must never throw exceptions). You can certainly write RAII style without throwing constructors. Generally, exceptions depend on RAII, but not the other way round.
chubot 5y ago
Lots of answers to this, but (1) Computing is growing as a whole. What was good enough in 1980 isn't good enough now. Computing is used for more problems, and by more people. Programs are bigger, so there is pressure toward compressing common code and idioms. Hardware is more capable and more complex: it's more heterogeneous, dynamic, has more sensors, etc. (2) Different problems have different use cases. Your "wart and bloat" is another person's feature, and vice versa. Multi-core, multithreading and GPU are major reasons that features have been added to C++, and those were less of a concern in 1980 when C++ was conceived. (especially GPU). The "cycle" you lay out isn't accurate because languages in fact do make progress. We're not going around in a circle. Rust fixes a lot of things wrong with C and C++; Go and Swift are also improvements, etc. (I don't even use those languages, but I can recognize the improvements as someone who's been using C and C++ for a long time). I recommend writing some C from scratch to get a feel for this. I do this on occcasion, because there are advantages. But you will also be extremely hard pressed to do anything that's interesting for a user. The gap to bridge is very large. For example, try writing a web app in C (not for production). You can save a lot of code by using CGI, but even then it's not fun. (It IS still done; look at the source code to the modern cgit UI if interested.) Also try to modify and understand source code from the 90's like GNU bash or CPython. (Interestingly, there is a pretty big difference between the codebases, despite being from similar eras.) Nonetheless it should be clear from that experience that we've made progress. The progress isn't perfect, but freezing languages in time isn't a reasonable option, given the massive change in the problems being solved, and the environment.
simias 5y ago
I don't think Python and C++ are really comparable here. Python was meant to be fairly minimalist from the start. I think if Python "feature froze" right now it'd still remain relevant for a long time. As you mention for its core use case you could argue that it's feature-complete already. C++ on the other hand was never small. It was never an objective. C++ started as C with classes so it was really just a way to have proper OOP in C. Then it grew and grew and grew, adding more paradigms along the way. C++ is in a relatively tough spot because it has to maintain backward compatibility all the way back to C89 while at the same time attempt to stay relevant when pitted against Rust, Zig, D and friends. You can't simplify anything because you'd lose backcompat and if you just feature freeze you're doomed to become irrelevant in the not-so-far future. Unlike Python you can't really argue that C++ as it is now is feature complete. Dependency management is still a nightmare (as is the entire build system really, given that you don't have any standard C++ build system). Concepts are also a great addition to the language IMO that I've been missing for as long as I've used the language. Coroutines are also fast becoming a standard tool for system programming (for better or worse, but that's a different discussion), and C++'s support in the standard is still experimental.
- tsimionescu 5y ago
  > C++ is in a relatively tough spot because it has to maintain backward compatibility all the way back to C89 C++ does not maintain backwards compatibility with any version of C. Almost any relatively large idiomatic C program will fail when compiled as C++ for a few simple differences (most commonly, in C it is idiomatic to write `int *c = malloc(sizeof(int))`, while this is a type error in C++).
- pjmlp 5y ago
  Except Python is quite huge as well, and introduces breaking changes even across minor versions, people think it is simple, but that is actually quite deceiving.
- frakt0x90 5y ago
  I don't think that's true at all for Python. It's explicitly created as a "batteries included" language with a very large standard library. This is a quote from PEP 206: "The Python source distribution has long maintained the philosophy of "batteries included" -- having a rich and versatile standard library which is immediately available, without making the user download separate packages."
ijidak 5y ago
I fear this is the road C# is on.
SubjectToChange 5y ago
>My question is why the need to keep adding features? Sure if something comes out that C++ is desperately lacking, add it in. But it seems like that hasn't been the case for a while. C++20 does address legitimate pain points of the language. - Modules alone can cut 30% off compile times, as well as solving some other corner cases. - Coroutines will make writing network code easier. - constinit and consteval greatly simplifies the horrible TMP hacks C++ programmers are already using. - The spaceship operator removes a lot of boilerplate when defining comparison operators. - Library additions like <format>, <bit>, <numbers>, std::jthread, etc, standardize widely used operations and libraries. In contrast, it seems like most of the language features proposed for Python are to "keep up" with other languages, e.g. the pattern matching proposal. It's made even worse in Python's case because it has historically been sold as a simple and easy to understand language. >I think the answer is probably yes, if it endures for a similar amount of time that C++ did Maybe. But Rust is in a much better position to avoid C++ style complexity. Editions allow Rust to "clean up" the language without breaking existing code (C++ is trying to do the same with Epochs). And Rust doesn't try to maintain broad compatibility with another language like C++ does with C89. Other features, like powerful macro definition facilities, also help offload language features to libraries. And most of all, Rust can learn from the mistakes of C++, e.g. destructive moves are definitely the way to go. Anyway, it does seem like programming languages are either destined to ossify, like C, or sprawl out of control, like C++. Although, this problem can be largely avoided if the language lets code leverage the compiler, such as Lisp macros.
- fpoling 5y ago
  Modules in theory for big source trees with a lot of small files and long include lists can reduce compilation time by factor of 5 as that time is dominated by repeated parsing of headers.
- pjmlp 5y ago
  I still don't buy into epochs at the industrial scale languages like C and C++ are used today. It relies on using the same compiler for the whole project, no use of binary libraries, or language semantic changes, for the whole idea of mixing epochs to work out.

ilkkao 5y ago

I don't know what the situation is with the C++ development. But in general, based on my experience on standardization work, it's really hard to stop a committee from inventing new features when the members get paid to participate and make an impact. Maybe exaggerated but sometimes I got the feeling that some proposal existed only so that the presenter was able to justify a week in a nice meeting location like Hawaii.

2iP1zbR 5y ago
> it's really hard to stop a committee from inventing new features when the members get paid to participate and make an impact. This could also explain most awful, unnecessary GUI updates, unprovoked by any customers, throughout software.

nsajko 5y ago

> people wish could be fixed (but can't due to backwards compatibility) This is actually not completely true. The only example I can think of right now is how C++20 deprecated some uses of volatile, but the standards definitely do deprecate features and break backwards compatibility. This is done with care, only when it makes sense. The standards and individual papers/proposals are public, so feel free to take a look, they include rationales in such cases. > My question is why the need to keep adding features? Sure if something comes out that C++ is desperately lacking, add it in. Well, that already is how it works. Just because you don't know about some change doesn't mean it wasn't worthwhile. There are often some complaints regarding the standardization process itself though, I think that, e.g., the coroutines proposals situation with the multiple competing proposals was pretty controversial. But that's just how it is with C, C++ (and Ada, Pascal, Basic, ...). It seems like the days of ISO reigning over programming languages are over though, in that newer programming languages aren't given over to ISO.

pjmlp 5y ago
When not ISO, it is ECMA. Many industries won't touch a language if it doesn't come with a standard and multiple implementations. Even languages like Java, C#, F#, have their standard documents, or foundation with working groups that are hardly any different from either ISO or ECMA, as means to be taken into those industries.

secondcoming 5y ago

New features get added to C++ only when people vote for them. I believe anyone gets to cast a vote. You have to write a paper that explains the rationale for your idea. So, features get added because they're considered good ideas.

jcelerier 5y ago

> In my naive opinion, It seems to me that both C++ and Python have reached a point where most people are satisfied with the features the language has. most definitely not. C++ still doesn't have reflection ffs, which I am reminded every time I have to type the name of an enum or class twice

Gibbon1 5y ago
Idle question, if you could toss everything added to C++ in the last 20 years in return reflection would that be worth it?
- jcelerier 5y ago
  I'm of the opinion that powerful enough reflection + metaclasses (e.g. with the ability to synthesize almost arbitrary code ) would be able to transform a lot of language features (noexcept, coroutines, ...) into library features. But it's not possible for all, and you'll pry auto, range-based for, atomics semantics, lambdas, restructuring bindings, and brace-init... from my cold dead hands
spacechild1 5y ago
Reflection is also one of the things I miss the most.

qalmakka 5y ago

The main issue I have with C++ is that you basically have to relearn it from scratch every time a standard comes out. C++11 threw away decades of best practices, and C++17 again changed so many things it's hard to keep track of them (for instance, stuff like `string_view` has had a _huge_ impact on how I write code and how I reason about strings, making `const char *` almost disappear from some of my codebases). C++20 with concepts and ranges will revolutionise everything, again, because those features are so big and pervasive they make lots of patterns and "older" parts f the language suddenly feel like "legacy". For instance, I see concepts vastly reducing the need for inheritance in lots of cases, massively simplifying what lots of folks like me were already doing with SFINAE and templates.

tsimionescu 5y ago
As far as I understand, that is the whole point of many of these changes: there are patterns that people have to bend their code into and unsafe constructs that need to be used with care, and the newer standards seek to replace patterns with language features (e.g. concepts more or less instead of SFINAE), or bring safe alternatives to the previously necessary unsafe ones (string_view instead of `char*`). Now, the major concerns that some have is that this will not be successful, and that instead of replacing X with Y, you'll be left with both X and Y in the language as still necessary constructs for new code, making the language ever more complicated even if you can disregard the legacy. C++ already suffers somewhat from the strong ties between many of its features (for example, many people would like to use C++ without exceptions, but then you can't use `new` or constructors that can fail, and without constructors you can't use RAII, and so on).
- spacechild1 5y ago
  Just FYI > but then you can't use `new` You can certainly use new without exceptions, see https://en.cppreference.com/w/cpp/memory/new/nothrow https://en.cppreference.com/w/cpp/memory/new/nothrow or https://stackoverflow.com/a/15292148 https://stackoverflow.com/a/15292148 > and without constructors you can't use RAII, and so on). I think RAII is more about destructors (which must never throw exceptions). You can certainly write RAII style without throwing constructors. Generally, exceptions depend on RAII, but not the other way round.

chubot 5y ago

Lots of answers to this, but (1) Computing is growing as a whole. What was good enough in 1980 isn't good enough now. Computing is used for more problems, and by more people. Programs are bigger, so there is pressure toward compressing common code and idioms. Hardware is more capable and more complex: it's more heterogeneous, dynamic, has more sensors, etc. (2) Different problems have different use cases. Your "wart and bloat" is another person's feature, and vice versa. Multi-core, multithreading and GPU are major reasons that features have been added to C++, and those were less of a concern in 1980 when C++ was conceived. (especially GPU). The "cycle" you lay out isn't accurate because languages in fact do make progress. We're not going around in a circle. Rust fixes a lot of things wrong with C and C++; Go and Swift are also improvements, etc. (I don't even use those languages, but I can recognize the improvements as someone who's been using C and C++ for a long time). I recommend writing some C from scratch to get a feel for this. I do this on occcasion, because there are advantages. But you will also be extremely hard pressed to do anything that's interesting for a user. The gap to bridge is very large. For example, try writing a web app in C (not for production). You can save a lot of code by using CGI, but even then it's not fun. (It IS still done; look at the source code to the modern cgit UI if interested.) Also try to modify and understand source code from the 90's like GNU bash or CPython. (Interestingly, there is a pretty big difference between the codebases, despite being from similar eras.) Nonetheless it should be clear from that experience that we've made progress. The progress isn't perfect, but freezing languages in time isn't a reasonable option, given the massive change in the problems being solved, and the environment.

simias 5y ago

I don't think Python and C++ are really comparable here. Python was meant to be fairly minimalist from the start. I think if Python "feature froze" right now it'd still remain relevant for a long time. As you mention for its core use case you could argue that it's feature-complete already. C++ on the other hand was never small. It was never an objective. C++ started as C with classes so it was really just a way to have proper OOP in C. Then it grew and grew and grew, adding more paradigms along the way. C++ is in a relatively tough spot because it has to maintain backward compatibility all the way back to C89 while at the same time attempt to stay relevant when pitted against Rust, Zig, D and friends. You can't simplify anything because you'd lose backcompat and if you just feature freeze you're doomed to become irrelevant in the not-so-far future. Unlike Python you can't really argue that C++ as it is now is feature complete. Dependency management is still a nightmare (as is the entire build system really, given that you don't have any standard C++ build system). Concepts are also a great addition to the language IMO that I've been missing for as long as I've used the language. Coroutines are also fast becoming a standard tool for system programming (for better or worse, but that's a different discussion), and C++'s support in the standard is still experimental.

tsimionescu 5y ago
> C++ is in a relatively tough spot because it has to maintain backward compatibility all the way back to C89 C++ does not maintain backwards compatibility with any version of C. Almost any relatively large idiomatic C program will fail when compiled as C++ for a few simple differences (most commonly, in C it is idiomatic to write `int *c = malloc(sizeof(int))`, while this is a type error in C++).
pjmlp 5y ago
Except Python is quite huge as well, and introduces breaking changes even across minor versions, people think it is simple, but that is actually quite deceiving.
frakt0x90 5y ago
I don't think that's true at all for Python. It's explicitly created as a "batteries included" language with a very large standard library. This is a quote from PEP 206: "The Python source distribution has long maintained the philosophy of "batteries included" -- having a rich and versatile standard library which is immediately available, without making the user download separate packages."

ijidak 5y ago

I fear this is the road C# is on.

SubjectToChange 5y ago

>My question is why the need to keep adding features? Sure if something comes out that C++ is desperately lacking, add it in. But it seems like that hasn't been the case for a while. C++20 does address legitimate pain points of the language. - Modules alone can cut 30% off compile times, as well as solving some other corner cases. - Coroutines will make writing network code easier. - constinit and consteval greatly simplifies the horrible TMP hacks C++ programmers are already using. - The spaceship operator removes a lot of boilerplate when defining comparison operators. - Library additions like <format>, <bit>, <numbers>, std::jthread, etc, standardize widely used operations and libraries. In contrast, it seems like most of the language features proposed for Python are to "keep up" with other languages, e.g. the pattern matching proposal. It's made even worse in Python's case because it has historically been sold as a simple and easy to understand language. >I think the answer is probably yes, if it endures for a similar amount of time that C++ did Maybe. But Rust is in a much better position to avoid C++ style complexity. Editions allow Rust to "clean up" the language without breaking existing code (C++ is trying to do the same with Epochs). And Rust doesn't try to maintain broad compatibility with another language like C++ does with C89. Other features, like powerful macro definition facilities, also help offload language features to libraries. And most of all, Rust can learn from the mistakes of C++, e.g. destructive moves are definitely the way to go. Anyway, it does seem like programming languages are either destined to ossify, like C, or sprawl out of control, like C++. Although, this problem can be largely avoided if the language lets code leverage the compiler, such as Lisp macros.

fpoling 5y ago
Modules in theory for big source trees with a lot of small files and long include lists can reduce compilation time by factor of 5 as that time is dominated by repeated parsing of headers.
pjmlp 5y ago
I still don't buy into epochs at the industrial scale languages like C and C++ are used today. It relies on using the same compiler for the whole project, no use of binary libraries, or language semantic changes, for the whole idea of mixing epochs to work out.