That hardware will continue to expose more levels of parallelism is almost certain at this point.
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.
Exactly. Moreover, most programmers will simply use high level primitives from some library where concurrency is deep buried, so they won't need to worry about it at all.
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.
Exactly. Moreover, most programmers will simply use high level primitives from some library where concurrency is deep buried, so they won't need to worry about it at all.
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.
what was your point then, if not that programmers won't need to know concurrency because it will be in black boxes that they haven't written? (Bear with me, I'm a bit dense at the moment. I haven't had much sleep the last while)
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.
>what was your point then, if not that programmers...
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.
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.