Dangerous Ideas

I asked nicely, and Avi Bryant was kind enough to give me access to Dabble recently! It’s a really amazing application, and I’m really looking forward to giving it a run through. For those who don’t know, Dabble is a Web-based service that makes it easy to create database applications – without code. Here’s an example of a public Dabble application for Smalltalk jobs – it includes RSS feeds generated by Dabble, and HTML views.

My first application will probably be a version of the humble to do list. The to do list applications I use most often these days are the ones in my Treo/Palm Desktop and the ones in Basecamp. Both are relatively simple, and work fine as far as they go, but I find that I almost always revert to a text format for to do lists because to do list applications invariably are less flexible than I’d like.

This may all change, though. Dabble seems flexible enough that I can setup my to do lists to track any information I want, and even allows me to change my mind about what I want to track and takes care of backend changes magically.

As someone who makes her living partly as a programmer (I’m a Jill of all trades, really), I wish I could get my hands on the Dabble code – it would make things so much easier. And I mostly program in Ruby on Rails these days. That said, I really like Smallthought’s effort to keep Dabble code-free (from the users’ standpoint) – I can’t remember seeing anything as powerful as Dabble that didn’t involve coding before.

Of course, Dabble is written in Avi’s Seaside framework, so at least part of the power is available to programmers.

Unlike most Rails programmers, I chose to use Rails after already choosing to use Ruby, and I chose Ruby almost completely because it closely resembled Smalltalk. The main reasons that I’m not using Squeak and Seaside right now instead of Ruby and Rails are:

• The libaries I find myself needing a lot exist more often in the Ruby world than in Smalltalk (well, at least Open Source Smalltalk; I bet I could find most of what I need in VisualWorks). Things like regular expressions are not common in the world of Squeak (with Squeak, you can use a C plug-in, but it’d be nicer if it there were a native way to do regexes). Another library I’ve been using recently is Ferret, which is a Ruby port of the Lucene search engine.
• Smalltalk isn’t exactly the best when it comes to integrating with non-Smalltalk libaries (again, this might be different with the commercial Smalltalks).
• Squeak’s license. I’m not sure this is a big deal – there are some who think SqueakL is freer than many open source licenses – but it’s a recurring issue, if only because Debian won’t include it in their distribution.
• Believe it or not, but … Rails’ larger marketshare makes it easier to sell to customers.

Maybe when Dabble leaves beta and becomes a killer app. Seaside will get a lot more attention, and then the last of the issues above will go away. As for the others … at one point, the benefits of using Squeak an Seaside could outweigh the cons. There are plenty of times I’ve hunted down bugs in a Rails application where I wished I had something even remotely approximating Seaside’s debugging support. The breakpointer script is certainly better than nothing, and better than what some other frameworks offer, but it still has nothing on Seaside/Squeak. And, of course, there’s the fact that Seaside is a stateful framework. This means that you can set an instance variable in one method and expect that it’ll still be set when you call the next method, even if that’s in between a couple of page loads. And, of course, being a continuation-based framework (maybe the reference continuation based framework), there’s support for the back button.

If you haven’t seen Dabble in action, read through the Smallthought blog and check out the videos:

• Dabble video clip 1: Migration.
• Dabble video clip 2: Column Menus.
• The a video demonstration of Dabble given at a Vancouver Lisp User’s Group (LispVan) meeting/.

Also, if you’re curious about Seaside and when you might use it instead of Rails, check out the Ruby on Rails Podcast inteview with Avi Bryant. The sound quality starts off poorly, but it gets (somewhat) better later on.