Last updated on Friday, February 9, 2007
I just finished reading “Subtext: Uncovering the Simplicity of Programming”. As I read, my mind kept going back and forth between this makes a lot of sense and this is crazy. This is common with radical new ideas. A few years back I read about Intentional Programming (It was the paper from 1995) another radical idea that I thought had some good points. Every now and then I will peek at Intentional Software to see if anything has materialized. There is always news but as of Jan-2007 there is nothing to get your hands on. Both subtext and Intentional Programming are looking to change the way we program and both jettison text as source but beyond that they are very different. The biggest practical difference is that subtext has a working prototype that you can get your hands on and is open source. This will make all the difference. I predict that if either of them makes it big it will be subtext.
Before I give some opinions based on what I have read so far I just want to say that I think subtext is interesting and important research and I’m looking forward to seeing where it goes.
I tend to agree that programming doesn’t need to be so hard (or shouldn’t be so hard). I have spent many spare cycles thinking about this, I just never thought of text as being the problem. Text is easy to type in or write on the back of a napkin. XML is very successful in no small part because it is a text format. Text is robust. There are many tools for processing it yet the text will out live the tool that created it. I could take a text file containing an algorithm written in Fortran and without a Fortran compiler or the editor that created the file read it and translate the algorithm to Java. How would you write down a subtext algorithm on a whiteboard?
I donâ€™t think of the syntax needed in a text representation as a problem either. People are good at syntax. We quickly turn sentences in natural language or a programming language into a mental model. It seems likely to me that in our mind sentences are parsed into some kind of tree structure but when we look at the resulting tree in say an X-bar diagram it is confusing and unnatural. It is as if the structure is so deep in our brain that we donâ€™t have access to it. As a programmer I get trees but they have their own problems. Large trees are hard to navigate. When your tree is really a view into an underlying graph it gets even harder. Sometimes it makes sense to add a little syntax and serialize the tree. It seems Subtext supports this with its nesting presentation.
Subtext suggests that it is WYSIWYG programming. It draws a comparison with WYSIWYG word processors. The comparison doesn’t seem quite right to me. When used in the context of word processing there is an unspoken completion to the term WYSIWYG, which is “when you print or display the document”. When applied to programming the ending would be “when you run the program”. But most programs don’t want to look like the subtext UI when they run. This may be too picky a point. Even word processing documents these days contain data that isn’t printed, annotations for example. The static description (imperative or declarative) for a dynamic process is going to look very different from the thing it creates.
A big thing I find missing is a tutorial. If subtext is truly a better way to program then there should be a short tutorial where subtext’s beauty and benefits are immediately clear. I should get a feeling of awakening like I did after reading the RELAX NG tutorial or the Little Lisper. What would a subtext tutorial look like? How would the visual copying be represented in a text description? Perhaps I’m stuck in old ways of thinking. Perhaps the tutorial would be interactive and part of the tool.
Which brings me to my biggest concern. Is subtext a language, a tool or both? I don’t think it claims to be a language. But it is for programming. I have trouble getting my head around this because languages are what I have always used to program. I think there is value in being able to describe the language independent of the tool. This allows multiple independent implementations that are [more or less] compatible. Perhaps the language will show through when the formal theory of copying is developed. Special purpose tools do have a place. It is true you can program in Excel but your programs are tied to Excel as a platform. Software developers want something more general and will fear a tool that locks them in.
A final thought. Applying usability to language design isn’t a bad idea but usability is all about testing. Subtext will need usability testing beyond just testing the tool’s UI