Nevertheless, you can still see what Paul is trying to get at: CS curriculums are woefully under-preparing their students for a parallel world.

It's worth pointing out that the "speed-of-light collides with 20+GHz serial processor" See http://www.hppc-workshop.org/HPPC07/Vishkin_HPPC07.pdf

That most software will consciously need to exploit that parallelism is not as clear. It's possible that some applications will be able ignore parallelism, but overall system performance can still be improved by being able to schedule multiple processes in parallel.

I suspect that people that talk about everybody using concurrency by themselves haven't thought what the future applications will use CPU power for. 3D graphics, IA, image and voice recognition... all these applications are susceptible to be encapsulated in some black box and used through a simple API. In fact, how many programmers are using right now complex APIs? I think it's a tiny fraction. It would be naive to think that suddenly the new generation will be full of highly skilled programmers.

Web apps is a clear example of heavily concurrent application where concurrency can be simply ignored most of the time by most programmers.

And who writes the libraries? I'd suggest that if you're only gluing together libraries, much of a rigorous CS training is wasted anyaways. You could do just fine with very little formal training on algorithm design and analysis, and a rather shaky understanding of the fundamentals of algorithms, if that's all the programming you do is. You're probably better off with a trade school.

If you're going to be doing anything challenging in the programming domain, you'll want a good grounding in concurrency.

I still think that programmers that are actually doing more than simply gluing together premade libraries will need to be familiar with concurrency, and that anyone taking a theoretical computer science degree to graduate and glue together libraries is probably overqualified.

No, not "programmers", but "some programmers" or "a lot of programmers". Of course there we'll be always people that has to do the hard part of whatever, but it is a minority now and I'm afraid it will still be a minority in the future.

Don't think that everybody is as snart as you or your buddies. No sarcasm, I really believe that you get it better than my points ;-) In my experience the concurrency is written always by the same person (guess who), in the best case, that it.

That doesn't mean that I think it shouldn't be taught. Only that I'm skeptical it will solve anything.

Google adds a pinch of concurrency to its web browser (each tab running in another thread) and it improves the client side experience.

The main touted benefit I've heard of Chromium's tab-threading is insulation, so if one tab crashes it doesn't bring the whole browser down.

At any rate, speed can be increased substantially without faster hardware, but with: (1) efficient implementations of javascript (Chromium); (2) faster Flash (AS3 + AIR); (3) web-friendlier Java (JavaFX); or even Sliverlight.

But the nice thing about faster hardware is you get faster apps without rewriting or learning new tech - opps, unless that faster hardware is many-core[⁎]...

Another reason to not need many-core is that desktop apps are already fast enough for the staples (word processing, spreadsheets). Hence the rise of sub-notebooks, the iPhone, and the best-selling games console being by far the least powerful (wii).

[⁎] many-core (as opposed to multi-core) technically means heaps of processors - tens or hundreds. It is a qualitatively different situation from one thread per processor.

However, if universities start teaching programming with pure functional languages (which is highly unlikely), concurrency becomes a much easier topic for discussion.

Perhaps this is the sort of thinking that will lead to more universities adopting something like PLT Scheme, which in recent versions, has moved the notion of mutable pairs into a library. Doing this might bring functional languages out of academia and more into the mainstream, which would be fantastic.

I remember fellow students having trouble grasping pointers, even after a 2nd year architecture course, which I thought was completely absurd since they were writing assembly code without tremendous strain.

One of the things that doing good OO and following the Law of Demeter does for you is to reduce the levels of indirection you have to deal with to one or two.

It's not the notation, it is the concept.

The old CodeWarrior debugger was great for this. Lots of windows you could pop up for every in-memory object you cared about. sigh

I agree. I don't think it should start from CS1, but you can start with the Dining Philosophers problem in CS1 to introduce the ideas of locks and starvation.

that is because you have slept through the entire revolution of share-nothing concurrency

I, just this afternoon, heard Guy Blelloch give a talk about Parallel thinking today, and he seems to support the idea of teaching parallel programming throughout the curriculum almost instead of sequential programming--making sequential thinking the oddity. I think this makes sense, but it obviously has some flaws...

I don't know that I agree with that at all. My first college CS class taught Java, definitely supports concurrency. It's not Erlang-like concurrency, but concurrency nonetheless.

Theres a trend to start teaching Python as a first language, that supports it as well.