(August 5, 2005) - I’ve been around software for 20 years now. Looking back, I have mixed feelings about the progress we’ve made. The end results have been amazing but the process of building software hasn’t fundamentally changed since the 80s. In fact, I see us make some of the same mistakes over and over again. One of the common anti-patterns is over-relying on tools and frameworks instead of inventing new programming models.

Layers of abstraction are fundamental to software. Some layers are defined through programming models, e.g., machine language, assembly language, 3GLs, JSP. Others are defined through a combination of tools and frameworks, e.g., MFC and Visual Studio on top of C++. There is a limit to how high we can raise a level of abstraction through tools and frameworks alone. At some point, a new programming model is the best way forward.

Here are some examples: CASE tools on top of 3GLs never achieved the success of 4GLs; tools and frameworks for Web application development, from CGI + your favorite language to WebObjects to HAHT, were demolished in the market by page-based Web application development models such as ColdFusion, PHP, JSP and ASP.

What we have seen time and time again is that it is often better to come up with a new programming model than to keep pushing an existing model forward by throwing ever more advanced tools and sophisticated frameworks on top. Think of a building. Programming models are the floors. Tools and frameworks are the walls. To build a tall building you need to strike a balance between the number of floors and the height of walls. Beyond a certain point, an extra foot of room height adds very little to the quality of a room but increases the cost of the building substantially.

When should one create a new programming model as opposed to go with a framework and/or tool leverage? What is a programming model anyway? Tough questions, both of them… The first is impossible to answer perfectly or quickly. The second question is a little easier because you can often recognize a new programming model when you see it. One key observation is that you don’t necessarily need a new programming language, as JSP and ASP demonstrate. Sometimes, it is sufficient to create a domain-specific template or wrapper into which existing programming models fit. Also, new programming models may come with their own set of frameworks and tools.

I have some first-hand experience creating new programming models. At Allaire we defined the page-based Web application development model with ColdFusion and later helped the Java community get its act together with JSP and tag libraries. Later at Macromedia, we defined the model for building rich Internet applications (RIAs) with Flash and Flex, something Microsoft will try to catch up to with Avalon in Longhorn (now Windows Vista). In between, we did a lot of work on SOA programming models, though with the burst of the tech bubble we decided not to ship this as an independent product but instead contributed the ideas to Apache and to existing products internally.

Here are some thoughts on two programming models that I hope we can significantly improve in the next few years.

Rich Internet Applications (RIAs) 
You have to admit, we did take a step back in usability with the Web. We can build easily accessible applications quickly, but wouldn’t it be nice if we didn’t have to go through 10 screens to make an airline reservation?

What we need are applications that have the deployment characteristics of browser-based applications but have equivalent power and more interactivity than desktop applications. That’s what RIAs are all about. They bring complexity on two levels. First, computing happens on both the client and the server over a potentially unreliable WAN. Second, they aim to deliver highly interactive user experiences (UEs). Don’t blow that second requirement off. Research clearly shows that users respond better to these types of interfaces. Who wants to use old-style Web maps when you can go with Google maps or the Flash-based AbMap?

A good RIA programming model will protect developers from the details of location, i.e., the tasks associated with synchronizing data shared between the front- and back-end, invoking back-end services, dealing with online/offline operation, etc. It will also have an advanced rendering engine, preferably one that is cross-platform and device independent, and a presentation model that hides much of the hassle of resolution, screen orientation and internationalization. I’m very biased in making this claim but the only commercially sound approach to RIAs nowadays is with Macromedia Flash and, better, with Flash and Flex together. Microsoft Avalon is the closest competing technology. It has yet to ship. AJAX, contrary to what many believe, has been around since at least 1998 but didn’t have a cool acronym. AJAX + DHTML offer an alternative but there has been little success moving from specific cool apps to a generalized programming model. Java doesn’t cut it, primarily for UE reasons. There is plenty of room for improvement.

Don’t forget mobile applications. More than PC-based applications, they really need a makeover and there are a lot of dollars at stake. Microbrowsers are trying to find ways to bring AJAX + DHTM ± WAP to devices. Java has deep market penetration but poor UE. Brew has the best device integration but is similar to Java on the UE front. Flash Lite is gaining traction here because of the great UE it enables.

Composite Applications
There is no question about it - you can build composite applications using Java, .NET or any other programming language for that matter, just as you can build Web apps using C++ and write admin scripts in Cobol. Why would you, though?

One of the cornerstones of SOA is that services can be implemented using anything. That’s great but traditional approaches for writing the glue code between services leave a lot to be desired. What we need are deeper and more declarative mechanisms for putting services together. BPEL and the WS-* standards are both too much and not enough. Do this: print all the specs and stack them together. Now, think about how much ad hoc work you had to do to build, deploy and operate your last composite app. Do you feel comfortable with where the industry is going?

Building, deploying and operating composite applications requires dealing with issues such as policy definition and enforcement, service evolution/versioning, system/deployment architectures and post-deployment management and monitoring. This goes into what traditionally has been considered to be the IT sphere of influence, often a taboo area for development. However, I deeply believe that a winning programming model has to begin to address these issues. Just consider some of the complexities. How do you maintain applications over time as services evolve? How do you debug them? When something doesn’t work right in a production application, how do you track down the root cause? If you don’t address these issues during the architecture and design phases you’re in for pain down the road.

Talk like this takes us into the realm of utility computing, whatever that means (definitions still vary). Perhaps this is what’s necessary to make building, testing, deploying and operating composite applications easy. There is plenty of innovation in this space. Unfortunately, much of it is in the form of add-on products as opposed to a comprehensive programming model-driven approach to the problem. This is bad news for customers who run the risk of experiencing the dubious pleasures of vendor lock-in.

My personal wish list for innovative programming models is longer, for example, covering ultra-scalable applications that run on large clusters (>= 32 nodes). I even think that we can do a lot better with the decade-old Web application model. Just look at some of the work going on with Ruby on Rails. As both a technologist and an investor I’m excited about the future.