skwpspace yan pritzker’s home on the web

The next high level language

When we used low level languages like assembly, we had to care about how the computer performed every step of our operations. With the advent of mid level languages like C, we no longer cared about registers, but we still had to know how memory was managed. With the higher level languages (Java, Ruby, Smalltalk, Lisp) and object oriented, functional, and event driven programming, we don’t care as much about how the work gets done, but program closer to the problem domain. As we create sets of objects that are more and more complex, we crate libraries and platforms. On these platforms, we create web applications.

Now we’re mashing up web applications themselves, creating more and more complex applications by building on top of existing APIs. As the register was to assembler, the array to C, and the object to Smalltalk/Java/Ruby, the web API is now a building block of the platform called the Internet. So what will the next high level language look like? We will no longer concern ourselves with objects, but rather services. Standardization–whether in the form of microformats and loosely defined service ontologies or the true semantic web with all its rdf madness–will bring power to this platform.

The code we write tomorrow will create web applications and new services with just a few lines of code which integrate services from all over the web. We’ll be able to register event callbacks not just across our local objects, but across web services themselves. Call it Web Oriented Programming.

Here’s a little implementation of a Facebook driven buddy-beacon type of system in this fantasy language.

at_url("/map_my_friends") do
  @map = Google.render_map(:center => 'Chicago, IL') do |map|
    map.add_data(:source => Facebook.get_friends.locations)
    map.add_data(:source => Yelp.my_favorite_places)
    map.add_data(:source => Planypus.my_plans)
  end

  Facebook.on_update(:attribute => :location) |user|
    @map.alert("#{user.login} has changed his location")
    @map.show_at_coordinates(user, user.location)
  end
end

This isn’t too far from what’s possible today, and most of today’s ugly implementation details deal with glue code and translation between the languages of different services. The development of a standardized ontology will get us a long way toward having one-liner service integration.

Now…let’s make it happen.

You really don’t need a new language to make that happen. Do it in Ruby/Ruby-on-Rails, as an extension.

The real problem is simple — there’s no way to really make different web services consistent, so your implementation is always going to have to specify the resource. What you’d really like to be able to do in a language is reference something like “Friends.list” and have the language not care if the friends list is being drawn from Facebook or MySpace or LinkedIn or whatever — your app would simply be able to invisibly get access to the data you need, and the data would be in some consistent format.

Reality, of course, is that doesn’t happen, and will likely never really happen unless everyone really gloms on to open standards. But open standards aren’t even consistent, and implementations rarely are. So you’ll need to write special code to know that if your friends are on Livejournal, they might belong to separate groups, while on LinkedIn, it’s just one big friends list. If your app is going to do something with group logic, it has to know that the source may not support it.

And, of course, one would really like to treat all the different services as an invisible cloud, so that if I accees “My.friends”, I’d get a comprehensive list from *all* services, not just one.

…Paul

You’re absolutely right. As I said the pseudocode I wrote is even possible in Ruby today (or any other language for that matter plus or minus some syntactical ugliness). It’s really about the implementation. We could write a library on top of every api out there to make them look and feel the same, but what I’m imagining is the level of dynamism we have in Ruby today with objects, having that across web apis.

So instead of object.respond_to?(:to_s) I would be able to say friend_service.respond_to?(:friends_by_location). Then you can imagine API’s that can be implemented by multiple services. So friend_service could be facebook or myspace, or any new service that comes out tomorrow that implements the same api. For example both Facebook and Planypus would implement a friends_by_location api supporting some standard (FOAF-style for example).

Standards may not ever be perfect but hey we all agreed to some extent on what html, xml, and css mean…why can’t we do the same for a standard set of ’social services’, at least to a basic extent. OpenSocial is a big step in that direction and is already seeing some uptake by major companies. I think it could be the building block of a service-agnostic social platform.

You’re thinking semantic web, I think.