Subtext
April 18th, 2005
I came across Jonathan Edward’s Subtext programming language.
Alan Perlis once said “a programming language that doesn’t change the way you think about programming is not worth knowing”. It has been my learning filter selection since I started programming computers as a kid. Well, Subtext is not a programming language that you can use today to write your next blog with, but it made me think.
A lot.
Jonathan knows how hard it is to write documentation, so he gives us a demo. The demo is a presentation, it’s well worth the experience (view the demo of subtext).
There are three things that hit me:
- cut/paste as the most natural way to write a program, and the reason why it’s criminalized is that what is copied is the syntactic representation, not the actual semantical one, therefore, changes to the original do not propagate to the copy.
- with a reflective editing environment, the program cannot just be compiled and checked for consistency on the flight (as eclipse does, for example) but it can also be kept executed, this ‘programming by example’ makes it possible for you to understand what the program is doing while you are writing it! No more looking up the docs to find out if substring() included the char at the index or not, no more uses of debugging as semantic checkings.
- the program as a graph. Thruout the entire demo, I couldn’t stop thinking about the fact that this is, in fact, RDF editing, just with very specific semantics that are ‘interpretable’ (or, should I say self-inferencing?).
I always wondered what would make me jump to the next programming language… and I have the impression that eclipse and subtext paint a road that I really identify myself with: not only dynamism and interpretation but interactivity, the blurring of the editing/execution separation.
Now I’ll just sit here waiting for some lisp dude to tell me that lisp could do that in the middle ages.