Back in January, I challenged the Seaside community to implement a dynamic FTP server. The idea isn't to get Squeak to serve out the filesystem, but to have a way to use the FTP protocol as an interface to any data you want, in the same way that dynamic web servers let you use HTTP for applications far beyond serving static HTML files. Well, Ian Prince wrote a couple of weeks ago that he and Lukas Renggli had started to tackle it at Camp Smalltalk in Brussels. Since then, Lukas has been hacking away, and he just let me know that he had support for passive clients done - which means that, among others, the Mac OS X Finder now works. So here's a shot of a Finder window browsing the class hierarchy of my Squeak image:

Each method is represented as a separate text file, and if you edit and save one, it'll be immediately recompiled and the image updated. Ever wanted to use emacs to edit your Squeak code? Here's your chance.

But browsing Smalltalk method source is just the beginning. Any number of databases and domain models could be usefully exposed as a hierarchical file system. Lukas says he's already working on an FTP view for SmallWiki2, turning BBEdit into a dedicated wiki editor. What other web apps could benefit from an FTP dimension?

Very cool stuff.

Can you call it arrogance if it's true? Either way, I can't resist repeating it. Paul Graham on how hard it is to design a new Lisp:

The advantage [the inventors of Perl, Python, and Ruby] had over us in the Lisp world was that they started from a lower point. Larry Wall, for example, started out trying to make a better awk. That's not hard. Awk is missing a lot. Whereas we in the Lisp world are bumping up against the asymptote. Among other things, we can't avail ourselves of the one of the richest sources of features for new languages: taking stuff from Lisp. We have to invent genuinely new things.

On a more serious note, I'm not sure why "the Lisp world" (to use Paul's sweeping generalization) spends so much time on language implementations. The great thing about languages like Lisp, Scheme and Smalltalk - which, I would agree, are all pretty asymptotic, but on local maxima not the global one - ought to be that the language problem is solved, and you can spend all that energy inventing genuinely new libraries instead. That way, all that genuine newness gets to interoperate, rather than compete.

Well, just a thought.

I'll be speaking in London on Tuesday, July 19th at the eXtreme Tuesday Club's weekly meeting. I'll be coming in early on the 19th and leaving fairly late on the 20th, so if someone's interested in a pint or something on one of those days, drop me a line.

I'll be speaking on April 25th at the Vrije Universiteit in Brussels. Here's the abstract of my talk:

On the web, abstraction is a dirty word. The dominant paradigms and philosophies of web development -- CGI, Servlets, Server Pages, REST-- provide only a thin wrapper around the low-level details of HTTP, and encourage you to use the rough stones of the transport protocol as the direct building blocks of your application. Web developers by and large reject any further abstraction in the way that assembly hackers once rejected structured programming: it's too inflexible, uses too many resources, and above all, it doesn't let you see what's *really* going on. As a result, web applications suffer the same problems now that assembly language programs did years ago; they're fragile, verbose, difficult to maintain and ill-suited to reuse.

That's not to say that better abstractions aren't available. The Lisp and Scheme communities have been working on them for years. Paul Graham's ViaWeb pioneered the use of closures, not query parameters, to capture application state in each link. Christian Quiennec showed how to use first class continuations to invert the flow of control of HTTP and put the server back in the driver's seat. Macro packages like htmlgen bring HTML into the language itself, opening up much more than a template system can provide. Meanwhile, object-oriented packages like WebObjects have demonstrated how to decompose the web page into a tree of stateful, interacting objects, allowing a finer granularity of development.

Seaside combines these ideas and others with the rich development environment of Smalltalk to provide a stable, complete, and innovative web application platform. This talk will introduce Seaside, and will focus in particular on the ways in which these abstractions can be leveraged to enable reuse: how to use closures, continuations, and intelligent HTML generation to destroy the intra- and inter-page coupling that is holding web development back.

One of the projects I'm working on right now involves five developers in three countries. Lukas Renggli recently sent me a PDF with an ancestry graph of all of the versions in our Monticello repository. Here's an excerpt:

Thanks to John Pierce for the GraphViz library for Squeak.

The inimitable David Heinemeier Hansson points out that in a recent set of slides by Sam Ruby, Rails is the fourth item from the top on a list of things Worth Watching. What's item number three? Continuations.

Sam also brings us Continuations for Curmudgeons, an explanation of call/cc from the point of view of a C programmer. I've also often found that explaining continuations in terms of the possible machine (or virtual machine) implementation often gets the point across much easier than trying to explain the semantics. How do you capture a continuation? You save a copy of the current execution stack. How do you invoke it? You blow away the current stack and replace it with a fresh copy of the one you saved. How many times can you do this? As many as you like.

Just don't explain it that way around Scheme folk...

Darren Hobbs writes:

Today I saw something in Seaside that gave me one of those 'Dude, that so totally rocks' moments.

There's an innocent toolbar option in Seaside called 'Toggle Halos' that switches on a visual representation of the components on a page, with some icons for each one. One of the icons looks like a spanner (US: wrench), and when clicked on, shows you the code for the component in your browser, and lets you edit it!

Oh yes. Welcome to really rapid application development.

Apart from the occasional quick fix to a live site, I don't tend to use that feature much for development, but what I use it for all the time is for getting my bearings in a complex codebase. When you're deep inside an application that someone else (like, say, yourself two years ago) wrote, there's nothing quite like being able to point at the screen and say "ok, now show me the code that renders that bit of the page".

(And in case anyone's wondering what halos look like, Ian Prince has a great reflexive screenshot here).

Update: Ian just posted a more detailed look at halos here

I occasionally get the impression that people view continuation-based web frameworks as more of an academic exercise than a production tool. Certainly, I'm no academic. I have the common hacker's failing of being much more interested in finding out what my code will do next than writing about what it does now. But neither is Seaside an academic framework. A few of the commercial uses I'm aware of are:

• Driving the workflow system for a bank
• Building offers and managing admissions for an insurance broker
• Managing CV information for researchers
• Running the boxoffice of some theatres
• Driving the shopping cart of an online merchant
• Managing images for a printing shop

• Universität Bern (slides from Alexandre Bergel)
• Ecole d'Ingenieurs de Mines de Douai (course materials from Noury Bouraqadi)
• Università della Svizzera italiana (slides from Romain Robbes)
• San Diego State University (course materials from Roger Whitney)
• New Mexico Highlands University as part of their Software Development Apprenticeship Program