I remain unconvinced that software development will ever be able to make that kind of a titanic shift; people naturally think in serial and accomplish tasks in

I remain unconvinced that software development will ever be able to make that kind of a titanic shift; people naturally think in serial and accomplish tasks in serial, and many programming tasks simply don't break down neatly into highly-parallelizable chunks. For example, you can parallelize at the web request level, but are you really going to start parallelizing the rendering of the output of that request? Would you bet your website on you being able to get that 100% correct, or would you rather trade off some speed for the sake of correctness and implementation ease? To put it another way, parallelization is a cost-benefit analysis; having more cores changes the "benefit" side of the equation but not the "cost" side, and I don't see any magic bullet coming that will drastically alter the "cost" side. Increased use of multiple cores at the lowest level will only happen thanks to better tools and frameworks that keep people from having to think about threading/parallelization themselves. As soon as you have to worry about ordering dependencies, you've entered a world where implementation is very difficult and testing/verification is nearly impossible. Most applications right now are "fast enough" to make correctness and implementation ease far more important concerns than raw speed. So you might see people migrate to frameworks that allow for easier parallelization, and web applications will obviously benefit, but I doubt you'll see any fundamental change in how people write software.