My Full-Circle Journey Back to Smalltalk

I suppose it’s time to tell my story. I was a Smalltalk zealot in the late 90’s, but I left it behind when I started my own business. I’ve now come full-circle, and I’m finding once again that Smalltalk is the best tool for most of the programming work I do.

I learned Smalltalk programming from Travis Griggs while working at Key Technology. He mentored me in Smalltalk and other general programming methods, and I introduced him to Linux. Travis likes to give me more credit than I deserve for some of the work that we did together, but one thing was certain: we had a blast working together.

Key went through a difficult aquisition, and I spent most of my energy working to bring our two software teams to common ground. My wife and I travelled back and forth between Medford, Oregon and our home in Walla Walla (with our newborn son, our first) while I worked with developers in both locations. Diplomacy is not something I particularly enjoy, but I’m good at it and the team really needed somebody in that role.

But the end result was that I didn’t get much time to do any significant programming. The more time passed, the more I missed it. I didn’t get to work with Travis as much anymore, and our team was becoming fractured as our project list grew. Despite all of my efforts to bring people together, our team was dissolving under the increasing project load.

I had always wanted to work from home, and I was becoming burned out in my Key position, so I left Key and took up consulting work. Most of my clients needed web applications, so I became a web developer.

I built my first web applications in Smalltalk. Travis and I had written the original WikiWorks code, and I used our experience there to build my own HTTP 1.1 server. This later became the basis for the Swazoo server, which was built on my code at Camp Smalltalk 2000 in San Diego. I implemented my own Smalltalk Active Pages (abbreviated SAP, to distinguish them from ASP sites) and built several sites using them.

At the time, there wasn’t much web application work being done in the Smalltalk world, and the frameworks people were developing were unattractive to me. I had to support myself, from top to bottom, and this was starting to feel painful.

This was what drew me towards PHP, Apache, and PostgreSQL. The promise of safety in numbers was attractive — I would never have to wonder if my server was fully compliant with the HTTP specs. But the main attraction for me was PHP’s support for for various open source libraries. PHP made it easy to handle image uploads in multiple formats, draw custom graphs, and build other visuals on the fly. Editing PHP apps in vim was easier over low-bandwidth connections (like a cell phone data connection) than making a VNC connection to a headful server image, too.

So I left Smalltalk behind and built a few large PHP apps. Nearly all of them relied heavily on PHP’s graphics library bindings for generation of custom reports and editable page components. I built content management systems that let my customers edit their page titles, for example, and behind the scenes PHP would generate new navigation buttons from template PNGs and TrueType fonts. Another app managed a database of donors for a non-profit radio network and allowed call-center volunteers to easily enter pledges from supporters — while the studio crew saw up-to-the-minute totals on their screens.

Things went smoothly at first but got rougher as the applications got bigger. I made heavy use of the flimsy object model in PHP 4 and built my own object-relational layer, and this helped me survive as long as I did. But I grew increasingly frustrated as I tried to scale my PHP applications. There was no way around the ugliness of the code.

seaside.jpgAt that time, somebody pointed me at one of the early versions of Seaside. I had taken a look at Seaside a few years ago, and while it looked interesting, I confess that I didn’t get it. I saw how call: and answer: worked to give you a certain level of modalism in your application, but that was all I saw. The Seaside HTML writers were less mature then, too, and that was a deterrent to me. I liked being able to interleave PHP and HTML code in template files, but that was mostly because my pages didn’t use CSS effectively.

I missed the larger picture, so I went back to PHP.

When Ruby on Rails started to gain popularity, it was like a breath of fresh air to me. Rails is a very clean framework for web applications, and it required no paradigm shift. Much of the work I had done in PHP already followed some of the Rails patterns, but now I had a full-fledged object-oriented language at my disposal again. I thought I had finally found the best of both worlds — a thriving community, lots of support for graphics formats, easy database connectivity, and a nice clean dynamic language.

These days, that would sound like the end of the story. But it’s not. The truth is, I’m disappointed with Ruby. Rails is “classic web development done very cleanly”, as Ramon Leon says. And Ruby is my favorite non-Smalltalk language. But it’s not Smalltalk. In fact, I’ve come to see that Ruby missed the mark on several points.

  1. File-based source control. In a Smalltalk image, all of the classes and code libraries your application needs are available to you immediately. Tools like the Refactoring Browser are much harder, if not impossible, in Ruby.
  2. Reflection. Ruby’s reflection is OK, but it’s much weaker than the reflection in Smalltalk. If more of the Ruby base code was itself written in Ruby, and Ruby allowed better reflection, a Ruby code browser would undoubtedly be easier to write (and more powerful once written).
  3. Speed. The Ruby interpreter is slow. In Rails, I still end up writing more complicated database queries than I should have to, because the Ruby interpreter is so slow to process data in memory.
  4. No Keyword Messages: Travis and I ran some tests using keyword-style messaging using Ruby’s last-argument-collapsed-as-hash, and the performance was terrible.
  5. Blocks. Ruby simply missed the mark on on these. All blocks should be first-class objects, not just a layer of syntax.
  6. Live Interaction. Irb is good, but Smalltalk workspaces are much better.
  7. Debugger. The Ruby debugger feels like gdb compared to Smalltalk. Most of the time, people opt to debug using console output and interactive exploration using Irb. It’s better than printf, but not much.
  8. Class Library: The Ruby class library is much younger than the extensive class library in Squeak or VisualWorks.

As far as Rails is concerned, I have far fewer criticisms. But once you’ve looked at Seaside, and you really understand the approach Seaside is taking, Rails just looks old. I never want to marshal data through a URL again if I can help it.

I’ve also come to see that unless you’re a light user of a technology, you have to be able to support yourself. This is not a downside for Smalltalk, it’s a reality of the complex environment we work in. Smalltalk’s web and graphics tools have come a long way lately, but ultimately Smalltalk empowers you to support yourself in a way that Ruby just doesn’t. I have been digging in the Ruby 1.8 source tree more often than most, and it’s not nearly as easy to navigate as the Smalltalk base. Remember, most of the Smalltalk base is implemented in Smalltalk.

Seaside is certainly more advanced than Rails in terms of raw technology, to the point that it’s hard to wrap your head around the concepts. It took me two attempts, and I’m fairly young and intimately familiar with Smalltalk. Rails is smoother — it gives a better out-of-the-box experience in the short term. But for larger web apps, you need to be thinking further than that.

Don’t be surprised if Seaside just looks weird to you at first. Leave it for a little while and then come back. You’ll be glad you did. And when it clicks for you, beware. You won’t ever look back.

Advertisements

13 Comments

Filed under Rails, Ruby, Seaside, Smalltalk

13 responses to “My Full-Circle Journey Back to Smalltalk

  1. Travis Griggs

    Hahaha! I think “Ken likes to give me more credit than I deserve for some of the work that we did together” but we did indeed have a blast.

  2. What’s the scalability of Seaside like? I’ve been hearing a lot more about it lately and how awesome it is from a development point of view, but I haven’t seen how it compares when it comes to real-world usage. What kind of traffic load can it take compared to a similar Apache/PHP or Rails app on the same hardware? What’s the RAM requirements like, etc?

  3. The answer is “it depends”. Different Smalltalk implementations perform differently. For the highest performance, VisualWorks is the best choice. I’ve seen a single VisualWorks server withstand a slashdotting, and this was an old Linux box.

    Squeak’s performance isn’t as good, but it’s at least as good as Ruby. Not only that, but because of Seaside’s continuations and the smart caching that takes place in Glorp (an object-relational framework), your database load is significantly reduced.

    If you want to scale beyond a single server, you need to use a load balancer with persistent connections (i.e. the same session always goes to the same server).

    Sorry I don’t have any hard numbers for you — that might make an interesting post for someday later. I can tell you that in the few comparisons I’ve done, Seaside + Glorp is noticeably faster than Rails — even running on the Squeak VM.

    In short, I think you’ll run into scalability issues on Rails long before you’d see them in a Seaside application.

  4. Thanks for the info, Ken!

  5. Ken, great post. Sean, for Dabble DB (running Seaside on Squeak), scaling has all been about getting the basic architecture right in terms of how to partition the load over multiple servers and VMs. Once we got that right (and it’s not that hard), increased load can be cheaply solved by just buying another server. Increasingly, for most applications, I think “does it scale” is a moot point. If you get to the point where you need more than a couple of servers, you’re probably very happy.

  6. Hi Ken. Nice post. I was recently doing some prototyping on making something more “Active Record” like using Glorp facilities. The general idea being to make things as automatic as possible, without being as limited. It’s published as GlorpActiveRecord. As someone who’s worked with both, I’m curious as to your impressions on that, and what would be needed for it to be really production quality.

  7. jc

    Great post. Already started writing a few test apps in Seaside. Interesting… to say the least.

    To me that whole stateful requests in seaside seems like a fatal flaw. Rails has a philosophy of the webserver being completely stateless. No session, cache, or data should be kept on any production server.

    Requests should be able to come in to any of the application servers and still be handled gracefully. This I think is the essence of web scalability. Raw code performance is moot when added a couple more app servers is as easy as making a few line tweaks to a capistrano script.

    Anyways… thanks for the heads up. I love that I finally an excuse to start writing smalltalk again.

  8. Pingback: yonkeltron » If Smalltalk can Squeak, why can’t Ruby Rumble?

  9. The first item in your list of where “Ruby missed the mark” was that Ruby uses file-based source code. Interestingly enough, the lack of file-based source code was one of the primary reasons I left Smalltalk for Ruby!

  10. Most of the items in that list are things where PHP is either no better, or worse, but you relate having worked with PHP very well for some time. As to the item of “Speed,” Smalltalk was considered by many to be too slow once upon a time too ;)

  11. Pingback: A journey ‘Back to Smalltalk’ | MikeWitters.com

  12. mikewitters

    Great post. Although my thoughts weren’t as detailed as yours, I agree with most of what you said.

  13. Idetrorce

    very interesting, but I don’t agree with you
    Idetrorce

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s