In the last couple of years, we have seen the rise of the netbook, the smartphone, and languages like Python and Ruby. Each of these are, apparently, "fast enough" to be highly succesful.

Applications are also changing: casual games, Farmville and even World of Warcraft have very modest system requirements but make a ton of money. Web applications are awful from a performance perspective: they are crippled by network latency and need a single server to do the work for many people. Still, they are "the modern way" to write an application. Again, the performance is "good enough".

Finally, even when performance is needed, there are different models for parallel programming than multicore. GPUs are very fast data-parallel "single core"-like devices. At the other end of the spectrum, real-world "web scale" systems scale horizontally and are thereby forced to adopt a multi-process model.

Yes, our OSes should be written for multicore, the newest Doom/Quake should be written for multicore, and our numerical models should be at least aware of multicore; but despite the fact that the C programmer in me will likely be happier in your multicore world than in the world I sketch above, I think most programmers will live in the latter.

I don't think that's accurate - being "single core"-like. Besides literally having multiple execution cores, GPUs are radically data-parallel in ways that even those already familiar with data-parallel code (using languages such as OpenMP) must still adapt their thinking. Code that extracts high performance out of GPUs must be aware of the memory hierarchy and degree of parallelism - you can't pretend you're doing sequential programming.

But I agree, "single core" isn't really true.

These days I think energy usage is the overriding concern, both because of thermal limits in high performance systems, and energy budgets in low-power systems. A smartphone which is fast enough to play Farmville or run a python interpreter is cool and sells well, but there is still a huge economic incentive to cut energy usage further, since that would increase battery life.

The core of your argument seems to be that since things like netbooks, smartphones, Python and Ruby are currently "fast enough", there is little incentive to increase the core count. I disagree with that, because energy savings will (or would) still add massive economic value. Whether these kinds of systems will become reality is a different question, since of course programming them is a very hard problem.

But how cool would it be to have a smartphone with 100 cores, each running at a few MHz or so (and apps which use them efficiently) and battery life of a month or so? Also, think of how motivated companies with datacenters are to reduce energy costs.

For consumer purposes. However, a ginormous amount of the software in operation today is not aimed at consumers at all, and don't resemble Farmville in the slightest.

Most programmers are writing COBOL (even if they are using a slightly more modern language to do it in.)

If the above is not an answer to what you meant, could you please clarify?

The tool I have now allows people to write multi-process programs and have them communicate effectively. I'm still trying to get permission to release the system as open source, or at least publish the ideas, but the industry is notoriously secretive and conservative, so it'll be some time yet.