This multithreading thing...
(I found this in my collection of drafts for my previous blog. Apparently I wanted to write about it but never got around to it. Bij deze dan.)
A few years ago I found this question on Google Moderator. (I don't know when this was written; it has no date on it, but my draft was from October 2008, so it must be at least two years old.)
In short, Guido van Rossum is asked how the Python community will address "the evolving multi-core programming paradigm". The gist of his answer is,
"I think the panic is greatly exaggerated. We are *not* all going to have to write multi-threaded programs all the time. It would slow productivity to a grinding halt anyway, due to the extreme difficulty of writing correct concurrent code using the current crop of mechanisms."
This draft piqued my interest again for two reasons. First, I have (re)started studying Clojure, which of course addresses the concurrency issue. I think this is a major reason why it's gaining traction. (Being able to use Java libraries, and having the flexibility of Lisp, doesn't hurt either, of course.) Second, the other day I had to shop for a new machine for work. I noticed that even the low-end eMachines model that I picked up, has a dual core processor. MacBooks have been exclusively multi-core for a few years now, IIRC. So, having ubiquitous multiple core machines isn't the future -- it's already here.
In this light, the above comment doesn't look too good, because it essentially says that Python (as a language) isn't going to do anything special to work with multiple cores. Sure, the multiprocessing module is cool, but I don't think it will be enough. I think that in the (maybe not so far away) future, languages that take advantage of multiple cores, and make it easy to do so, will win.
Of course, this is hardly a new idea; for example, here's a presentation by GLS giving an excellent explanation about the issue. At this point, most (mainstream) languages are woefully ill-equiped to deal with these issues.
My point is, as a long-time Python user, I think that the language will be unable to adapt. A proper multicore-using Python would have to be rewritten from scratch, would likely need many new constructs, and would simply no longer be Python.
Maybe I am misunderstanding the issue, but... as the number of cores in machines grows, and you have the choice between:
- language A, which was designed to use only one core (thread) at a time, and in which it's cumbersome and error-prone to use multiple;
- language B, which was designed to support concurrency from the ground up, and which scales over any number of cores without needing any special code;
...well, that is not really a choice at all.
I don't know what the programming language world will look like in ten years. I am notoriously bad at predicting these things. I do think, however, that functional languages have the best prospects here.
<idle_speculation> It would be interesting to have a language that supports concurrency like Clojure does, with Pythonic syntax and possibly idioms... I wonder if such a beast would be possible, and what it would look like. It wouldn't be an imperative language... but that doesn't mean it could not look like Python, or use some of the lessons learned there. Hmm... </idle_speculation>