These posts have been around ever since I started to learn how to program. When I was a wee little lad, everyone told me that C++ was going the way of the dinosaur and no one would ever need to learn it.<p>That was 10 years ago. It still hasn't happened. Meanwhile, blog post after blog post is written about how C++ is dying when it simply isn't. Maybe it will happen sometime in the future, but as of yet no language solves the same problems that C++ does. Not D, not Rust, not Go. Every single one of these arguments is colored by the specific problems the author has spent their life solving. If none of those problems benefit from C++, then they will inevitably come to the conclusion that C++ is useless, and then yet another "C++ is dying" or "C++ considered harmful" blogpost is written. Meanwhile, reality doesn't care.
> OO with class hierarchies is a broken model.<p>I can't agree more with you! As a matter of fact, someone famous said:<p><i>I think that object orientedness is almost as much of a hoax as Artificial Intelligence. I have yet to see an interesting piece of code that comes from these OO people.</i><p>This someone is Alexander Stepanov the author of the STL (the C++ Standard Library).<p>C++ is much more about generic programming.<p>> Algebraic datatypes and pattern matching have been around for years, and have clear advantages.<p>Try this keyword: "template".<p>> Parallel programming has been around for years, and is becoming CRITICAL for modern applications.<p>Whether this is the job of the language or the job of a library is debatable. Efficient parallel programming in C++ is done with the latter (Intel TBB for example).<p>> C++ has a RIDICULOUS amount of boiler plate.<p>Maybe. This is one of the philosophy of C++ is "don't pay for what you don't want".<p>> Headers shouldn’t exist in the language:<p>Yes, but as you said it will be addressed in C++ 14. You should appreciate that C++ has enablee the industry to move forward thanks to its support of C headers. This may be less obvious now, but 10 to 20 years ago this was really a big deal.<p>> The same problems that make highly-parallel code a nightmare in C++ also make it an unsuitable language for security-critical, or mission-critical projects.<p>You are naive if you think the weak link of security is the compiler. The problem is behind the keyboard and the chair. According to you, programs written in Java or .NET should be more secure. That's not the case.<p>Some of the most secure programs ever written are written in C which offers even less compile-time checks than C++.
> OO with class hierarchies is a broken model.<p>If this is true, there is nothing that forces you to write classes in C++. You have all the freedom to write only in functions and structs.<p>I think C++ is not going "to go" anywhere and is here to stay for a long, long time, and have it's place in programming language "pantheon" similar to C. C++ gives programmer freedom, which is too much to handle for many. Restrictive language is a good way of preventing bugs, but in C++ you can just select what language features you are gonna use and have similar result.
> Standing on a raft in the middle of a lake.<p>Water, it's time to go. We don't need water anymore!<p>> Standing in the middle of a desert.<p>It would be great if we had more water!<p>This is literally what these arguments for or against C++ sound like. Please, before you decide some language needs to go, take the time to understand the context in which it should or should not be used.
I think this is confusing.<p>If C++ has to go because the paradigm is wrong, because it has to be replaced by say more functional languages, OK. But then so does Java, C# and so on.<p>Now, if C++ has to go because of some <i>language aspects</i>, I disagree. There is no point. The language is good enough and can still be improved.<p>When I choose C++ over other languages I don't do it because I like the language, I do it because it generates native code, because of manual control of the memory management, because templates can be useful to solve some problems elegantly, etc.
I'm not the world's biggest C++ fan, quite the opposite. But this guy hasn't really realized yet that any attempt to build something as expressive and powerful as C++, and just as fast, without any of the things he dislikes in C++ will hit any number of walls, problems, and challenges that nobody out there has overcome. Objective-C gives you almost as much performance as C++ except in the critical cases where message passing can degrade overall performance due to objective C run-time message send overhead.<p>Performance, Compatibility, Ecosystems, Existing Running Code In Production. Go ahead and rewrite your piddly little apps in Anything You Like. C++, and any other language you hate (Java, C#, whatever) will still be used and significant and powerful tools that people use to get stuff done.<p>Me I love Delphi, and I'm used to people considering it dead. (It's not dead.) I consider it a better language than C++, but that's just a subjective opinion of my own. I've spent years hating on C++, but I'm done with that. C++ 2011 is a great step forward for the language, and when they finally get modules (2020?) they'll have caught up with TurboPascal (1984). Awesome.
hey facebook, please replace all your core c++ infrastructure with haskell/rust/D/ruby because this guy had decided that its time for c++ to go.<p>all those high frequency trading systems too. you need to replace everything. gc pauses are nothing compared to the elegance of other languages.<p>as you can clearly read its just not the right language for parallelism, and all those headers make 3m lines of code harder to read not easier. also all those bloody class hierarchies..
Not sure what is meant by "research".<p>It would be nice to justify statements. To write something in upper cases isn't a justification and doesn't make sense.<p>Each new programming language seems to be better and so on. But if we are looking to the hottest shit on the planet of the past year like java, ruby, python, etc. we can say that we didn't know their problems at the beginning.
<i>OO with class hierarchies is a broken model.</i><p>I am not sure whether C++ is a good target for this criticism. The most frequently used libraries (STL and Boost) don't use class hierarchies extensively.<p>Also, some domains are easily modelled using class hierarchies, such as GUI widgets, where more specialized widgets override or extend behaviour (or painting) of more general widgets. I have programmed Qt for years, and the class hierarchy model works exceptionally well there.<p><i>Algebraic datatypes and pattern matching have been around for years,</i><p>They come with advantages and disadvantages. E.g. adding a constructor potentially requires you to update every pattern matching case. This can get quite ugly quickly if you add a constructor to some commonly-used library.<p>I do like them in cases where you know up-front what constructors there will be. E.g. lightweight error handling with Maybe/Either. Or when their visibility is limited.<p><i>Parallel programming has been around for years, and is becoming CRITICAL for modern applications. If your language doesn’t EASILY support it, it sucks.</i><p>Luckily, parallel programming is <i>very</i> easy in C++ using e.g. OpenMP or Intel TBB. In the case of OpenMP it is usually a matter of adding pragmas to your embarrassingly parallel loops. It is <i>concurrency</i> that is more of a problem. C++11 has standardized lot of 'old-world' constructs for threading, but it's not as if you can find a mature technology like Erlang's OTP or Akka on top of C++.<p><i>C++ has a RIDICULOUS amount of boiler plate.</i><p>I agree that there is a lot of boilerplate. But then the author goes off ranting about constructors. I don't find it that convincing. There used to be a lot of boilerplate in iterator and <algorithm> use, but C++11 makes things much more compact with auto et al. IMO one of the biggest sources of boilerplate in C++ is writing libraries such that you have ABI compatibility. You usually end up using PIMPL for every class, maintaining two versions (PIMPL and actual) of each class.<p>Then, there are other languages that come with a lot of boilerplate, such as Java, but the difference is that Java is much easier to parse, process, and incrementally compile. As a consequence, Java IDEs tend to be much better at code generation and refactoring than C++ IDEs.<p><i>The same problems that make highly-parallel code a nightmare in C++ also make it an unsuitable language for security-critical, or mission-critical projects. </i><p>Yes, it is extremely easy to blow your foot of. Forgetting a 'virtual' keyword can lead to subtle, difficult to find bugs. You can read or write beyond bounds by accident. Etc. These are well-known critiques. Use C++ (or another unsafe language) when it's necessary to trade off safety for performance. Rust will probably bring performance while sacrificing less safety. But it's not there yet.