Steve Yegge: "Now we all see this happening in clients. Excel, for instance, is scriptable. And the reason that Excel is so powerful, I mean the reason that you can go to the bookstore and get a book that's this thick on Excel, and scientific computing people use it, whatever, is that it has a very very powerful scripting engine.

In fact, all of Microsoft Office has it. Right? You can fire up Ruby or Python or Perl, and you can actually control, though the COM interface, you can actually tell IE to open a document and scroll to a certain point in it. Or you can open up Microsoft Word and actually... I mean, if you want to do the work, you could actually get to where you're typing into your Perl console and it's showing up over in Word.

Server-side computing has to get there. It's gonna get there.

But how many server-side apps are user scriptable today? Precious few. Google has a couple, you know, like our JotSpot acquisition, which is [scriptable] in Rhino...

So we're talking about something that's kind of new. I mean, we can all see it coming! But it's still kind of new, the idea, right? Why?"

When I read this, the first thing I thought was... Zope. Not JavaScript on the server/jvm which is what the rest of Steve's post is about. Zope.

Zope has had this kind of scripting for nearly a decade - Python, and through the web if you want it. Zope's had an OODB since forever - you can do stuff like changing cardinality without migrations. Every Zope object can respond to HTTP methods - HTTP is built into the interface. Zope supports arbitrary/semi-structured metadata - can't settle on a geotagging scheme? - support as many as you need. It has a repl that works over gnureadline/ipython - go ahead, shell into the running server, poke around, enjoy the fact you can transiently manipulate the object state on your instance of the data. Zope has components with full dependency management and lifecycle support - these are called products. This is a Zope product. This is another.

Yes, I know we don't like Zope - modern fullstack frameworks are better, OSGi based microkernels are better, plugins are better. Continuations are better. Zope's a dinosaur, it's too complicated, it's labyrinthine, it's deeply unfashionable.

We might not want to use Zope, but we do want to learn from it. Want to know the downsides and issues around using an OODB? Bidirectional RPC/Object Caching? Incremental backup policies. Component lifecycles and transitive dependencies? Hot reloading? OO based URL dispatching? Properties and Folder/Collection Acquisition? Supporting arbitrary metadata? Document Translation/i18n? Not running on an RDBMS? Open classes? Multisite publishing? Through the web scripting? Look at Zope. Zope is the Lisp of the Web.

Anyway, there's a good book on the most recent Zope, that gets into the meat of what it can do. Enjoy.