Saturday, January 13, 2007


So there's a kickass object-modelling system in Smalltalk called Magritte. Magritte is basically like, imagine if you had ActiveRecord, minus the database part; and imagine further that it could change its shape aribtrarily and at will. From the main Magritte page:

Most applications consist of a big number of model- or so called domain-objects. Building different views, editors, and reports; querying, validating and storing those objects is very repetitive and error-prone, if an object changes its shape frequently.

The goal here, basically, is to be totally prepared if you run into a situation where you do know that you're going to need to do all kinds of things with a certain piece of data, but you don't know what form that data will have in the future. The perfect example of this kind of thing is Dabble, where you can record a date as a string, and then decide at some arbitrary future time that all these strings are in fact dates, and you need them mapped onto a calendar.

There's a great podcast where Avi Bryant describes the problem Dabble is designed to solve. It's a very, very common problem: spreadsheet abuse. DSL experts will tell you that the domain-specific language in Excel is actually the most popular programming language in the world. It's not actually because Excel is so good; it's also because it's an easy tool to use to represent a very wide range of data. One of the first Rails projects I worked on involved turning a de facto work orders system that consisted entirely of a manually-updated Excel spreadsheet into a nice Ajax-y Rails app which put almost exactly the same business process into a new context (the Web) and format (HTML). The idea behind Dabble is, you've got all this data people like to put into spreadsheets, because spreadsheets make sense visually, and yet these spreadsheet-driven systems inevitably get very ugly, because spreadsheets are the wrong technology for this kind of solution, so, let's give these people a spreadsheet with the ability to turn itself into a database further down the line, when the time comes, as it inevitably will.

Now the obvious thing, when you see Magritte, is to wonder about the database side. If it's ActiveRecord minus the database, that's kind of weird, because it's almost like the whole point of ActiveRecord is the database. Ramon Leon is working on an ActiveRecord for Smalltalk, which is basically Magritte meets Glorp, but the interesting thing here is, besides Dabble itself, when I first discovered this, I thought, my God, this Magritte thing, this is incredibly powerful. And then I thought about, what can I build with it? How can I learn this? And I couldn't think of an answer.

And I puzzled over this, but I'm puzzling no longer, and here's why. On Wednesday I met with one of the smartest companies I've really ever had the pleasure to meet with, and the funny thing is, they don't do a whole bunch of glamorous Web 2.0 stuff with VC funding. They build enterprise systems. And they told me why they think "enterprise" isn't a dirty word after all, despite the way the Rails community feels about it. They said that "enterprise" doesn't just mean big -- it means massively complex.

The example they gave me was inventory systems. Say you need to track a very large number of different items, structured as a very large number of different sets, in a very large number of different boxes, on a very large number of different palettes, in a very large number of different warehouses. Say further that you need to be able to reconfigure the sets these items are arranged in. You end up with a tree set, and you need to be able to represent that tree set in a database, and run reports on that database, and those reports need the kind of performance that allow you to get reports on very large data sets in a very small amount of time.

In a situation like this, you have a complex problem. But let's take it one further. Say you have some data in there which seems inessential; and that your clients or business users then give you new requirements which involve being able to reconfigure the whole system around that previously inessential data.

Sounds like a fucking nightmare, right? You have this gigantic tree set in a database, which is insane to begin with, since tree sets are best handled with linked lists, not relational rows; and you need to be able to move entire subtrees across the tree set, and of course you have to implement that in a relational database. And the whole thing has to have the type of indices and such that make databases capable of reporting on large data sets gracefully.

Enter Magritte, and assume for the sake of argument a fully mature Smalltalk ActiveRecord -- or a translation of Magritte into Ruby, and further one which allows precompilation of SQL calls, to optimize slow processes in Rails. In either case, your problem may or may not be entirely solved, but it's certainly streamlined. Because this is exactly the problem Magritte solves, on the code side. It still leaves you with the database side of the problem to solve -- and it could be that the database side is the really hard side anyway -- but what you have that you didn't have before is an elegant way to approach the problem.

It's pretty cool.

1 comment:

  1. Interesting view. I hope that people will get more, because as a
    reader not knowing Magritte now I would really like to know. :)

    I will not comment on Magritte because I'm not objective on it (I show the ancestor of Magritte to L. Renggli).

    I like the enterprise point. Indeed intrinsec complexity is an important point.

    People mentioned to me that Gemstone was one of the most powerful OO database since it could evolve schema/objects on the fly.


Note: Only a member of this blog may post a comment.