She sells seashells by the Seaside
Something like that.
I’ve been playing with Avi Bryant’s continuation-based web framework Seaside, which is written in Smalltalk. Wow. That’s all I can say. After some recent work with Rails, I had come to admire the cleanliness of the framework—even if, on occasion, I had some complaints about short-cuts taken that need not be necessary. Compared to Seaside, Rails seems to me to be a jalopy. Don’t get me wrong, it’s a seriously pimped out jalopy, but the easy with which one can build interactivity and modify it on the fly with Seaside is mind-blowing.
There is, however, a concern about integration with database systems—as there always seems to be when I have to deal with Smalltalk. I am looking at integrating through Alan Knight’s GLROP, which has some brilliant mapping ideas and largely allows for the disposal of mind-numbing shifts between Smalltalk and SQL. My concern however, is that one of the data-sets I need to work with is current housed in a MySQL database, and as far as I can determine, there’s no functional MySQL support and the one I had heard of is no longer available.
NB: Don’t take this as a slam of Rails, as it’s not. Rails is brilliant—for what it is. It takes the historical model of page interaction and data storage to new heights of simplicity. It doesn’t, however, change how you view the web. Seaside does. Whether you use it for your next project, or not, it’s worth looking at, going through the tutorials, and allowing your mind to conceive of a web that simply behaves more naturally.
This entry was posted at 9:24 am on 23 November 2005 and is filed under Ruby, Smalltalk. You can follow any responses to this entry through the post-specific RSS 2.0 feed.
I agree, Seaside makes you think about the web in a different way. I built an inventory management application with it in a period of less than 24 hours that works beautifully. And there is some complex logic, something that would have given me headaches in rails. As for database integration, since this was a new application I opted for just storing the objects in the Smalltalk image. A class level variable suited me just fine.
“just storing the objects in the Smalltalk image”...no offense, but this really makes me shudder. Don’t know anything about your app so maybe it was the perfect solution, but for anything really sizeable that can’t afford to screw up, you really need all the fancy concurrency stuff that modern relational databases have. It’d be non-trivial to re-implement. Not to mention indexing, some kind of flexible query system, query optimization, robust transactional backup…the list goes on.
Actually modern relational databases aren’t very modern, or very powerful. They’re really quite antiquated and I’d much prefer “modern object databases,” which in some ways is what a Smalltalk image is. The question of where to store data is a complex question, and largely depends on the issues of what you are storing and the read/write/update model that is used.
Many applications I work on have strange profiles for data usage. Either they are exceptionally high update, which kills “modern relational databases” dead, or have scary-high (1000:1) write to read ratios, with updates verbotten, that also kill “modern relational database.” Instead, I’ve often had to design custom data stores.
The “flexible query system” many people think of, etc., is great when you are designing a general purpose—one size fits all, looks good on nobody—solution, but in many situations, I’m dealing with very unusual data mining strategies and again, query optimization often requires hand-tuning to perform at the level of performance needed.
I realize I don’t work in the normal rectangular accounting world, but then neither do a lot of people. They just try and use it as a box to constrain their solutions.
Responses are currently closed, but you can trackback from your own site.
If you’re not already aware of it, Borges is a Ruby port of Seaside. And yeah, it’s reeeaal nice.