But arguably this smaller set of programmers have high impact. So it would be a little presumptuous to dismiss the need to understand parallelism. Notions, as those held by the author of the blog post, can have a few undesirable effects. One, it discourages new hackers from messing around with parallelism, which may deny him/her of an opportunity to have a high impact. Two, though it is true that it is not necessary to know the inner workings of a car to drive, sometimes it helps.
But may be hackers weren't the target audience in the first place.
This is already the case with systems programming in general. The set of people who can program competently in VM-based languages is much larger than the set of people who can program competently in C.
I agree with you. But wouldnt it be good if high level languages supported concurrency. This would make it easier to program certain tasks. A popular opinion I encounter often and also reflected to an extent in the article is that such a route has no merit.
There is no reason to believe that HLLs have to be particularly inefficient (for example the scheme compiler stalin can hold its own and often run faster than an equivalent number crunching code written in c). I am not arguing that Python should be that high level language, but that the current state of "divide" (c for programming servers python for apps) is a little artificial and is a result of a lack of options. Not grappling with parallelism only makes the scene a little more entrenched.
I find X10, Fortress and Chapel quite exciting as they are trying to straddle this gap.
I'm all for models of parallelisms in high level languages. I was pointing out that writing parallel programs without high level models - such as using Pthreads or MPI directly - will probably remain at the systems programming level.
I think we'll need to add models of parallelism to high level languages, and most programmers will have to deal with it. But, that's not a given. This author is on the other side: maybe the majority of programs will be able to remain sequential, and we can allow the exploitation of multiple cores to happen mostly at the OS level through the scheduler.
