Some time ago I wrote about some limitations still blocking the scope of things like web applications. I was seeing how many different players in the industry were taking a new look at the problem of disconnected browser-based programs, which is one of the main shortcomings in this space. In the last month or so several important announcements has been made public, and some basic support for this scenarios are actually working right now.

For once, Google just released Google Gears, its browser extension that adds offline support for applications. This is in a very early stage and thus it is just adding basic functionality like a local web server to serve locally cached content, a small local database to hold data, and a little thread pool to ease the handle of asynchronous tasks. As several people noticed, there is a bunch of stuff that's still missing, mainly more features to handle different synchronization scenarios, which is something that the current implementation leaves to the developer. But for the first release, this API looks really promising.

On the other side of the fence, Microsoft recently released Silverlight, which has planned offline support although it is in an even early stage in this particular area. However, the scaled-down version of the .NET Framework runtime is a perfect sandbox strategy to provide this kind of services in a safe and easy way, and this is something they definitively ave in their roadmap.

At the same time, Silverlight brings another push to other area where web applications were often turned down: rich applications. While it is true that Flash is a well-established platform, so far it has been mostly used in areas like marketing, games and other niches. Microsoft is trying to push Silverlight and its promised simplified programming model to a wider audience, including business applications and other typical markets where Flash didn't penetrated much yet.

In the meantime, another huge trend both competitors are heavily pushing now is mashups. These are web applications built out of parts, much like you could build with components before, but in the lousy-connected scene of the web. Microsoft has PopFly in Beta, while Google has its own Mashup Editor.

What's interesting in this space is that you can built a valuable service out of already existing services and sources by adding very little code or configuration on your part, usually just connecting outputs with inputs. But of course, this poses a new series of challenges, like the need to store this configuration and data somewhere. As it is usual in the mashup style, you may not own or control the server where you are hosting your creation, so finding a store for your data is not that easy. Also, as this kind of strategy evolves, there is an increasing need to have a standard way to access some specific information which has a more complex structure than what RSS or Atom supports.

Microsoft came up with a very interesting approach to help in this issue with a project called Astoria. What they are trying to provide is data services over the web, and this really captivated my attention. I had always discouraged people to try to use web services as a data service, in the typical sense of exposing a "query" service over HTTP. This something I reconsidered in certain cases once we arrived to the point where we were talking about XML Services (without the "web" emphasis). My main concern was always the high-latency nature of the whole SOAP-HTTP combo. Providing data access over the web means that you need to add to the actual database access a lot of overhead in the form of packaging, connection and disconnection, etc. This can decrease once you use SOAP over TCP, etc, but still SOAP is not designed to handle this kind of situation.

Astoria take a more RESTful approach (basic background on REST architecture in Wikipedia). It is based also on the ADO.Net Entity Framework (another piece of yet-unreleased software) that provides a conceptual model over a given physical database schema (to follow me, just think of it as sort of Object-Oriented Database). An Astoria service provides an entry point to this model, where you can start by querying its content (like "http://host/vdir/northwind.svc") and get an XML with the entities (kind of tables). Then you can refine your URL based on this information, to access a specific resource. I won't make this into an Astoria overview, but what's important is that this allows you to get the equivalent of select, insert, update or delete operations over the web, with a fairly good throughput, and -more importantly- with a single consistent mode that allows tools to be very generic. For example, there are some sample controls for ASP.Net that will figura out the whole structure of an Astoria service and allow to navigate trough its data by using grids with sortable columns, filters, paging and editing without any other configuration than the entry point (again, this "http://YourServer/YourModel.svc").

The point I'm trying to make is that we are starting to see some forbidden territory explored. I guess that sooner than we expect we will witness how cities are built over there. Convergence is happening really fast, and the traditional lines we take for granted today between desktop, web and mobile applications are finally starting to fade. New technology and faster communications are accelerating it.

I'd just want that the level of quality of the produced solutions evolved as fast as its reach... What do you think?

Programming languages have gone a long path, as you can see in this nice diagram by Éric Lévénez. Throughout its history, programming was always searching for the perfect balance between several forces like expressiveness, productivity and correctness. While the first two evolved with object orientation, higher abstraction and an increase in composability (as more and more reusable algorithms and even executable code accumulated), correctness was somehow slower, maybe because it is a more complex problem, and maybe because for a relatively immature industry, the competitive advantage seemed to be more productivity-related.

As software became more pervasive in our daily lives, however, predictability and safety in execution started to be bigger concerns. Also, software lives more and more as part of an ecosystem, where dependencies on other services its crucial, and minor mistakes or errors get quickly magnified.

Verifying that a program is correct is a tricky task. For once, intention has to be clear to be able to know what to check. Then, inputs and outputs have to be clearly defined, allowing to detect any misbehavior. Even at a lower level, some operations over the platform have to be validated to avoid problems in the hosting environment (like memory leaks, drying resources, locks, etc).

From an academic and mainstream perspective, so far, the tendency has been to solve these issues by strengthening the runtime environment (like the Java Virtual Machine or the .NET Framework), and letting it handle dangerous operations instead of the languages, and also making the compilers smarter to detect as many problems as early as possible.

To enable this many languages (like Java and C#) followed the C++ path of strong typing. The focus of type safety helped to make compilers much better, but also helped with many other levels of checking, like static analysis, which allows to provide a higher level overview of a system and detecting more subtle things like compliance to specific practices or conventions.

Strong typing also helped providing better contextual information within IDEs, greatly improving features like Intellisense and refactoring tools, but until recently, it also added some verbosity.

While this mainstream approach captured most attention in the enterprise market, a grass roots movement with a noticeable mix of open source initiatives and communities pushed in a different direction: toward dynamically-typed languages.

This is indeed a complex terrain, as there is not a strict definition of what makes a language "dynamic". Some of their attributes, however, are things like runtime evaluation and dynamic creation of types and objects, and many times, dynamic typing, although this is not a requirement. Generally speaking, they are perceived as simpler to program and more functional in nature.

I personally feel very happy about all this renewed language explosion because I love this field, but I still see a greatest reward in static languages, coupled with some features that are usually perceived as "dynamic".

Type inference for example, arriving in C# 3.0, allows developers to avoid declaring variable types in many situations, by using the var keyword. This is handy and nice, but it is also great in the sense that strong typing is still there, because the type is inferred from the value been assigned.

Functional programming is making its way also in the form of lambda expressions support, but without the need of been checked at runtime. I really prefer lambda composability over runtime expression evaluation, as it provides a much safer experience and fastest feedback.

But dynamic languages (and the DLR) will provide a good complement to strongly-typed languages, like a good way to handle scenarios where late binding is a need, or contributing some interpreter environment for checking short snippets of code without the need to have projects, compilation, etc. This is great to quickly instantiate stuff and play around, then getting code into a program.

I guess that convergence is here, and the will be no real static vs. dynamic fight in the end, but a great leverage of all the languages strengths. This will boost productivity and safety at the same time, and I hope programming would be able to make a quantum leap as a discipline pretty soon.