My little screencast has now gotten over ten thousand hits. Amazing. It seems there is a large pent-up desire for a better way to program. I have gotten lots of positive feedback, much of it endorsing not so much the particulars of Subtext as that I am making an attempt to improve things. Thanks to everyone.
I have also triggered some fairly negative reactions. I take this response also as a positive sign, that my work is threatening enough to warrant a backlash. I have written an FAQ to answer some of the recurrent criticisms.
This might be a good time for a progress update on Subtext. I have decided to change direction somewhat. I was previously working on “getting factorial right” with new representations for conditionals, iteration, and higher-order functions, as described in the Future Work section of my OOPSLA submission. I now think I should shelve that and instead face the issue of I/O and mutable state. This nasty problem has been the bane of much programming language research, particularly leaving functional languages tied up in knots. It could be the critical issue that makes or breaks Subtext. My new goal is to show how to build a GUI in Subtext, and to do so while maintaining the principles of WYSIWYG and the unification of edit-time with run-time, just as with factorial. I haven’t figured out all the details yet, but if I can pull it off it would make an eye-opening demo, and also make Subtext dramatically more realistic and relevant.
Have you decided yet whether a description of a UI will be declarative (e.g., XUL) or imperative (SWT, Swing, etc.)? Something tells me that a declarative description would fit subtext better, but this feeling is based mostly on the tree-like data structure in subtext so I may be off the mark. A description of a UI would require a set of semantic rules for interpreting it and displaying it. Would these interpretive rules be built into a subtext “virtual machine” just like arithmetic is?
Bravo! Factorial has the advantage that everyone understands it and knows when it’s working. However, virtually every language ever invented does a passable job of factorial: it’s a solved problem and no solution looks compelling over the others. User interface code is a great example of where traditional languages look terrible: make that look good and you have a case for change.
Good work so far.
I wonder what’s the underlying semantic of a file interface?
The semantics of UI is pretty clear – it’s a visual representation of shapes and text boxes. Flash developers are more productive in Flash than a programming language because the IDE allows thems to manipulate the underlying objects directly, rather than struggling through a disconnect by having a text-based language intervening between a person’s idea and the computer’s representation.
But what about files? There is the idea of a stream, but that’s too low level for most people.
Libraries such as ConfigParser, pickle or XMLReader already provide a semantic interface to file formats.
What level of abstraction do you have in mind?
[In the case of XML, the obvious thing to do would be to directly represent the DOM. However DOM’s are not the most user-friendly rep, so maybe there is a better way. XML is a particularly tough case, because it is such a design disaster: a data structure designed to be human-readable that ends up being unreadable by either humans or computers. – Jonathan]
Thanks for the comments.
Peter asks about declarative vs. imperative. That is the heart of the matter. I am trying to make them one and the same. Chui’s comment about Flash is apropos: Flash provides a timeline in which you can schedule events. A timeline combines some elements of declarative and imperative descriptions. I want to generalize on that.
There is one aspect of imperative descriptions that will not be present in Subtext: the notion of a “program counter”. Even timelines have a “play head” that moves to animate behavior. I want something more like a comic strip that show the history of states, with captions describing the actions.
Interestingly enough, Chapter 10 of the book “Concepts, Techniques and Models of Computer Programming” by Van Roy and Haridi is about GUI programming. The authors discuss the pros and cons of procedural vs declarative GUI construction. They decide that both methods should be used. The structure of a UI is described declaratively (like HTML or XUL) and pieces of code are hung off of appropriate places in this structure. For example, code is needed to handle user interaction. Because building langaugaes is a primary theme in the book, they simply combine two aspects of a language for the purpose of building UIs. It sounds like a LISP solution (Data & Code are the same) but their language is more restrictive.
To me, this doesn’t seem much different than the current structure of subtext. That is, I can create an arbitrary tree structure and I can place a function anywhere it is needed, within that structure. The functions are builtin and would be at higher level than, say, arithmetic and would be capable of working with GUI components in the structure.
As far as states are concerned, I would suggest that each reduction of the subtext program’s AST (*not* its visual representation) represents a “frame”. Clicking frame by frame through the execution of the program, one could observe the behavior of that program. One could imagine going backwards as well. Maybe programs could be written starting with a copy of another program’s “script” as a base.
Peter,
The Mozart UI style is common, and goes at least as far back as Tk. It is also related to Visual Basic, which provides a “design-time” UI to a (hidden) language of GUI construction. I am planning something similar, with 2 differences. The first differences is that the “declarative” part will actually be the same thing as the run-time object model of the GUI – windows and frames and controls, etc. Self does that already, though Subtext’s natural containment hierarchy makes it a little more literal.
The other, and larger, difference is in the representation of the action functions attached to the GUI controls. That will be the key. I am still working on it.
In the context of GUI programming I find finite state machines very useful as well as robert martin’s (uncle bob’s) task based architecture on objectmentor.com website. Maybe you could orientate the whole GUI dev around the notion of tasks not just actions. Also, tasks don’t have to be singular. I have three tasks put into a supertask that allows the user to select/zoom/pan the views from the mouse alone (ie. no toolbar buttons need to be pushed for each task). This is driven by internal FSM that contains the logic of the three tasks. This mouse handling can also change at my whims thus it needs to be modifiable easily. That task master architecture allows me to add in another task with possible subtasks easily and I can then switch between my different mouse handling logics. We are in dire needs for a better GUI building tool instead of the tedious MFC api. I think C#/.net is a bit easier w.r.t. message handling and placing controls on the form but I don’t know for sure since I haven’t used it. Basically, I think that the ease of removal of features is just as important as the addition of them. When I looked at the Quake code I noticed how difficult it will be to remove something and/or modify it. So program structure is important or “programming in the large”. Ok, just wanted to express some ideas and let you know how I do things in real world 🙂
So how’s it going?
I’m familiar with a couple of approaches to this problem. There’s the monad approach, where you thread the outside world through your program as a sequence of values; there’s the functional reactive programming approach, where you write your program as functions taking time-varying signals as input and producing time-varying signals as output; there’s the “make” or lazy evaluation or dataflow approach, where your functional constraints change their outputs whenever their inputs change; there’s domain/object’s approach, which I don’t think I understand yet; there’s the composable transactional memory approach; and there’s the applicative-order approach used by e.g. Lisp and ML, which I think I showed how to apply to Subtext in http://lists.canonical.org/pipermail/kragen-tol/2002-May/000713.html — which ones of these have you tried at this point?
I still haven’t decided whether to come to OOPSLA. It’s awfully tempting, since this stuff is crucial to the future of computation, and it’s all appearing *now*.
Hi Kragen,
I am sitting in the Ahwahnee in Yosemite, on vacation, so let me just fire off a quick response. [BTW, the wifi login here is james/123456].
I am excited about how this is coming together. Mutable state may actually be quite simple if you don’t get hung up on having an efficient compilation into a machine model of writeable memory. I added a “teaser” at the end of the final version of my OOPSLA paper, at http://subtextual.org/OOPSLA05.pdf
My main goal in life once I get home will be to implement this in time to demo at OOPSLA. I don’t think missing OOPSLA will leave you behind, but it would be great to see you there anyway.
Later,
Jonathan