wllm

A friend of mine who’s been thinking about the cloud for a while now came by last week for dinner. Not only does he grok what I’ve been calling the metacloud, he’s already thinking about (and building) a ‘cloud-native’, object-oriented language to program it. After a couple of beers- both drunk by me- he and I took a flight of fancy listing the features any self-respecting cloud-native language should have. Here’s what we came up with:

1. Context. An application has to have a way of looking up the resources it needs at runtime. This could be in the form of a library like JNDI for Java, only built in to the language. Moving on. . .
2. Portable objects. The language shouldn’t care in what memory bank- or in which cloud- an object happens to reside; it should only care about getting a the right reference to the right object and doing the right thing with it. To get full credit for this one, we’d have to figure out some mechanism to leave marshalling/unmarshalling headaches behind us. Misha thinks the answer here is to pass behavior along with data over the wire. My gag reflex kicks in at the thought of all the accompanying security issues, but if security in the cloud were based on trust, open standards, and capabilities combined with disciplined adherence to the principle of least privilege, it just might work.
3. Orthogonal persistence. OK, I didn’t know what this meant when Misha said it, either. But the concept is simple: no distinction between in-memory storage and persistant storage. The corollary here is that the language would have to have built-in query primitives. And, if LINQ is any indication, that may not be such a bad idea.
4. Observers. Cloud-native languages won’t have to just support massive parallelism; they will have to warmly embrace it. But few day-to-day problems lend themselves to centrally managed processes, and those problems typically involve heavy computation. Of course heavy computation has its place in the cloud, but most computer resources are actually devoted to distributed data manipulation nowadays. Whether it’s one service in your SOA app talking to another or Facebook talking to Twitter, changes in state have to be propagated to many systems which handle them in different ways. We believe the observer pattern comes in big here. In fact, so big that it may not hurt to have common observer patterns like pub sub and priority queues baked in.
5. Relationships. OK, here I am pushing my relationships agenda again. To recap, I think relationships like ‘parent’ or ‘customer’ are the most important untrapped- and untapped- construct in OO languages, although I’m still trying to convince my friend of this. It’s not as if the problems that the semantic web solves go away in the metacloud. In fact, with queries as language primitives, relationships may just be the most powerful new innovation in language theory since the turn of the century. C’mon people. Give relationships some love, already.

So, what have we missed here?

,Wil