Lambda the Ultimate

Since Oz/Mozart is (at core) a C++ program, I wonder if Adam/Eve could be leveraged to create an easier multi-platform support for the uI.

I was wondering when the world would get around to realizing the advantages of a mixed declarative/imperative approach to GUI design. It has been available as a full-featured tool in Mozart, QTk, since 2001. This tool is the work of Donatien Grolaux, a truly gifted developer, who was pushed into designing and writing QTk by me after I refused to learn the arcane and verbose logic of tcl/tk. See, e.g., the short paper presented at the EHCI 2001 conference, the paper presented at the DSVIS 2001 workshop, or chapter 10 of CTM. If you haven't played with the Prototyper tool presented in chapter 10, then you are missing out on a real Aha experience. (What's even more amazing is that the whole Prototyper is written in only 140 lines of code.)

I've got CTM here and have been reading through it off and on over the last few weeks (great work, by the way). I just looked at chapter 10 now in response to your post, so maybe this isn't the most thoughtful response you'll get.

I wonder if you could explain more about the particular features of Prototyper that you find useful. From what I can tell, the edge binding feature is identical to a similar feature in Borland's VCL. The tabular widget organization (lr/td) is interesting. I've made something similar in the user interface system of my little Scheme-like interpreter (UIs defined in my system can derive HTML or regular desktop window interfaces from the same widget layout definition).

One feature you describe here that I find really interesting is linking unbound variables to user interface fields.

One feature you describe here that I find really interesting is linking unbound variables to user interface fields.

What about using widgets together with dataflow streams? Is this at all useful or desirable?

What about using widgets together with dataflow streams? Is this at all useful or desirable?

Actually, it is! When a program interacts with a QTk-created specification, information flows in two directions: toward the GUI and toward the application. For the former, internally the GUI runs in a single thread and reads commands from a stream. This is important to keep the right order of graphics commands. For the latter, the GUI calls action procedures or sends messages to ports (QTk supports both), from within its single thread. (The P2PKit toolkit for building peer-to-peer applications that Kevin Glynn is working on now is based implicitly on message streams, BTW.)

I wonder if you could explain more about the particular features of Prototyper that you find useful.

I was referring to two things. First, the fact that you can interactively enter and edit a GUI specification and run it directly. This is because Mozart has a first-class Oz compiler (a normal situation for a dynamic language, BTW) and because QTk is an interpreter (it interprets a GUI specification and creates handler objects to fill in the holes in the specification). The second thing is how Prototyper is organized as a learning tool: with progressive lessons on GUI construction in the left pane, that come with explanations and live code examples in the other panes. It's such a simple structure, but it's very effective. It is enabled by the first-class Oz compiler and QTk interpreter.

Don't forget that HTML with CSS is a declarative GUI library. Combine that with Javascript and the DOM and you have a mixed declarative/imperative approach to GUI design. No wonder Googles interfaces are so good.

Yes, you're right. HTML with DOM is close to QTk in spirit (declarative specifications that can be interpreted at run-time, with embedded objects), but based on character strings instead of records. Character strings are really not the way to go for this kind of thing. They're flat so you have to parse them to get at their structure. Furthermore, it is hard to embed live language references inside them (you have to encode them). Full-featured records with syntactic and operational support on the other hand are almost ideal.

I wanted to say you can do all that in Javascript, but then you don't have the declarative part anymore. DHTML is not mixed declarative/imperative, but declarative only first and then imperative only.

But Mozilla now has E4X support (XML in Javascript), so that gives you the declarativeness back. But I haven't seen anyone use E4X with XHTML yet.

We tried using Dynamic HTML as a basis for a GUI toolkit (in the QHTML tool), but we ran into two practical problems: (1) nobody had implemented enough of the Dynamic HTML standard to be useful, and (2) the most complete implementation, in IE 5.5 I believe, was very slow. It was never intended to be used as a graphical toolkit (it suffered from the suffocating gerbils problem).

This was a few years ago, I don't know whether things have improved since then.

The trick is not to try to emulate the standard graphical toolkits, but to improve on them using the new web idioms. That way you get the performance, because you are using the browser what is was optimized for. Google does this very well imho with their mail and map apps.

Mozilla and IE both have enough implemented from the DOM, and have added enough on their own, to seriously build applications. But they are platforms, and like any platform it takes some time to learn the details.

Uhh, what's the suffocating gerbils problem?

I think the expression comes from the aerospace industry. A space rocket, like the Saturn V, is a complex piece of engineering with many layered subsystems, each of which is often pushed to the limits. Each subsystem depends on some others. Suppose that subsystem A depends on subsystem B. If A uses B in a way that was not intended by B's designers, even though formally B's specification is being followed by A, then we have a suffocating gerbils problem. The mental image is that B is implemented by a bunch of gerbils running to exhaustion in their hoops. A is pushing them to do too much. That's how I understand the suffocating gerbils problem.

I searched google, and turned up some experiments where the active ingredient of marijuana was used to partially prevent brain damage in suffocated gerbils. So I guessed it was a colloquialism for brain damaged.

--Shae Erisson - ScannedInAvian.com

Arcane and Verbose?

Well, it may not float your boat, but Tcl is pretty simple, really. It's like a cut down lisp with some things thrown in (expressions) that make it more palatable to people without a great deal of programming experience. It has been quite successful at that really. It certainly has some warts, but for what it was aimed at, it has done quite well.

Well, I didn't mean to criticize Tcl/tk specifically. Like you say, it does quite well for what it is designed for (building GUIs). My criticism is aimed at the general GUI approach where you have to build the GUI by invoking lots of commands. At the time we did QTk, Mozart had a very nice tk interface with an OO layer on top (the Tk module). But for building simple interfaces, the number of lines of code needed using QTk is 1/3 to 1/4 that of Tk, and they're simpler to write.

Web applications do seem like a good step in this direction of "a large number of ways to manipulate a small number of data structures". Using Firefox I can now consistently navigate webapps with isearch (just like Emacs) and control which pages to keep in tabs (buffers) ready for display, to name but two important examples. Contrast this with "rich" applications that make me do mental alphabetic-sort while pulling scrollbars and repeatedly clickety-click my way backwards and forwards to get where I want to go.

What good stuff is happening in the world of powerful user interfaces today?

P.S. I haven't used Photoshop and I'm not saying that it has a bad interface. The best example I have of a wonderful program with a hurtful user-interface is Ethereal.

Actually Sean's reply below makes it sound like there's more to constraint-based UIs than I realised. Perhaps I chose the wrong thread to unleash the "I don't like ethereal's UI" rant :-)

From the functionality this reminds me a little of Apple's Interface Builder. But QTk seems much more declarative (IB only works graphically, but helps a lot with layout), with obvious advantages for automatically generated windows.

BTW: is there a short summary/introduction to the Oz lightweight Thread implementation? Are they heap-allocated, cooperative threads without OS support, maybe continuation-based, like in most Scheme implementations?

Yes, I agree with you. It's depressing how long it takes for ideas to make it into the mainstream (20-30 years). I seriously think that most of the good ideas in CS existed already by the mid 1970s, and that what came after is just consolidation and maturation of the field.

I think that constraints have the potential to make it into the mainstream some day. The Adam tool is really a nice idea and we will try to find some time to give it the attention it deserves (it depends on whether one of my project proposals gets funded :-) ).