[rabidgnat]

It's not some silly vision of the future, but an oversimplified version of today! A brief and incomplete list of applications I use in a typical day:

Remote storage and/or processing: GMail, Google Docs, Weather.com, Reddit.com, Hacker News, Outlook web client, Google.com, DuckDuckGo, Delicious, Facebook, Github, tens of blogs/articles, online help documentation for, well, everything

Local storage and/or processing: Windows+Linux, Firefox, Chrome, Outlook, Visual Studio, Emacs, Python (or other dynamic languages), Acrobat, Amarok, random Unix utilities, various games

Most of my applications exist solely to present data stored elsewhere. I see no reason the trend won't continue: for instance, why would I compile C++ code on my machine when I can farm it out? Why would I store flat code files on my machine when I can have synthesized views of the code I need to see at one time?

Split up by time, most of my attention is spent manipulating or displaying data from somewhere else (or that could be stored somewhere else)

Games show that there are exceptions

[kenjackson]

Even if all that is true, the server apps have to be written by somebody. They don't get written by themselves. It's not like whole program optimization of your C++ application in the cloud just magically happens. The same team that wrote the C++ app on your desktop is going to need to figure out to optimized across your application, and in some cases it is more difficult as they 'll be dealing with multithreading within a box and multiprocssing across boxes on the server. And then they have to work on optimizing data transfer, from one cloud to another (since presumably the cloud you build on isn't the cloud you debug or edit on).

The world just got more complex, not simpler for devs.

[rabidgnat]

But my original point is that there's one dev team in the middle of this dealing with concurrency, and any number of remote applications that can use it through a library because someone else worried about the hard parts. There isn't a day of reckoning where developers as a group worry about efficient concurrent computation, it's the few guys in the center.

[commieneko]

You are describing a project, not the world. We break the world up into projects so we can manage them. No one has be able to come up with a way to manage the world (so far.)

The next step in understanding "the cloud" is that it is actually "clouds." Some connected deeply, other's loosely, some held in jealous, secretive isolation. There are clouds within clouds, and some clouds are outside the light cones of other clouds.

I will describe a place known as "the pit." The pit has power wires going in, and that is only out of compelling necessity. (If they could make carrying in batteries work, they would.) Equipment, data and people go in, but only people come out. The pit is a crowded place. And there is much processing of the data; decisions are made, the world changes.

We all have our own personal pits. Or least we should.

[kenjackson]

Where is this one dev team that is dealing with concurrency? I don't see how you do this? At least not with the current state of the art in concurrency technology. They can provide some basic tools like concurrent collections, but the hard work is still app-dependent. I still need to figure out where concurrency makes sense. I still need to figure out when data races are OK and which ones are a problem. I still need to be the one to put locks in my code. It's not like I can just push up the source code to Photoshop and say, "Make it concurrent now please".