Tuesday, May 1, 2007

MIX07 Update: Evolution of Declarative Programming in .NET

One of the key messages from the MIX 2007 conference is the evolution of the .NET framework to support a much more declarative programming style.

Anders Hejlsberg made the claim that the potential productivity improvements from imperative programming are limited - we've essentially already invented all the major programming constructs and he doesn't see much more productivity improvements - we're not going to invent the equivalent of a new type of FOR LOOP - we've got them all.

Declarative programming paradigms have some significant room to improve developer productivity by simply changing the game - instead of making developers focus on statements that construct the logic on how something gets done, declarative programming frameworks can allow programmers to focus on focusing on domain level concerns.

An example of this is LINQ - instead of writing a data access layer for every table, with LINQ you can simply write declarative SQL like syntax. The data access layer is automatically generated for you. In addition, the power you get in the LINQ for declarative SQL like logic means that you can do all sorts of database operations in code that would have taken tonnes of imperative style coding previously:

var wordGroups =
from w in words
group w by w[0] into g
select new { FirstLetter = g.Key, Words = g };


Just imagine the amount of plumbing code you would need to do this in today's .NET or Java frameworks - this is the power of declarative programming styles.

The same is true on the interface side - the power of languages such as HTML, CSS, PHP, Python, etc. are declarative languages that allow the user to use a declarative programming style instead of an imperative set of instructions.

In HTML, the imperative version would be what we used to do with old CGI or classic ASP applications to generate HTML programmatically. It would look something like this:


Response.Write("<html>")
Response.Write("<body>")
' build a table with n rows and m cols
Response.Write("<table>")
for i = 1 to n
Response.Write("<tr>")
for j = 1 to m
Response.Write("<td>")
Response.Write("</td>")
next j
Response.Write("</tr>")
next i
Response.Write("</table>")
etc.

This type of programmatic approach to HTML generation has almost entirely disappeared as declarative programming styles have now allowed interface developers to simply write HTML directly.

Expect more of this declarative style in deeper layers of the architecture and for the syntax of the declarative constructs to support more complicated and domain driven programming patterns. This will hopefully have an impact on the amount of plumbing code required for core business logic domain problems such as O/R mapping, value object design, web services coding, security/user/authentication problems, profile mapping, configuration management, etc.

In addition, one of the key frustrations with declarative programming for me has always been the sacrificing of strong types, IDE integration, compile time checking, object oriented principles (try doing inheritance or encapsulation with HTML!), etc. But with technologies such as LINQ we may be at the stage where we don't have to make such a sacrifice and integration of declarative and imperative programming styles can happen in the same environment allowing for both styles to work where appropriate.

1 comment:

Anonymous said...

You may like to take a look at F#. It is quite amazing integration of declarative-functional style with OO style of developing based on a OO framework (.NET).