I'm Mark Edel, one of the developers at Intentional Software Corp. Unfortunately, I'm no match for Charles' eloquence on the subject of Intentional Software. What I am offering, here, are some random bits of personal perspective.
Some readers may be familiar with my work as the author of NEdit. However, the software I'm most proud of having written, is something I did 20 years ago in graduate school, a visual programming environment called "Tinkertoy". In Tinkertoy, I used draggable, snappable icons for program and data representation. My goal was to be able to do graphical interaction while retaining the representational compactness of textual programming. Editing with icons turned out to be quite natural. You could perform very complex edits quickly and accurately by snapping and unsnapping program parts.
One of the most compelling aspects of Tinkertoy, and one I understood only after I had built and used it, was its ability to combine execution of code fragments with viewing and manipulating data. In a desktop window, you could place code and data at will: large or small program structures, individual functions, lists, trees, arrays, etc. Because you could juggle a combination of code fragments and hundreds of results at once, you could use completed and uncompleted code together, performing computations by hand, manually manipulating data structures, feeding results from one fragment to others. You could also build ad-hoc user interfaces by plopping down an appropriate set of functions in a window. It was an environment in which you could explore programming ideas very quickly. Having experienced this 20 years ago, I am dumbfounded that we are still programming in text-based languages.
I've been at Intentional a little over a year, now. The thing I remember being most surprised and confused by when I started, was the idea of using of transformations for display. I had expected transformations to be used to generate code, and that we (and our users) would just write code with graphics library calls to generate the various views of the code and data we wanted to display. It wasn't until I put it together in my head with something I had stumbled on years before, that I understood how powerful an idea it really was. One of the things people like most about NEdit, is that it provides high quality syntax highlighting for over a hundred different computer languages. I didn't write parsers for 100 languages, I personally wrote just two. Users wrote and contributed all the rest. What I did write, was code to support a hierarchical regular-expression matching framework. The framework carefully constrains what would be a very computationally intensive matching process to what needs to be parsed for displaying exactly what the user is viewing. To the highlight-pattern writer, it feels like free matching, as if they are combining hundreds of expressions, each theoretically examining thousands of lines of code, and applying it effortlessly to their 10,000 line file on each keystroke. The highlight patterns have proved flexible enough to handle all kinds of strange language constructs, thoroughly, and with good error tolerance. More importantly, they are easy enough to use that people are willing to make the effort.
Intentional display transformations work on the same general principle, but with a much broader scope. The system provides the underlying support to make writing transformations easy, and like NEdit, focuses the computation on just the data necessary for what the user is looking at. This allows the transformation writer to concentrate on transformation, and code it in the most straightforward manner, using the highest level techniques available, without worries of efficiency. Syntax highlighting is just a tiny subset of capabilities of display transformations in the intentional editor, which can freely restructure what it is presenting, and endlessly combine a whole range of graphical and non-graphical display targets. In a sense, the very best feature of NEdit is a tiny footnote for the intentional editor.
This brings me to a second and equally important lesson from my experience with syntax highlighting in NEdit. Syntax highlighting was a huge success in stark contrast to a very similar interface for smart indent. In seven years, only three smart indent packages beyond the two I originally wrote have been contributed, compared to over a hundred actively maintained highlight patterns. The main difference between the two interfaces is that highlight patterns are in a domain-specific language based on simple regular expressions, while smart indent has to be programmed in the NEdit macro language. If this is any indication, there is vast untapped potential for non-programmer participation in programming tasks, when the interface is right.
Software developers are naturally skeptical of radical new development methodologies. We've heard plenty of promises to triple, quadruple, or (usually) 10x our productivity. To illustrate how little we've actually advanced, last year I remember being amused by the results of a yearly programming competition that gives competitors free choice of language and development environment. Several of the winning entries were coded in C.
What makes me think that Intentional Software can change this, is that it attacks what I consider to be the core issue. I've always thought of software writing as a battle against complexity. To me, tools and methodologies are useful mostly to the extent that they either shed light on, or reduce, this complexity. By this metric, switching from C to C++, for example, is not necessarily as effective as using a better GUI library. In computer science, abstractions are our building materials, and as Charles has pointed out, languages are a terrible vehicle for them. With a new language, you basically get only one shot at a few new abstractions at the birth of the language, and then, for the most part it's sealed forever. Intentional Software is a method for improving the abstraction process itself.
We've seen bits and pieces of this kind of technology before, but nobody has stepped back and taken the long view of the whole thing. A lot of what we are doing can be accomplished by other means, using lots of parsers and unparsers, display programs, and software tools. I can see that we're on the right track because I see convergence. We are joining functionality which most people would say is inherently complicated and incompatible, and it's coming out as a unified whole that I think users will view as astonishingly simple and powerful.
Comments