C++, it's time to go
blog.irukado.org
blog.irukado.org
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.
1987: End of Fortran predicted.
1988: End of Cobol predicted.
1989: End of Fortran predicted.
True. What reality cares is that the programs run where they need to run and it's "portable"
And as much as I would want all programs to run on Linux/Mac OS only and not care about a user interface, there are still programs that need to do that.
Do a cross platform desktop software that runs in Windows/Linux/MacOS. I know three possible answers: Python, Java and C++. Mono maybe a choice as well, but it requires installing Mono.
Now, how to do a software that runs on an embedded linux device.
I can't agree more with you! As a matter of fact, someone famous said:
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.
This someone is Alexander Stepanov the author of the STL (the C++ Standard Library).
C++ is much more about generic programming.
> Algebraic datatypes and pattern matching have been around for years, and have clear advantages.
Try this keyword: "template".
> Parallel programming has been around for years, and is becoming CRITICAL for modern applications.
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).
> C++ has a RIDICULOUS amount of boiler plate.
Maybe. This is one of the philosophy of C++ is "don't pay for what you don't want".
> Headers shouldn’t exist in the language:
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.
> 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.
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.
Some of the most secure programs ever written are written in C which offers even less compile-time checks than C++.
Exactly, many of the warts and gotchas of C++ can be explained through this philosophy. If a certain feature is or hard to use or difficult to understand but faster during runtime the C++ committee will most likely pick this over an implementation of the same feature that is easy to use but slower during runtime.
This someone is Alexander Stepanov the author of the STL (the C++ Standard Library).
Authority doesn't make it true ;) : How about Qt? Or Cocoa?
OO was overhyped. It doesn't fit every problem domain. That doesn't mean the opposite is true. There are domains where OO with class hierarchies is quite a good model, such as GUI toolkits.
Try this keyword: "template".
Templates are a compile-time construct. Algebraic data types are not. I think you are confusing ADTs with parametric polymorphism.
According to you, programs written in Java or .NET should be more secure. That's not the case.
Proof it. I think it is reasonable to assume that Java code produced by the average programmer is safer than C++ code produced by the average programmer. Java does not have pointer arithmetic, does bounds checking, etc.
You keep saying that word. I do not think it means what you think it means: http://en.wikipedia.org/wiki/Algebraic_data_type
The human will make mistakes, as that is what humans do. That's not fundamentally fixable: even the savant will make the occasional error. Compilers and static code analysis can help mitigate the human factor, as can code reviews and any number of other variables.
Static code analysis and "safe" languages seek to mitigate the problem. They are not the only variables in the security equation, but holding everything else constant, given three codebases written in C, C++, and C#, I'll just outright assume the first two will have at least one buffer overflow that's potentially exploitable for arbitrary code injection. The third, at least, has a chance of said overflow being "merely" a potential DoS vulnerability.
Links please re headers solution in C++ 14, Google and Wikipedia didn't return results.
I am not sure how to navigate that site, but it does not look like modules are planned for C++14. At least C++17 according to the picture on this page: http://isocpp.org/std/status
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.
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.
Functions and structs is not much freedom. But you're quite right: nothing forces you to write in C++.
> 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.
Sure. Or COBOL, or any other number of languages in which massive legacy codebases have been written. At best, one avoids them in their own work.
> 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.
Even when you whittle down the feature list far beyond what you can still reasonably expect to be even remotely productive with, simple matters like uninitialized variables can still go uncaught if your compiler can't catch every single use case and you don't wade through a slew of false positives with maximum warnings and warnings as errors. One is forced to use time-expensive static code analysis, enforced by CI build process, to begin to even remotely approach the general runtime safety of something like C#.
These options are extremely useful when you're stuck with a C++ codebase, but I wouldn't describe it so casually, as if they were quick and simple to implement and enforce.
Except that abstract classes are pretty much the only way to implement type-checked interfaces and they are, well, classes.
UPDATE: And for the record, inherence of pure interface classes works just fine in C++. The stuff where it gets ugly is when you try building a deep inheritance hierarchy of behaviour. It can work, but usually not terribly well.
Water, it's time to go. We don't need water anymore!
> Standing in the middle of a desert.
It would be great if we had more water!
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.
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.
Now, if C++ has to go because of some language aspects, I disagree. There is no point. The language is good enough and can still be improved.
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.
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.
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.
all those high frequency trading systems too. you need to replace everything. gc pauses are nothing compared to the elegance of other languages.
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..
It would be nice to justify statements. To write something in upper cases isn't a justification and doesn't make sense.
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.
YES IT DOES! ;-)
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.
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.
Algebraic datatypes and pattern matching have been around for years,
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.
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.
Parallel programming has been around for years, and is becoming CRITICAL for modern applications. If your language doesn’t EASILY support it, it sucks.
Luckily, parallel programming is very 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 concurrency 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++.
C++ has a RIDICULOUS amount of boiler plate.
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.
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.
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.
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.
No it's not.