4 ms·

> language designers have the problem of knowing when to stop C++ will evolve as long as programming methodology hasn't been perfected. At this point it is imm

> language designers have the problem of knowing when to stop C++ will evolve as long as programming methodology hasn't been perfected. At this point it is immortal and the committee knows it. > C++11 should have been a minimal cleanup of C++03 C++03 was a very minimal cleanup of C++98 aka ANSI C++. Therefore they were pressed to have much wanted features in the next standard, which was delayed repeatedly to make them ready. > C++14 onwards could have been a new language, with all the old baggage removed. The committee seems to gravitate toward first adding the superseding features and removing those rendered obsolete only in the next standard, to provide a clean upgrade path to legacy code. It also leaves time to see which features were really obsoleted.

__d 5y ago
>> language designers have the problem of knowing when to stop > C++ will evolve as long as programming methodology hasn't been perfected. At this point it is immortal and the committee knows it. I fear you are correct. >> C++11 should have been a minimal cleanup of C++03 > C++03 was a very minimal cleanup of C++98 aka ANSI C++. Therefore they were pressed to have much wanted features in the next standard, which was delayed repeatedly to make them ready. Yes. At which point, I think it became clear that there were two languages at play here: one a minor touch-up of C++03, which could have been pushed out once they realized that C++11 was a mutant monster. And then newC++11, which was the first draft of newC++23, and should've had a more light-weight "agile" development process, allowing what became 14, 17, 20, and 23 to happen without all the pomp and circumstance of the committee process. >> C++14 onwards could have been a new language, with all the old baggage removed. > The committee seems to gravitate toward first adding the superseding features and removing those rendered obsolete only in the next standard, to provide a clean upgrade path to legacy code. It also leaves time to see which features were really obsoleted. Which gives you a constantly moving target, and code that once worked without issue is now in need of major maintenance, and (just like with Python3) the community spends vast amounts of what would otherwise be productive time just keeping application code current.
- TheMonarchist 5y ago
  > > The committee seems to gravitate toward first adding the superseding features and removing those rendered obsolete only in the next standard, to provide a clean upgrade path to legacy code. > Which gives you a constantly moving target, and code that once worked without issue is now in need of major maintenance, and (just like with Python3) the community spends vast amounts of what would otherwise be productive time just keeping application code current. In practice compilers never remove anything they have had in the past. You may have to re-enable it with a switch though. In the worst case you just stick with the previous standard until code has been updated. > should've had a more light-weight "agile" development process, allowing what became 14, 17, 20, and 23 to happen without all the pomp and circumstance of the committee process. To be fair, developing C++ without something like ISO would be impossible. It provides legal protection; so many critical things depend on C++ that the committee would face accusations of collusion without a rigid process and a backing organization. > C++11 was a mutant monster. This is true to some extent, but it still was a big improvement on C++03, at least if you wanted to do generic programming and rudimentary metaprogramming. > > C++ will evolve as long as programming methodology hasn't been perfected. At this point it is immortal and the committee knows it. > I fear you are correct. I have for a while suspected that people actually fear it. I wonder why? 20 years ago it may have looked like C++ could kill your favorite language but that's hardly the case today. Now it seems like that it continues to be an expert-friendly language that is used to bridge the gap between human expectations and hardware. I imagine that the future of C++ will look similar to its current symbiosis with Python.

__d 5y ago

>> language designers have the problem of knowing when to stop > C++ will evolve as long as programming methodology hasn't been perfected. At this point it is immortal and the committee knows it. I fear you are correct. >> C++11 should have been a minimal cleanup of C++03 > C++03 was a very minimal cleanup of C++98 aka ANSI C++. Therefore they were pressed to have much wanted features in the next standard, which was delayed repeatedly to make them ready. Yes. At which point, I think it became clear that there were two languages at play here: one a minor touch-up of C++03, which could have been pushed out once they realized that C++11 was a mutant monster. And then newC++11, which was the first draft of newC++23, and should've had a more light-weight "agile" development process, allowing what became 14, 17, 20, and 23 to happen without all the pomp and circumstance of the committee process. >> C++14 onwards could have been a new language, with all the old baggage removed. > The committee seems to gravitate toward first adding the superseding features and removing those rendered obsolete only in the next standard, to provide a clean upgrade path to legacy code. It also leaves time to see which features were really obsoleted. Which gives you a constantly moving target, and code that once worked without issue is now in need of major maintenance, and (just like with Python3) the community spends vast amounts of what would otherwise be productive time just keeping application code current.

TheMonarchist 5y ago
> > The committee seems to gravitate toward first adding the superseding features and removing those rendered obsolete only in the next standard, to provide a clean upgrade path to legacy code. > Which gives you a constantly moving target, and code that once worked without issue is now in need of major maintenance, and (just like with Python3) the community spends vast amounts of what would otherwise be productive time just keeping application code current. In practice compilers never remove anything they have had in the past. You may have to re-enable it with a switch though. In the worst case you just stick with the previous standard until code has been updated. > should've had a more light-weight "agile" development process, allowing what became 14, 17, 20, and 23 to happen without all the pomp and circumstance of the committee process. To be fair, developing C++ without something like ISO would be impossible. It provides legal protection; so many critical things depend on C++ that the committee would face accusations of collusion without a rigid process and a backing organization. > C++11 was a mutant monster. This is true to some extent, but it still was a big improvement on C++03, at least if you wanted to do generic programming and rudimentary metaprogramming. > > C++ will evolve as long as programming methodology hasn't been perfected. At this point it is immortal and the committee knows it. > I fear you are correct. I have for a while suspected that people actually fear it. I wonder why? 20 years ago it may have looked like C++ could kill your favorite language but that's hardly the case today. Now it seems like that it continues to be an expert-friendly language that is used to bridge the gap between human expectations and hardware. I imagine that the future of C++ will look similar to its current symbiosis with Python.