Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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



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


> "Ease of writing parallel software" was never the question we were arguing.

You wrote this at the top of the sub thread:

> If it was that difficult to implement parallel programming in imperative languages...

Now you want to make it about squandering. You seem more focused on being right than having a discussion.


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.




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

Search: