I'm still not clear on why multithreading is left in the hands of the programmer
Well, largely because it's difficult/impossible to do automatically in traditional languages, and people are used to traditional languages. To make it automatic, you have to change how people *think* about programs, and that's not easy.
Google's demonstrated that the MapReduce paradigm is a good example of a shift that leads to inherently parallelizable programs.
Oh, absolutely, and it wouldn't surprise me if that proves to be one of the primary shifts -- that that will push down from "architecture" to "libraries" to "language" pretty steadily. But that simply underscores my point that a programmer can't afford to be complacent in how he programs nowadays, because tomorrow it ain't gonna be the same.
(Which reminds me that I really need to get more comfortable with MapReduce myself: I've never worked with that particular architecture, and I owe it to myself to grok it deeply enough to know when to use it...)
Re: That was my first thought....
Well, largely because it's difficult/impossible to do automatically in traditional languages, and people are used to traditional languages. To make it automatic, you have to change how people *think* about programs, and that's not easy.
Google's demonstrated that the MapReduce paradigm is a good example of a shift that leads to inherently parallelizable programs.
Oh, absolutely, and it wouldn't surprise me if that proves to be one of the primary shifts -- that that will push down from "architecture" to "libraries" to "language" pretty steadily. But that simply underscores my point that a programmer can't afford to be complacent in how he programs nowadays, because tomorrow it ain't gonna be the same.
(Which reminds me that I really need to get more comfortable with MapReduce myself: I've never worked with that particular architecture, and I owe it to myself to grok it deeply enough to know when to use it...)