Hacker News new | past | comments | ask | show | jobs | submit login

You can't remove features from a language, that creates a new language instead. The transition then takes years. Haven't people realised this since the Perl 5/6 and Python 2/3 transitions?



As long as you can link old-C++ and new-C++ together, there shouldn't be any big problems. You'll write your new code in new-C++ and wrap your old code in extern "old-C++". The same way you can mix C code in C++ projects today.


The fact that these transitions were so painful doesn't mean that all breaking changes have to be so painful. With Meyers' 'magic wand', the transition is eased quite a bit. But another important component of a smooth transition is a 'carrot', a new feature that's so compelling everybody will want to move to the new use the new version. If a C++ with major breaking changes would also halve compilation time for example, most people would switch in a heartbeat.


That assumes that compilation times is a number one prio for all users. Halving compilation times certainly is worth something, but the cost will have to compare well to other options of reducing compilation times such as using distributed builds etc.

In the end it's really hard to force breaking changes for systems that are working sufficiently well. If I have something that I'm satisfied with (after all, I chose to use C++ over Go, c#, D, Ada, Pascal, etc., why not choose C++17 over some hypothethical incompatible C++22)


Things have been removed from C++ before, after a deprecation period. Many things on Scott’s list could easily be deprecated in C++23 or even 20.


Indeed the author proposes a ten-year plan.


I'm a little bit surprised to see this coming from scott meyers, who I generally assume to have much better judgment than I do when it comes to c++.

I would think (or at least hope) that there are not many new projects being started in c++ these days. with this assumption, it seems like the main focus for c++ today should be on adding features that enable developers to incrementally rewrite old code with a view towards increased safety. range-based for is a great example of this. a large portion of unchecked vector accesses within loops can be trivially rewritten with range-based for to be much safer, and a small team can simply fix them one by one as they quash bugs.

on the other hand, removing NULL all at once in a legacy codebase could be almost impossible for a small team. I've seen many unfortunate instances where the code actually relies on NULL being the integer '0'. fixing this kind of thing across thousands of files would be an absolute nightmare.

I am certainly sympathetic to the idea that the code that will be broken by these types of changes is sloppy and should be rewritten anyway, but this is unlikely to actually happen. most resource-constrained teams are just going to freeze their projects at c++yy and never benefit from any new features.

edit: I partially retract this post. the gradual 10-year deprecation process he specifies seems reasonable enough. I still question whether making c++ less confusing to newcomers is a good use of resources. there's really not a lot of situations where it makes sense to start a new project in c++.


> I would think (or at least hope) that there are not many new projects being started in c++ these days.

I would imagine there are fewer new projects in C++ than, say, JavaScript, and fewer new projects in C++ than old projects in C++.

But C++ is absolutely still a live language! For the simple reason that there is no alternative which can work in all its significant niches (systems, realtime, embedded, HPC) and which is mature. Rust is on its way. D could be on its way. Ada never caught on widely, for some reason.


Ada never caught on, because its compilers were too expensive and no OS vendor included it on their standard SDK, thus hardly anyone would pay extra for additional languages beyond those on the SDK.

C++ caught on, because it came from AT&T and was embraced by C compiler vendors, thus landing in all OS SDKs.

Being part of a platform SDK is usually the path to fortune, for any language in platforms that manage to win widespread usage.


Ada was also too slow to compile with the computer systems of the day. I remember a HW company coming on site with a demo (contained on 9 track tape, of course). Compilation of a couple thousand lines of ada took all day (5+ hours). In that era, couple of thousand lines of fortran was 10 minutes. Big difference. Ada was ahead of it's time. Still the language of choice when you care more about non-functional requirements.


> Compilation of a couple thousand lines of ada took all day (5+ hours). In that era, couple of thousand lines of fortran was 10 minutes.

And a couple thousand lines of Turbo Pascal was 10 seconds! XD


> I would think (or at least hope) that there are not many new projects being started in c++ these days.

At least on Github it's growing : https://www.benfrederickson.com/ranking-programming-language...

I'm pretty sure that given the overall large increase in the amount of programmers, there are more new C++ projects being created this year than there were new software projects overall when c++98 was standardized. Consider that in the US alone, there were ~600k developers in 2002, and nowadays the estimates are at ~4.5 million.


>I would think (or at least hope) that there are not many new projects being started in c++ these days.

I doubt there was any fall to the number of C++ projects started. For the domains C++ is used (OSes, premium apps the likes of Office, Photoshop, 3D, video editing, DAWs, etc, AAA games, networking, databases, number crunching, etc), there's no substitute with the same number of compilers, ecosystem, maturity, and programmer base. Rust doesn't even come close.


New robotics and vision systems are still very much using c++. Real time object tracking with sensor fusion requires careful handling of resources all of which needs to fit into a larger framework. C++ is the best choice to be able to develop a complex OOP architecture and still be able to get the efficiency where you need it.




Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: