4 ms·

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

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.

chetanahuja 13y ago
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++).
- michaelwww 13y ago
  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 his opinion. > and is obviously false That's your opinion.
  - chetanahuja 13y ago
    >> and is obviously false > That's your opinion. 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.
    - michaelwww 13y ago
      I was under the impression he was speaking of parallel programming (software algorithms utilizing parallelism,) not sequential code running in parallel.
      - greatzebu 13y ago
        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.
        michaelwww 13y ago
        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.
- j_baker 13y ago
  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. [1] https://en.wikipedia.org/wiki/Church-Rosser https://en.wikipedia.org/wiki/Church-Rosser
  - mbrock 13y ago
    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?

chetanahuja 13y ago

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++).

michaelwww 13y ago
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 his opinion. > and is obviously false That's your opinion.
- chetanahuja 13y ago
  >> and is obviously false > That's your opinion. 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.
  - michaelwww 13y ago
    I was under the impression he was speaking of parallel programming (software algorithms utilizing parallelism,) not sequential code running in parallel.
    - greatzebu 13y ago
      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.
      - michaelwww 13y ago
        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.
j_baker 13y ago
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. [1] https://en.wikipedia.org/wiki/Church-Rosser https://en.wikipedia.org/wiki/Church-Rosser
- mbrock 13y ago
  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?