I've been monitoring with great interest the reactions to yesterday's item, to its related InfoWorld column, and to Jonathan Edwards' screencast and paper that I cite in both. I was particularly curious to see what Smalltalk and Lisp folks -- who have in certain important respects been there and done that -- would have to say. James Robertson was merely dismissive in this post. Preston Bannister offers more nuanced reflections:
The example and the accompanying narrative is somewhat interesting. Oddly enough it is not the tree-structure-editor aspect that I find compelling. Rather it is the use of sample values, live computation, and highlighting of "dead" (not executed) code. [Structure editors, IDEs, and another Lisp flashback]
Agreed. That's the part of the demo that makes Edwards' notion of example-driven programming come to life. Bannister goes on to say:
One of the strong, subtle advantages in the Lisp environment was in having the parser and pretty printer as simply another set of functions in the library. In the C/C++ world the compiler is a large monlithic seperate program, and offers only a one-way path from source text to compiled code. You cannot reuse parser or gain access to the parse tree. In the Java world the compiler is once again part of the environment (with only slightly awkward access). This is one prime reason Java IDEs can support refactoring, and "deep" operations on your Java programs.Yes. That's why I wondered in my column whether emacs will ever be pried from my cold dead fingers. Mark Levison, who has been thinking about these issues recently, has some suggestions:
In my opinion at least, the notion of tree-structure editing is still only of limited value, and not a replacement for simple text editing. Back in college, after we had all played with structure editors for a time, one member of our group identified the source of our discomfort by noting that many simple common operations in a text editor were much more complicated in a structure editor. [Structure editors, IDEs, and another Lisp flashback]
In the .NET world there is CodeDOM -- though I gather it's more for creating than for analyzing and rearranging structure. For Java I found the AST View plugin for Eclipse which, once installed, reveals the abstract syntax tree and connects tree navigation to text navigation. I suspect that we have many of the raw ingredients we need to move forward. What's missing is a coherent UI metaphor that combines the benefits of structure editing and text editing.[Mark Levison: Programs still edited as text"]
- IDE's need to better tools to manipulate their Abstract Syntax Trees
- The Abstract Syntax Trees need to be documented and made accessible to external vendors
Maybe that's an unattainable goal. But I hope people will keep trying to achieve it nonetheless. It would be great if those who have been there and done that could not merely describe the pitfalls, but also show them to us. Why not take a cue from Edwards and use the screencast medium to do that?
Former URL: http://weblog.infoworld.com/udell/2005/01/20.html#a1155