David Pollak's Blog - Smalltalk

Smalltalk -- Language of the gods

nospam@example.com (David Pollak) — Wed, 15 Nov 2006 09:53:49 -0800

I recently learned Smalltalk (http://squeak.org/) and wrote a little code for Pier (http://www.lukas-renggli.ch/smalltalk/pier?command=PRViewCommand&view=PRDefaultView), the Smalltalk wiki. Luke (http://www.lukehohmann.com/blog/index.php) was all happy because I was spending time with the "Language of the gods." After spending some time with Smalltalk, I understand why it's wonderful, why it's a language of the gods, and why it has not and will not become mainstream. Smalltalk is a very beautiful thing. It is a "pure" object oriented language (everything, even numbers, even blocks of code, even the execution environment is an object.) Smalltalk's syntax is very simple and very pure. Smalltalk runs in its own graphical world (Sam, http://www.javarants.com/, finds this a barrier to using Smalltalk.) Smalltalk is a live system in that the objects in the program that you're editing are live all the time. There's no 'run', you simply edit live classes of live objects and they stay live. You save your 'image' and all the running objects and all their state gets saved.

This means if you have a web server running in your image, you can save your image, stop the Smalltalk environment, start Smalltalk and load your image and your web server is running again. No need to restart anything. No need to do anything to get back to exactly where you were when you saved your image. This does not mean you have to stop your image (some folks have had images running for years.) However, if you are doing development and you need to shut your machine down to go home, you can save your image, stop your computer, go someplace else (or copy the image to another machine), start the image and things are exactly how you left them, including having your server running.

This mechanism has its pluses and minuses:

-- Always getting back to exactly where you were is awesome.
-- Because the system is live, you can inspect (and modify) any object in the system and because everything in the system (except for some byte-code primitives that communicate with the underlying OS) is an object, you can change the way the system works on the fly as well as seeing how others have implemented stuff.
-- To aid your exploration and changing of the system, Squeak (the open source Smalltalk environment I use) allows you to enable 'halos' around any graphical object and inspect instance variables and code associated with that object.
-- The halo thing works for web based applications in the browser as well (Seaside really rocks.)
-- Lots of tools for exploring all the classes in an image: 'find all the classes that implement a method', 'find all the classes that call a method', etc.
-- Because the execution environment is well defined and has clear boundaries, the code for exploring or halos or changing methods while the system is running is short, clear, and very, very stable.

-- The environment looks very long in the tooth... Squeak feels like Macintosh circa 1989. It feels like driving a 1965 Mustang... everything is in its place, but it's got an AM radio, a 3 speed manual transmission, and no air conditioning.
-- Running headless is a bear. Updating (e.g., loading the latest version of the web server or fixing a security vulnerability) a headless image on a remote server is very difficult (one has to either have a VNC session running in the image or save the image, copy it to a local machine, update it, copy it back, start it up again.)
-- The data and the code is resident in the image so stopping the image without saving causes data (state) loss.

I really like the image concept for development, but for deployment, it's a challenge and for code sharing, it's a lot more work than using CVS/SVN for text files.

The code browser (it's a class browser, editing, syntax checker, method name checker, almost like Eclipse, but has access to every object [and they're all live] in the system) has a great deal to do with why Smalltalk is a thing of beauty.

The code browser allows users to easily find any method from any class. There are all kinds of tools for finding methods. The code browser allows users to add or change methods or instance variables. The code browser does nice formatting (color syntax highlighting is optional.) The code browser helps you look up method names on the fly, does method name completion, and warns you if you're about to call a method that's not defined anywhere in the image.

The code browser has an editor window that, by default, is about 40% of the height of the code browser... or about 14 lines. This is a not-so-subtle reminder that, in Smalltalk, one writes short methods. If your method is too long, you are encouraged to refactor your code. You are encouraged to refactor your classes and push commonly used methods up the class hierarchy.

A side note... Smalltalk has a rich, deep, and beautiful class hierarchy. I looked at it. I was blown away that Smalltalk's classes are richer, more beautiful, more understandable, and all-in-all better thought out than any class hierarchy in Java, .Net, or any other O-O system I've seen.

I found myself writing "better" code in Smalltalk than I ever have in Java. I found myself refactoring early and often. Then I started asking myself why I was writing better code. I realized that Smalltalk is that a language of the gods, I was in Mt. Olympus, and I was doing as the others before me did: coding more thoughtfully.

Smalltalk is an amazingly well designed system/environment/language. It's clean, clear, precise, understandable, and in general done right. I found that I was doing things the way other Smalltalk programmers do things. I was following the example and lead of the amazing folks who wrote the beautiful classes I was browsing and learning from.

This is true of the community as well as the code and environment. The folks hanging out on the Smalltalk and Seaside mailing lists were more polite, more thoughtful, and more direct (flaming is not direct, it's counter-productive and thus less direct) than many other open mailing lists I've seen. Avi Bryant, the guy who wrote Seaside, is amazingly polite and helpful and welcoming. Stephan Ducasse, a professor in Switzerland who's written a bunch of Smalltalk books, helps beginners with the simplest issues in a really warm way.

But all of this takes a lot of work. Coding correctly requires more work and more thought and more effort and less short-term productivity than, well, being a couch potato coder. It takes a lot of work to be nice to everyone on a mailing list, even when they are not being nice to you.

The more I think about Smalltalk, the more I think about working out with free weights. It's a lot of work and a lot of discipline and a spotter and a lot of slower going at the beginning. It all pays off. It's all worthwhile in the long term. But keeping up the pace, keeping up the work, keeping up all the things that must be kept up to have fewer, more understandable, more maintainable lines of code is, well, a big commitment.

I don't think that Smalltalk will ever make it to the mainstream because it does require so much commitment. The bow-flex, treadmill, work-out in front of your TV kind of programming environments are the ones that will prevail. Smalltalk is not one of these. Smalltalk requires real work to get significant rewards. Rails and VB require filling in some blanks and refreshing your browser.

So, maybe I sound like I'm condescending to the programmers who don't want to spend the time and effort and work to make things of beauty. To the contrary. SInce I've become a father and a husband, I have very little chance to get into the "zone" required for me to build great things. I feel comfortable coding by filling in blanks. The fewer things I have to worry about, the more quickly I can get to my project goal. I want to have time and space in my brain for my wife and kids (this was not true 6 years ago when I liked nothing better than to code for 2 weeks straight with small breaks to eat, sleep, and occasionally shower.) In the past I've been able to make the kind of commitment that Smalltalk requires. I'm not sure I'd want to continue to make it over a large project.

I am not sure I'd make the commitment to being a god that Smalltalk requires. Most of the developers I meet on a day-to-day basis... the kind of developers who work hard and are conscientious in the work for 10 or so hours a day are not looking for an environment that requires a mind meld. They're looking for a tool to achieve their goals. From what I've experienced with Smalltalk, I don't think Smalltalk is that kind of tool.

Smalltalk is in fact a language of the gods. Unfortunately, one must make the commitment to work as hard as the other gods to generate output. That, I think, means that Smalltalk will continue to attrack programming gods and continue to grow as a thing of beauty, but will also continue to be a niche language.

Smalltalk -- some early thoughts

nospam@example.com (David Pollak) — Sun, 03 Sep 2006 12:00:00 -0700

The exploration continues.

I've spent part of my vacation learning Smalltalk and the whole Smalltalk development environment. Some may consider that a lack of vacation... but for me... it's a vacation.

First, I have to say, the guys that invented Smalltalk implemented most of the good ideas in programming and development environments back 20+ years ago. This is totally amazing. Amazing for the following reasons: (1) I'm an idiot for not learning Smalltalk earlier and (2) most of the rest of the world are idiots for not using more of the good stuff from Smalltalk. It's like using Windows for my whole life and realizing that Unix does everything that Windows does, but better and with less hardware. On this tangent... I wonder if the circa 1984 Smalltalk image could have fit on a 128K Macintosh. If so, Steve & Co. should be cursed a whole lot for not building Mac entirely in Smalltalk. It's clear that NeXTSTEP could have been done in Smalltalk rather than Objective-C. The 68030 and RAM in the original NeXT machines could have supported Smalltalk. The only issues would have been building a JIT for the Smalltalk VM and protecting the IP of the environment.
Smalltalk as a language is a tad more verbose than Ruby, but less so than Java. It's dynamically typed, but the object browser and other tools give the developer almost as much in terms of help and hints as does Java/Eclipse. It's weird living in a windowing environment that's 20+ years old (and looks it.) On the other hand, like Emacs (or Vi), the Smalltalk environment has almost everything down just right. So far, I'm missing the break/continue loop construct and the Ruby collection 'join' method (although Smalltalk classes are open, so I'll add 'join' to one of the root collections.)

The Smalltalk class hierarchy is nothing short of totally amazing. It's a couple of generations advanced from Java and a couple of more generations ahead of Ruby. It's amazingly rich and robust. These Smalltalk OO guys really, really think OO. It's a thing of beauty to read most methods (except maybe asString which is a pig-dog of a method and should be shot.) Once again, a class hierarchy that's 20+ years old aces Java, .Net, and everything else.

Smalltalk's everything is a block syntax is very nice. It promotes writing clean code. I'm really enjoying it.

Smalltalk has all the meta-programming features (and more) of Ruby. There's very good access to the compiler and it's possible to do impact virtually every part of the running system. However, with Ruby, everybody is playing with meta-programming. It's difficult to find any software that doesn't dynamically modify its own classes, etc. With Smalltalk, there's very little code that accesses the compiler/run-time. It looks and feels much cleaner. Maybe it's because the Smalltalk guys went through a meta-programming wild-and-crazy time and found that mucking about with every class on earth is a bad thing or maybe they just built a more flexible system. I don't know, but I haven't seen the meta-programming crazies in Smalltalk that I see in Ruby.

I've been using Squeak (http://squeak.org) which was spun out of Apple and is developed by Alan Kay (the originator of Smalltalk) and some other Smalltalk luminaries. So far, the implementation is very robust, but it does suffer from some of the issues I have with Ruby. The Virtual Machine is single threaded (it's got its own thread scheduler which makes some less than optimal choices.) It's interpreted (but there's a hot-spot style JIT in the works -- just a side-note the guys that built the Java HotSpot JIT were part of a company that was building a strongly typed Smalltalk system. Sun acquired them and they built the Java JIT.) Performance is similar to Ruby for some strait-line benchmarks. Because Smalltalk has much richer collections classes, it's easy to optimize Smalltalk code to run faster than Ruby code (e.g., using IntegerArray vs. Array, linked lists for stacks and queues rather than Arrays, etc.)

VisualWorks (another Smalltalk implementation) is reputed to run much faster than Squeak. It's commercial and costs a non-trivial amount for licenses. It may be worth the price depending on how much performance is an issues.

Smalltalk's debugger is the best thing I've ever seen. If there's an error in your code, the debugger pops right up, allows you to fix your code, inspect (and change) variables, and restart where you left off. It's like Eclipse without the issue of making changes to a class that renders the classes incompatible with the prior version requiring a JVM restart. Rumor has it that Eclipse was built by IBM's Smalltalk team and that earlier versions of IBM's Java tools were written in Smalltalk. Also, as a digression, Taligent was building a C++ development system that focused, like Smalltalk, on editing a method at a time. The Tagligent system was wicked cool, but never saw the light of day. Looking back, it seems that the Taligent folks were trying to apply a lot of Smalltalk goodness to C++.

There are some negatives.

Squeak and most Smalltalk systems are graphical. Running them headless on a UNIX server requires real work. It's kind of like running a Windows machine as a server. It always expects to have a graphical display. Apparently VNC is a way of life for running Smalltalk on a server.

There's no native mixins for Smalltalk. I find that mixin methods (basically a "prototype" layer on top of the hierarchical OO mechanisms) are very helpful. For example, Ruby has a rich comparable mixin for any class that supports the '<=>' method. There are some external mixin systems for Squeak, but I haven't evaluated any of them.

There are far fewer libraries for Smalltalk than for Ruby. Most notably, PostgreSQL is the only relational database that has a supported adapter. There are a few O-R mapping tools, but as far as I can tell, they're all pretty alpha/beta. There's no ActiveRecord for Smalltalk.

There's no native Regular Expression support. There's a regex library which sucks rubber donkey lungs ('Hello World' regexMatchAll: 'l*'. causes an infinite loop.) In reality, the regex library should be written in C for performance reasons.

The syntax isn't as nice as Ruby. You can't write 1_000_000 to mean 1,000,000. There are no '!' or '?' as part of a method name which is really nice to denote methods that have nasty side-effects or methods that ask questions. There's no post-fix style conditionals (print 'you do-do head' unless being_nice?)

On the plus side...

There are excellent unit testing facilities. Smalltalk is the root of all common unit testing libraries (SUnit begat JUnit begat RUnit...)

The class/method editing and browsing facilities are very, very nice.

The folks on the mailing lists are both very nice and very knowledgeable. The guy who wrote Seaside and DabbleDB spent a lot of time answering questions about how he's hosting the Smalltalk instances that run DabbleDB. This is a lot different than the high noise ratio on the Ruby boards.

There's an awesome Object database (Magma) that has very active developer support. Using Magma means not having to deal with O-R mapping. I'm putting together some tests to see if Magma can scale to support a 40-80GB database. If it can, it may address a lot of issues with persisting objects.

The Seaside and Squeak mailing lists seem to be increasing volume.

Squeak supports both byte and double-byte Strings and deals with intermixing the use of them very effectively, although some folks complain about the memory and processor overhead of double-byte Strings.

Finally, there seems to be a lot of cross-over between Ruby and Smalltalk. Dave Thomas who wrote a fair number of Ruby books has also written a fair number of Smalltalk books. Seaside was originally written in Ruby, but Avi switched to Smalltalk because he found there was more depth of support in the Smalltalk community. There are some rumors of a Seaside backport to Ruby.

I'm sure I'll have more of a rant when I'm hard-core into Seaside, but I figured I'd do an interim rant for all of you.

Rails and Seaside -- Two new, great web frameworks

nospam@example.com (David Pollak) — Sun, 20 Aug 2006 12:00:00 -0700

I've been casting about recently, looking for a good set of tools for building applications... mainly applications with a web interface.

I've looked at a lot of environments. Ruby/Rails and Smalltalk/Seaside offer a lot of cool, compelling features.

Java has been my language of choice for 9+ years (since early 1996.) With the help of Dani Pletter, I wrote a framework of domain specific languages that sat on top of the JVM for building web applications (SmartMode.) The syntax for SmartMode was XML with embedded Java. SmartMode compiled the domain specific languages to byte-code at run-time and shoveled them into the JVM so that one could make a change to a SmartMode managed file and the change would be reflected on the next browser refresh. The only time the web container needs to be reloaded or restarted is when changes were made to the Database Schema (this is due to Java's strong typing.) Dani and I were able to write applications about 10 times faster with SmartMode than with other Java tools (we built SmartMode in 2000-2001, at the time Struts was in its infancy and there were very few good OR mapping tools.)

SmartMode included DSLs for Object-Relational-XML Mapping (it generated Java classes that knew how to persist themselves, call stored procedures, and update the database schema and stored procedures automatically [kind of like migrations.]), Web site navigation including access control, multi-page, multi-object Object-HTML-Object mapping (it included state management, support for multiple forms in multiple browser windows, field level validation, etc. much like ActiveRecord validation mixed with a sub-set of Seaside's state management) and a Collection->HTML Table generator (this tool was much maligned, but the more times I have to iterate over objects to create HTML tables, the more I miss it.)

After 5 years, it was clear that SmartMode was long in the tooth. We never managed to open source it, although we've been trying for almost 2 years. That kind of made me start looking for a new environment to program in. It would have taken a lot of effort to retool SmartMode for AJAX and quite frankly, the world doesn't need another Java framework.

I looked at Spring for about 5 minutes. It's a bloated pig. I know it's slimmed down versus other Java frameworks, but if I have to write an XML file and 3 Java files just to get "Hello World!" it's a bloated pig. And while Spring is all about Inversion of Control, it doesn't feel like any well done IoC app I've ever seen.

A side-note... the all-around best development environment I ever used was NextStep. NextStep (now Mac OS X) is built on Objective-C. ObjC is a series of SmallTalk style object extensions to the C language. It's dynamically typed like SmallTalk. There is much message passing. The GUI and application framework that sits on top of ObjC is a beautiful message based framework that allows for the creation of GUI and other applications in very short order. To give an example, I wrote the GUI for Mesa (http://www.plsys.co.uk/mesa.htm) in about 4 or 5 weeks. When I went to write Mesa 2 (http://sundialsystems.com/mesa/index.html) it took me over 4 months to replicate a subset of Mesa's functionality using C++ and OS/2's Presentation Manager. ObjC/OS X and SmallTalk are all about Inversion of Control and most responses to UI messages are 6 or 7 lines of code rather than the bloat that's required for a statically typed system that is requires that the developer handle the plumbing of a UI or Web request.

In November, I started looking at Ruby/Rails. My first impression was that it was very SmartMode-like. The first thing Rails did was create the framework of an application for you. You started filling in blanks. Rails has a built-in web server, so with very little configuration, you can see the results of your application in your browser. The flash-to-bang time for Rails is amazingly short. ActiveRecord (Rails' Object-Relational mapping layer) does most of the basic CRUD (Create, Read, Update, Delete) stuff that you need to do with a database very easily. ActiveRecord has marginal, but allegedly improving, support for complex OR mapping tasks. Between Rails and Open Source Web Design (oswd.org) one can build a simple web site very very quickly.

Ruby as a language is an amalgam of Perl, SmallTalk, Lisp, and a few other languages. As a Java developer, I was able to pick up Ruby in 30 seconds (okay, my propensity for picking up new languages is quite good, but still, compared to OCaml, Ruby was a walk in the park.) It figure the average Java developer should be writing reasonable Ruby code in a week. If the developer had Visual Basic experience, it'll take less time.

As a dynamically typed language, Ruby gets almost everything right at the syntactic level. It's really beautiful to read and write. It's very expressive and, with the exception of some of the meta-programming constructs, most of Ruby makes sense to any Java, C, C++, etc. programmer.

So... I was totally loving Ruby. Until I started to push the language and the runtime.

The Ruby interpreter (there is no Virtual Machine although there are many alleged to be in development) is dog slow. The best performance I've seen, Ruby is 7 times slower than Java (this is for a short process, including JVM start-up time that spent most other the Ruby time doing RegEx.) Most hard-core Ruby tasks take 50-100 times more time than Java and in the case of some hard-core outliers, Java is 1,000 times faster than Ruby.

The Ruby runtime is not stable. I've crashed it repeatedly doing floating point math.

Ruby strings are based on 8 bit characters. While there are a variety of UTF-8 libraries for Ruby, basic methods like 'length' return the number of bytes, not characters, in a string. This is especially surprising given that Ruby was developed in Japan.

The current version of Ruby is 1.8.4. Ruby has been at 1.8 since 2000. Version 2.0 will not be available for at least 18 months. This is a very long cycle, but is due to the fact that Matz seems to be the only one writing most of Ruby's core interpreter and libraries.

There's no viable Ruby debugger. In order to debug a Ruby app, you've gotta use printfs. I kid you not.

Finally, the Ruby interpreter runs on Green Threads, so it can't make use of more than 1 CPU on the new wave of SMP machines. This is due in large part to the underlying IO structure and the way Ruby talks to C programs. It would break many of the existing C libraries if Ruby moved to a native threads model.

For the standard fast_cgi deployment of Rails applications, very few of the above issues have a material impact and the programmer productivity gain of Rails versus Spring/J2EE (about 10x) justifies buying marginally more hardware to run more Rails processes (note that most of the time servicing web requests is spent in the database so the Ruby slowness issue translates to a 1.5-2x increase in the amount of CPU needed to service the Ruby process vs. a similar Java application.)

Rails is amazing, but has its issues as well. It is almost entirely defined around the concept that a web page request translates into a database query/update and the resultant display. This is true in the simple case. However, Rails doesn't have much of a security model, either at the page access level or at the database level. Thus, each page must be protected either with code in the controller or with some third party "engine." The existing user management engines are binary in the way the protect pages: users that are logged in can see everything and all other users can only see the "public" pages. Objects pulled from the database must each be checked to see if they belong to the user that is accessing them. There are scant mechanisms to filter objects in a way that users can only see what they own. Further, the Rails methodology of including database primary keys as part of the URL perpetuates the issue because it's very easy to change the ID in the URL and see data that belongs to others.

Rails has the notion that all state with the exception of the ID of the user for the current session should be kept in the database or passed as part of a web request. This means that making multi-step processes (e.g., checking out of a store, managing a shopping cart) is very difficult and prone to failure. It also means that there is a lot of database traffic for each page load. It also also means that COMET style (http://en.wikipedia.org/wiki/Comet_%28programming%29) web app development is very, very difficult. On the other hand, scaling Rails deployments is brain-dead simple and if one of the fast_cgi processes dies, no state is lost... the user just needs to hit reload.

Rails also has a bunch of security vulnerabilities. The recent 1.1.4-1.1.5-1.1.6 3 day upgrade-o-rama fixed the ability for an attacker to execute arbitrary code on your server if they knew where the code was relative to the Ruby code. This is because files are included by creating paths to the files in the file system and sometimes URIs are merely appended to the paths... well you get the idea. Every Rails form submission can change any attribute on an ActiveRecord object unless the programmer has taken the affirmative step to filter out the fields returned from a POST based on the fields put in the form originally. This means that an attacker can change the primary key of an object by appending ?foo_id=44 to a web post and voila, the object has a new primary key and can over-write another object. There are other lurking vulnerabilities as well. But at this point in time, Rails is as insecure as PHP was 5 years ago.

For building a simple CRUD app, there's still nothing better than Rails. For any application requiring complex user interaction or multiple user interaction, Rails is not the best solution.

I have spent the last 4 days playing with Seaside (http://seaside.st) Seaside is a Smalltalk web application framework. It takes a 180 degree different approach to building web apps than does Rails. First... some background.

Smalltalk is the superclass of all object oriented programming systems. It's a dynamically typed, everything is an object, language that runs on top of its own virtual machine. It was originally developed at Xerox PARC (now known as PARC) in the 70's. It was created in an era of limited computing resources, networks, mice, graphical displays, etc. It's syntactically nice (not as beautiful as Ruby, but a whole like prettier than Java.) Its performance seems to be very good. It seems to be very stable (I'm using Squeak http://www.squeak.org/ )

Squeak is maintained by folks like Allan Kay. As opposed to being "language hobbyists" (as some folks refer to Matz) these guys are the fathers of Object Oriented programming and were around for the creation of TCP/IP and most of the other things we consider advances in computing.

Everything in Smalltalk is an object. Smalltalk originated as a systems programming language (as did C) and has built in process control, etc. However, Smalltalk objects are all live and can be modified on the fly in the running Smalltalk system. This means you can get an exception in a running process, debug the exception by changing code, hit "go" and the process will resume where things broke. Yes... it's that good. It's that flexible.

With the caveat that I haven't tried to beat Squeak into a bloody pulp with 90M record text files, etc., I believe that it's a very stable runtime.

Smalltalk has code blocks you can pass around (in fact, almost everything is a code block that's passed around.) Smalltalk easily allows you to build "continuations." You can say "take a snapshot of the current thread context, save it (in a hash table, array, local variable, instance variable), and start executing it later." This has very important implications for creating non-linear programs using a linear syntax (and we all think linearly.)

Seaside takes advantage of Smalltalk's continuations by allowing the developer to put different components on a page at the same time and each of the actions of the components (expressed as HTML <a hrefs> or form field) executes some code when it happens. Okay, this can be done with Java (think about a program littered with anonymous inner classes) or Ruby (lots of closures.) For example:
html link: 'add one' do: [self count: self count + 1 ] .
html link: 'reset' do: [self count: 0 ] .

However, Seaside also allows a "call:" construct which is done in the flow of the Smalltalk program. You "call:" another Seaside component which is substituted in the HTML display for the calling component and the results of the called component are returned in the normal flow of the caller. So, it would look something like:
address := self call: AddressForm new .
(address inState: 'NY' ) ifTrue: [self alert: 'We don't like New Yorkers' ] .

The AddressForm would be substituted in the DIV where the other HTML content was (that div could be the whole HTML page or just the part of the user checkout) and the user could fill in the right values, the AddressForm could span an arbitrary number of HTTP request/response cycles, validate stuff and when it was successfully complete, the flow of control would return to the caller which tests to see if the address was in New York.

We did stuff like this in SmartMode, but SmartMode could only handle a single multi-page form at once. Seaside can handle the state of an arbitrary number of objects on a page at the same time. So, you could have your address form, your chat with the sales person form, etc. all on the same page and Seaside takes care of managing the state among all the objects, etc.

Seaside correctly manages multiple browser windows open to the same form on the same site. Seaside correctly treats each browser window as a separate logical session.

Seaside also deals correctly with state changes resulting from the back button (it does this by saving continuation snapshots of all the components that are rendered for each page load.) And Seaside has transactional isolation so that the back button won't let you go back to a page after your credit card has been cleared.

If all of this isn't cool enough, you can write your entire Seaside application in the browser. Seaside will display the entire Smalltalk object hierarchy for you, let you add, edit, and remove methods and classes, change CSS, etc. all in the browser and you see that changes in your application. If your app throws an exception, you can fix the code that caused the exception in the browser, hit "try again" and see how things change.

Seaside is very secure in terms of how the responses are handled. Each link and each form element has a unique ID and if that ID doesn't exist in the runtime, it's thrown away. This means doing replay attacks is not possible. It means that hidden links are useless outside of the current browser's state. It means that you can't add a parameter to an HTTP request and change the ID of a database object. It also means that QAing a Seaside app is more difficult because automated tools won't work.

Finally, Seaside has amazing AJAX integration. Because Seaside manages what needs to be served as part of an HTTP request, it determines if all the components on a page need to be re-rendered (e.g., a Web 1.0 page load) or if only a particular component needs to be re-rendered (a component or two or three that were made dirty by an AJAX request.)

DabbleDB was done in Seaside and the main Dabble developers are the guys who maintain Seaside. Everyone I know who has played with Dabble thinks it's the best web app ever.

So... what's wrong with Seaside. Well:
- There's no stable, well maintained Object-Relational mapping layer.
- There's no documentation (it's worse than the lack of documentation for Ruby/Rails)
- There's no HTML layer. All the HTML is rendered programmatically. This is not like CGIs from days of yore. This is html div: [ html text: 'foo' . html text: 'bar' .] It makes sense because all the formatting is done with CSS, but still, without a graphical HTML editor, it's a challenge.
- All the state is managed in the Smalltalk image. If the Smalltalk engine crashes, so does the state. It also means that all requests for a particular user be sent to the same Smalltalk instance (this is doable for load balancers, but requires more work.)
- There's a smaller community around Seaside and it may not reach critical mass.
- It requires a totally new way of thinking. It's not just IoC, it's much much more. While Rails has a shallow learning curve for Java, JSP, PHP, Python guys, Seaside is much, much different.

So... why this rant? Well... even though haven't gotten to my "hate" point with Seaside (I've gotten to that point with most technologies, although with NextStep and Java, I came back to loving them... with Ruby, the jury's still out) I think it's got the right pieces parts to make it a quantum shift in web development. I think the kind of apps that could be commonplace with Seaside are totally not doable with any other web technology. But... I needed to get a lot of this stuff off my chest.

If any of you have a chance to check out Seaside, it's worth 4 hours of time. I'm interested in what you think.