The author clearly didn't say that C++ was the worst language he's ever heard of. He didn't necessarily even say C++ is a bad language. What I'm reading is more along the lines of "Ok sure, C++ was important at one point in time. But in 2013, we have lots of things to worry about that C++ doesn't help us with that other languages do help us with."
He conclusion is the C++ is obsolete and the power of new hardware capabilities is being squandered because of it. I'd call that 'scathing.' I'll always be fond of C++, but I hope I never have to use it again.
That conclusion on squandering the power of new hardware is being backed by absolutely zero data and is obviously false. Just look around you and note how much software you depend on runs in a parallel fashion on multicore systems (using the SMP model of programming) and is written in imperative languages (mostly C and C++).
The only arguments presented by the author are his own subjective opinions of how bad various features of C++ are. There's merit in many of his arguments but the effect of each problem is exaggerated way beyond it's actual impact. For example, the bold, unhedged claim:
"Two words: data races. Imperative languages offer no protection against data races — maybe with the exception of D."
is a ridiculous claim to make right after his (mostly dismissive) nod to memory model and synchronization primitive introduced in c++11. If it was that difficult to implement parallel programming in imperative languages, we'd have to scrap every OS kernel (which pretty much all scale to large number of cores today) and every hosted language environment (which are all ultimately written in C/C++) and rewrite them in Haskell.
Careful readers (who read the references at the bottom of the article) will note the author clearly has an agenda having to do with more automated resource management in C++. For whatever reasons, it has not found it's way into the standard until now and in his frustration, he's lashing out at not just C++ but basically the entire installed base of computer technology (mostly built on top of imperative, manually memory managed languages like C and C++).
It's worth re-reading the quote again: "Imperative languages offer no protection against data races"
...and this is true. An imperative language (in and of itself) has no protection against data races. That's not to say that imperative languages can't have code without data races. It just means that the language itself offers no protection.
Functional languages (basically only Haskell - I consider Scala an imperative language) have protections due to the Church-Rosser theorem[1], which states that (in essence) pure code can be executed in any order and there won't be any race conditions.
The rub (which is what I think you're getting at) is that it's dubious whether languages like Haskell are practical in a real-life production environment. Imperative languages "get things done", and given judicious use of appropriate libraries may be able to do concurrency just as well if not better than a purely functional language like Haskell.
I don't know any languages that are practical in a real-life production environment. They all kind of suck in their own special ways. What makes you think Haskell's practicality is more dubious than any other?
The author is on this thread, so maybe he'll answer you. Of course you can do these things in C++, but does anyone really want to when there are languages better suited to it?
> That conclusion on squandering the power of new hardware is being backed by absolutely zero data
I believe that the C++ language and its philosophy are in direct conflict with the requirements of parallel programming. This conflict is responsible for the very slow uptake of parallel programming in mainstream software development. The power of multicore processors, vector units, and GPUs is being squandered by the industry because of an obsolete programming paradigm.
It's not an opinion. It's a simple matter of observation. I see software all around me (and I write some of it) written in C/C++/Java and other imperative languages scaling perfectly fine on large scale multicore systems. I use linux, OSX, Android and iOS on a daily basis. Almost all the code running on these boxes is written in imperative languages, much of it written as parallel, shared memory code.
Google (where I used to work, but I don't think I'm revealing any secrets here) runs a gigantic cluster on foundational software almost entirely written in multithreaded C++ with the kernel written in C of course (some of the application level stuff is in other languages, but still a whole lot even at that level is in C++). Almost any large scale, parallel computational systems you could name are written in imperative languages.
To call all of the above "just my opinion" is simply denying reality. There's no further argument to be had unless there's a basic, shared reality ground to stand on.
What you're saying, basically, is that it's not an opinion because you're right. That's...not a very good point.
Pointing out that most parallel systems are written in imperative languages doesn't help. Most systems in general are written in imperative languages, so it's unclear what you're even comparing it to. Imagine standing on a street corner in 19th century England saying, "What do you mean that open sewers aren't as nice as closed ones? Look at all these sewers; they're all open!" Similarly, "but dude, Google!" just isn't responsive to the argument at hand. An easier-to-grapple-with framing might be: if FP languages continue to grow in popularity, will it become much easier to build parallel software?
I don't actually know, and I'm not even claiming you're wrong. And it's a predictive claim, so you could argue the semantics of whether it's an opinion or not. But your argument sucks and your pretense that your view is some sort of law of nature is lame. It's completely reasonable for someone to disagree with you on how good C++ is for parallelism.
The original claim that this subthread is arguing is that the multi-core processes are being "squandered" somehow due to the deficiency of C type imperative languages. I'm pointing out that I see all those multiple cores gainfully and heavily employed using nothing but the imperative languages so primitive, that they are being compared to open sewers of 19th century London at this point :-)
"Ease of writing parallel software" was never the question we were arguing.
The C++ problem with concurrency is not that C++ can't efficiently do concurrency (as you state, it definitely can), but that it can't safely do concurrency, therefore it's a big draw on programmers, debugging and productivity.
Exactly. the reason the parallel computing is being "squandered by the industry" is because it seems to be too hard to do. There is no "ease" of parallel programming and hence no one does it
I was under the impression he was speaking of parallel programming (software algorithms utilizing parallelism,) not sequential code running in parallel.
If you want to get into proper parallel numerical algorithms, most useful programs are C, C++, or Fortran, sometimes with CUDA or OpenCL kernels. I don't think I've seen any large-scale HPC applications in Haskell, as much as like that language.
I'm not trying to be argumentative, I'm just trying to clarify my perspective, which I think the author shares with me and I feel is not being understood. We know what has worked in the past. To me the author is saying functional programming with language features helpful for parallel programming is a better path to take. If I say I believe electric cars are better suited for the future and you say millions of internal combustion cars exist and work just fine, you haven't told me anything I don't already know or addressed features of electric cars that you feel make me wrong. That a large electric car infrastructure doesn't exist yet also doesn't disprove anything. The internal combustion engine is going away and so is C++. That's my opinion.
"I was under the impression he was speaking of parallel programming (software algorithms utilizing parallelism,) not sequential code running in parallel"
The argument was about squandering the powerful multi-core hardware because of deficiencies in imperative languages. No notion of some platonic ideal of a parallel application was raised.
My point is that the "squandering" claim is clearly and obviously false as I argued above.
I agree that the use of the word 'squandering' is provocative and incorrect. reddit points out that he is evangelizing Haskell (FPComplete) and trolling C++ users on Twitter ("I used to be a C++ masochist") He doesn't make his financial bias clear in the article, which would have been helpful for those not familiar with him.
Ouch! Ad personam attacks are a sign of desperation. For the record, I used to work for FPComplete (I architected the School of Haskell) but I quit. It was an interesting experience, having seen a whole complex web site and an online Haskell IDE built in record time by a few Haskell programmers.
Sorry man! If you read the rest of my posts I was agreeing with you. I was just trying to address the reaction chetanahuja had to your article to say I wasn't blinded and had healthy skeptism, but I still agreed whole-heartedly with you. C++ is great for special circumstances but I'd hate to have to go back to it for general coding. Functional programming offers some very intriguing ideas, which I'm only starting to grasp. I don't really mind you being provocative because it provokes and discussion follows.
The author clearly didn't say that C++ was the worst language he's ever heard of. He didn't necessarily even say C++ is a bad language. What I'm reading is more along the lines of "Ok sure, C++ was important at one point in time. But in 2013, we have lots of things to worry about that C++ doesn't help us with that other languages do help us with."