Wednesday, July 14, 2004
I found this interview with Charles Simonyi today. Simonyi, formerly at Microsoft, talks about Intentional Programming, something he has worked on for over a decade, since his days at Microsoft. Intentional Programming, says Simonyi, aims to move beyond conventional text-based programming languages using a system based on an abstract tree structure stored in a database. The idea is that you separate the "intention" of a program, from its expression as a text-based representation. An "intention" is an abstract conception of what the programmer intends for the program to do and can be either low level or high level. As near as I can tell, the best way to think about an intention is something akin to an abstract function, stripped of any particular programming language representation or algorithm. The idea is that many different representations (what Simonyi calls "projections") can be created for the abstract intentions. You could express them as a conventional programming language, or something more compact like a domain-specific programming language. For instance, given a database of intentions interconnected to represent a program, an editor could represent the program in something akin to C or Java. Further, code generations can pick different algorithms for the same intention based on where in the tree structure the intention sits. For instance, an intention might pick an algorithm based on parameter types.
This video describing Microsoft's intentional programming prototype called IP may help you understand the concepts a bit better.
It's interesting to note that intentional programming serves up essentially the same value proposition as described in my previous blog entry about Dr. Gregory V. Wilson's notion of an extensible programming language. My guess is that Wilson is grabbing ideas from intentional programming.
Now, these general ideas strike me as being very interesting, particularly in view of the capabilities of Lisp. I went through a bit of Wilson's stuff last time, so let's spend a bit of time examining Simonyi's Intentional Programming, using the Microsoft video as a bit of a guide for what he's up to at his new company.
- Firstly, Simonyi wants to move beyond text notation of a program to a tree structure representing the computations required for an algorithm. What's interesting is that Lisp has essentially done that. More than any other programming language, Lisp basically exposes the parse tree of the underlying algorithm. The main difference between Lisp and IP is that Lisp uses a text-based representation (sexprs) rather than a versioned database.
- A key point about intentional programming is that it allows the user to change the way a problem is represented. If a domain-specific language is more helpful for a program expression, the user is encouraged to use that, rather than a conventional notation. Since the tree-structured database is the master information repository and languages are simply notational conveniences for the sake of the programmer, there is no issue in changing representations when it is convenient. In the Lisp world, this is encouraged, too. As I have said quite a few times in this blog, Lisp nailed the macro system, and how! One of the things that most excites me about Lisp is the opportunity to create domain-specific languages when required. The difference is that with intentional programming, the database tree is the master and everything else is a projection. There can be multiple equivalent projections/representations of the same intentions. In the Lisp case, the source text is a master, with any DSL being transformed into the parse tree of sexprs using macros.
- At one point during the IP video, they talk about having bits of code that can walk the IP database tree and perform various transformations and optimizations, such as looking for redundant pieces of code that can be extracted into common functions. They call these transformation functions "enzymes" (horrible name, IMHO). Of course, Lisp has had code walkers for quite some time, and the same types of functionality could be written fairly easily for Lisp.
- The code generation scheme seems to be the biggest difference between the two systems. In the IP video, they make it sound as if code generation is very flexible and essentially pluggable. Programmers can create new types of intentions and add them to the system. Part of the definition of an intention is an expression for how to transform that intention into code. In the case of Lisp, this is typically a more conventional system, with a compiler performing basic transformations and emitting code for primitives. One could easily conceive of a metaobject protocol for compilers, however, that would mirror what IP has done. Indeed, it looks like Kiczales and crew at Xerox PARC did some work in that area some time ago.
- One thing that intentional programming seems to make very easy is refactoring. Most of what we think of as refactoring in a language like Java simply becomes transformations on the tree representation, easily handled as such, rather than the parsing task that it is today with languages like Java. If you think about most of the really good refactoring tools like Eclipse or IDEA, they operate by fully parsing the source code and then operating on a parse tree representation stored in the background. Interestingly, I don't hear the word "refactoring" a lot in Lisp circles. Why?
So, it seems to me that intentional programming is a pretty interesting field of study. Certainly, we need to find a way to express problems at higher levels of abstraction in order to combat the explosive complexity that accompanies big problems. Moving beyond simple imperative programming style and using DSLs heavily seems like a good idea. The ideas associated with intentional programming seem like they're on the right track, if for no other reason than Lisp has already partially validated at least some of them. So, a few questions...
- Is intentional programming really that different than just programming in Lisp to begin with?
- Is the total abstraction of computation into text-less "intentions" with text-based projections the right way to go, or does simply moving to sexprs do the job?
- Is the database really buying you anything from a computation/algorithm/expression standpoint, or is it just source code control in another form?
- How close to an amazing intentional programming system could you get by creating a great IDE in Lisp? Of the various Lisp programming environments, the best ones I have heard about seemed to run on the Lisp Machines, but I don't know that they had the same characteristics as an intentional programming system like IP. All I know about Lisp machines has been gleaned by watching some of the screen-cam videos floating around the net; I have never worked on one directly and don't know enough about the programming environment capabilities.
In short, intentional programming has a lot of neat ideas. The question is whether they are sufficiently different than stuff already done in Lisp to warrant that "wizzy, cool" factor associated with "new technology," or are they just Lisp, recycled yet again into the mainstream with a better marketing campaign?
In addition to "source code control in another form", I thought of the following benefits:
+ Pattern Matching: It should be possible to define patterns against which the code is constantly checked. Actions could be taken if a match occurs. This could be used to enforce coding standards, and to allow tests against patterns of common coding mistakes to be written (a la Scott Myers). Actions taken upon a match: to report the match to the programmer, to automatically apply a predefined transformation on the code, etc. This could help ensure that programmers comment their code, for example.
+ Distributed compilation: IP suggests a client-server architecture. It should be trivial for the server to farm out compilation tasks to the clients, collecting and assembling the resulting binary or bytecode. Compilation could be performed continuously and incrementally, so there should be no reason to wait a long time for a build to complete.
+ Automated conflict warnings in team environments: Again, because of the client/server architecture, it should be possible to detect that two or more developers are making changes that will cause some kind of conflict (e.g. they are both editing the same piece of code). As soon as this is detected, the system could warn the programmers, and possibly connect them via a chat program or A/V link to help them resolve the problem.
In think that, in general, an IP-style programming environment could help the human side of the software engineering process. Capturing intentions directly, rather than indirectly through text, makes so much possible.
This is very interesting to me, especially because I've done similar work myself! But your video link is 404. :-(
Anybody have an alternate source?
Post a Comment
Links to this post: