Parallel Evolution, Not Revolution

It seems to me you're equating "parallel" with "distributed". The eBay-example is how we've been using databases since database servers became common. If *that's* parallel, the word adds nothing, and we can just use "programming."

Parallelism is no fun, especially not for its own sake. You use it when you hit a performance wall (HPC, graphic rendering etc).

Time to market and correctness of software beat pure performance. As with the Ebay example above, people will USE parallel code, but they are less likely to WRITE parallel code themselves.

I like to say that over the years, the only constant in optimization has been C. Not the language, but the speed of light. That is to say, data locality was an issue when people were allocating registers by hand, and it's an issue today when deciding what parts of a web app to write in JavaScript on the client.

To be more specific, these days I'd say that the data has to travel less than an inch, you probably don't need to do any optimization since most operations don't run more than a hundred times in a second. If you're calling out to a database or non-SSD disk, then you at least have to think about optimization. And if you are writing a web application, then you really need to think about the distance between the client and server.

Interesting take on parallel (//). I'd argue that explicitly // kernels (not just multi-threaded, but truly //) and MPP have an important place in the // programming taxonomy. Loosely-coupled systems bound together in what I call "Blind Optimistic Horizontal Scaling" (BOHS) with unknown (and possibly un-knowable) pathologies have been recently responsible for a variety of "CNN moments" for brokerage firms and banks. Parallelism is only as useful as it is provably correct. Not there yet by a long shot.