Smalltalk & Seaside vs. Ruby & Rails
futuremint.com
futuremint.com
Aida (http://www.aidaweb.si is a web framework that's been around for quite a longer while and includes very nice features like Ajax for free.
Also, Iliad (http://www.iliadproject.org) is a smaller, lighter, faster framework that also provides Ajax for free. Being small doesn't compromise its power though, it's being successfully used in commercial apps.
To top it up, you may wanna take a look at the latest thing going on in the Smalltalk web dev community: Amber (http://amber-lang.net), formerly Jtalk, which is a Smalltalk dialect that runs on top of the Javascript machine, so you're actually building your site from _within_ your site, live!
Just my 2¢ ;)
Which has many of the points of an earlier talk: Django is obsolete (but so is everything else)[5]
[1] http://www.quora.com/Avi-Bryant Also creator and founder of Smallthought Systems, which was later sold to twitter[2], one of the core developers of Maglev (a Ruby implemented in Smalltalk), Monticello version control system, and many other cool stuff[3]
[2] http://blog.twitter.com/2010/06/more-than-dabbling.html
[3] http://blog.redtexture.net/2010/10/30/avi-bryants-presentati...
[4] http://confreaks.net/videos/359-gogaruco2010-rails-is-obsole...
[5] http://python.mirocommunity.org/video/1186/djangocon-2009-dj...
From the discussion here, it sounds like:
1. futuremint was developing a bunch of Rails applications in Rails 2 + Ruby 1.8.x.
2. futuremint got bored of coding in Rails, was tired of Ruby being slow, and yearned for an IDE.
3. futuremint checked out Smalltalk/Seaside and Common Lisp. He liked it for a while (for reasons that seem unclear). There doesn't seem to be much discussion of continuations (which seem most salient to me as an outsider, but who knows!). Refactoring in Smalltalk is easier (which isn't surprising given that it's a really simple language).
4. futuremint returns to Rails 3, Ruby 1.9. Things are faster, he uses an IDE, and he is content with his ability to meta-program even if the syntax is ugly. futuremint is tired of lots of boilerplate and conventions because Smalltalk is so small, and he's tired of not having a community like Ruby/Rails in either Smalltalk/Seaside or Common Lisp.
Something else is I also don't really like IDEs. They really are a symptom of a larger problem. And the code navigation tools that ship with most Smalltalk's really suck. They're like looking at the code through a straw, and its really hard to quickly grasp the pattern of how things hang together unless there is a comment describing it.
Having said that, this article has a bizarre name. There was nearly no comparison of anything. The guy actually likes and uses both systems.
The most recent post, which won't show up at the last link because it isn't tagged, is http://futuremint.com/once-again-enjoying-ruby
It took me a long time to get into Smalltalk. In the early 1980s, my local Xerox Special Informations Systems sales/support guy let me use it on my 1108 Lisp Machine for a while, and I did not get it. Long story short, it took me about 15 years to get comfortable with Smalltalk since I only tried it sporadically.
Unfortunately, my customers always seem to want to use mainstream platforms like Java/JSP/Tomcat/Java EE6/Rails, etc. For personal projects Seaside makes a lot of sense to me. Seaside is easy to deploy also (I wrote a blog abut this a few years ago, and you can find better sources on the web).
I still maintain a production application I wrote with Seaside, however my day job now entails Sproutcore & Rails.
If you're unfamiliar with Smalltalk environments and are wondering what this actually means, watch this 3-minute video showcasing a Smalltalk IDE -- the class browser, method finder, and debugger:
Anything else seems so... primitive by comparison.
Smalltalk's great drawback is over-reliance on the image:
"If your program misbehaves (and they always do) and corrupts the state of the process, things get tedious. Say you have a test that somehow failed to clean up properly. In a conventional setting, you fix the problem with your code, and run the test again. With an image, you have the added burden of cleaning up the mess your program made. [...] In general, Smalltalk makes it hard to [...] separate the application from the IDE." -- http://gbracha.blogspot.com/2009/10/image-problem.html