All Applications will be Web Applications

I often mention this in my classes and other talks: it is clear that the majority of new applications will be web applications (not all of them, of course, that is just standard headline hyperbole).

Jeff Atwood gives some more reasons as to why this is happening. Basically, people like web applications because they don't have to install them or worry about what happens when they get a new computer, business like web applications because they don't have to worry about installing their custom software on every PC. We can see old desktop applications, Quicken, being replaced by web versions Mint which are better in many ways.

But the real draw of web applications lies in the interconnectedness they allow (see the photo above for an example). These applications are also services and provide REST API's for other applications to plug into them. In this way each application is also a programming library (remember DLL's and .so files?) and a database with up to date information. Thus, even the so-called desktop applications of the future will also be web applications in that they will suck down data from the web, like Google Earth. I am still trying to figure out what the proliferation of all these REST APIs and microformats will mean for multiagent systems, but I can't help but feel that this is good news for the field.

So, what does this mean for a new student? First of all, it is still programming. While you might be using a slightly higher-level language, you will still be writing for-loops, recursive functions, and lots of if-then statements. No one has invented a language that can eliminate those. Thus, nothing much changes. One still needs to have solid programming experience and knowledge of algorithms.

On the other hand, the architecture for web applications is different from the standard desktop. In a standard desktop application you write event handlers that run whenever the user clicks on a button. In web applications this becomes more complicated. You can write your JavaScript to handle events from the user, just like in a desktop application, but you also have to deal with the client-server communication (AJAX magic). This raises all sorts of very interesting questions about what activities should be handled in the server versus the client. For many of the current set of applications the decision seems easy (gmail) but it is not as clear for others: should mint.com generate their pie charts server-side or client-side? The decision depends on the user experience you are after as well as the capabilities of the client and server devices and the network that joins them (wired, wireless, reliable, spotty).

It is very exciting to realize that allowing others to use your software is as easy as emailing them the URL, and that they can use your software on their PC, netbook, smartphone, set-top box, kindle, etc. etc.

The Functional Web

REST triangle of nouns, verbs, and content types.

There is a new short article by Steve Vinosky introducing his new (really, re-named) column: Welcome to the Functional Web. The new column acknowledges the domination of the new distributed (web) programming paradigms. As as note of background, I have been reading Steve for many years and I can attest that he knows what he is talking about. He is not one the many architecture astronauts that so often publish on academic journals. Steve actually builds systems. He knows what the real problems are, and often provides realistic solutions.

In this article he tells how after years of building distributed applications using Java, C++, and middleware technologies (SOAP, WSDL, CORBA, etc.) he has decided that a much better approach is to use functional programming languages (Erlang, Ruby, JavaScript) and RESTful services:

After pondering this problem for years, I finally concluded that our efforts were ultimately most impeded by the programming languages we chose. C++ and Java affected how we thought about problems, as well as the shapes of the solutions we came up with, far more deeply than I believe any of us realized. Add to that the verbosity and ceremony of these languages, and the net result is that we wrote, debugged, maintained, and extended a significant amount of code that wasn’t directly helping us get to our ultimate goal. We were fundamentally blocked by our inability to change our chosen programming languages into vehicles for application distribution

This is a very exciting time for those of us who are interested in multiagent and distributed programming. We are now seeing an explosion of REST services. You can barely browse the web without tripping on yet another REST API. There is a lot of data, there is a lot of functionality, there is a lot of possibility: how do we discover and create mashups automatically? how do we make it easy for programmers to integrate these various we services? how do we use this distributed data about individuals to create new services? emergent services?

In any case, I look forward to his upcoming columns, and his blog posts.

Update: Here are his presentation slides from a talk he gave on the history of RPC and why industry has moved on.