A recent blog post by Gartner Analyst Mark Driver picks up on the increasing interest in Smalltalk. There are many factors contributing, but one of them appears to be the rise in popularity of dynamic languages like Ruby, Python and others. Smalltalk has pioneered many of the concepts behind these languages a long time before they were conceived and has been around since the 1970/1980s. Many of the Smalltalk VMs have been around just as long and have reached a high level of maturity.
Seaside
Another reason for the interest in Smalltalk today is, like with Ruby and Ruby on Rails, a web framework. Seaside has been around for a while and has gathered a lot of interest. Avi Bryant is behind DabbleDB, an online database which is built on Seaside (InfoQ has an interview with Avi Bryant talking about how DabbleDB makes use of Smalltalk's image concept for persistance and how Squeak can be made to scale).
While Seaside was developed on Squeak, recently many other Smalltalk vendors have started supporting it as well. Cincom Smalltalk supports Seaside and offers WebVelocity, a GUI tool for Seaside development in the browser (a short video introduction to Web Velocity is available, a longer demonstration is available at Google Video). GemStone, who's behind GemStone/S, a Smalltalk that offers persistence and clustering, also supports Seaside, eg. with their GLASS product (which is also available in a free edition).
Ruby and Smalltalk
Smalltalk was one big influence on Ruby, and it continues to do so. Rubinius, for instance, has used Squeak Smalltalk as a model for implementing their VM, and GemStone's Maglev is built right on top of a Smalltalk VM.
While Ruby's grammar is more complex than Smalltalk's simple grammar, it's still being influenced. Named parameters ('keyword messages' in Smalltalk), for instance, aren't available in Ruby, although they can be emulated using hash iterals, a feature that's long been available in Smalltalk.
Ruby:
def foo(arghash) # ... do something with arguments 42 end foo( :name => "foo", :size => 42)
Note: Ruby 1.9 offers a more compact literal hash syntax, which allows to omit a few characters.
The same using Smalltalk keyword messages (note that the method's name is made up of all keyword arguments):
:name name :size size "this is a comment ... do something with arguments" ^42. receiver name: 'foo' size: 42.
Languages like Objective-C also have Smalltalk-style keyword messages.
Smalltalk has also managed to avoid the many variants of Lambdas, Procs and Blocks in Ruby, recently joined by the new 'stabby lambda' syntax (-> {}). Smalltalk has one way to create block: [:argument| ^42] creates a block, it takes one argument and returns the value 42.
Another difference between Smalltalk and Ruby is the availability of tools and IDEs. Ruby IDEs have only recently started to become available, whereas Smalltalk has always been closely integrated with IDEs (although there are Smalltalks without dedicated IDEs, eg. GemStone/S or GNU Smalltalk). Ruby IDEs, however, are very different from Smalltalk IDEs, for instance: all of the Ruby IDEs are written in a non-Ruby language. The Ruby support in Aptana (RDT), 3rd Rail (DLTK), Netbeans, IntelliJ is written in Java, SapphireSteel's Ruby In Steel is based on Visual Studio. There's the Ruby based FreeRIDE, although it's development seems to have stopped.
Ruby IDEs provide static analysis, type inference, and other logic for analyzing and modifying Ruby code - but all of that code is written in either Java or C# and depend on either JRuby's AST or RubyInSteel's AST. The availability of an AST of Ruby source has recently been improved with Ryan Davis' ruby_parser, which can take Ruby source and return the AST (in UnifiedRuby format), complete with comments and line numbers.
Smalltalk's IDEs, on the other hand, are written in Smalltalk. Static analysis tools are available too, as well as refactoring tools (the first refactoring tool was actually Smalltalk's Refactoring Browser).
Interview with Randal L. Schwartz
To get a view of someone who moved from a language often associated with scripting (Perl) to Smalltalk, we talked to Randal L. Schwartz. Randal is the author of many popular books and columns on Perl. Recently he's spent a lot of time using and advocating Smalltalk, declaring the "The Year of Smalltalk". He's also on the leadership team of Squeak.
InfoQ: Seaside's known for using continuations for maintaining state. Avi Bryant recently mentioned that the product he's working on, DabbleDB, has been moving away from using continuations because AJAX allowed for a different application model. What's your experience with this? What makes Seaside an appealing web framework to use?
Continuations allow me to create abstractions control flows, much in the same way that I would create abstractions of layout views. I can have an abstraction called "show this form until it validates" in a library, and the library can return the incomplete page containing the web form until it validates, all apparently "within" a call to the library. Without continuations, I'd have to hook up some top-level recognizer to say "ok, this is a response to a form input that this library now needs to see", and I'd lose all my local state.
InfoQ: What method(s) of persistence are you using in your Smalltalk and Seaside applications? Are you using an RDBMS with Smalltalk? What's the ORM library situation for Smalltalk?
For legacy interface, Glorp is Object-Relational mapper of choice. Glorp is in active development to add an "Active-Record"-style layer as well.
For new applications, I'd highly recommend the product from GemStone, which puts the VM inside a completely persistent environment. Objects just naturally persist, and thus don't need to be dissassembled into SQL for insertion into and retrieval from a classic database.
InfoQ: What Smalltalk versions do you use - which ones do you have experience with? Are they all equivalent - or are some more suited to particular problem domains?
I'm on the leadership team for Squeak, and I've been tracking Squeak since its initial release. I only recently started playing with Cincom VisualWorks, so I'm learning more about it as I progress. I think GNU Smalltalk is interesting, but as a Squeak contributor, I can't look at it because of the licensing issues (GPL code cannot be derived into MIT-licensed releases).
InfoQ: Ruby 1.9 added Fibers - a construct which can also be used as symmetric coroutine. Some Smalltalk versions also use these instead of exposing heavyweight kernel threads - what's your experience? In Smalltalk versions that only have userspace threads - are there situations where you'd like to use kernel threads?
I'm not a big fan of threads. In Unix, thread is spelled "f o r k" for a reason. I think sharing should be opt-in, rather than opt-out, and threads presume the wrong default.
InfoQ: You've been actively promoting Smalltalk for some time now. What are the two most common questions or objections to Smalltalk you get?
"Smalltalk, isn't it dead?" Hardly.
"Can I edit with my favorite editor?" Basically no, and you wouldn't want to use your favorite editor when you realize you're only editing 5 to 10 lines of code at once anyway, and you really want an editor that is sensitive to the current environment. The built-in code editors do that just fine.
One approach to make Smalltalk usable from IDEs like Eclipse is the STDT. It's based on Eclipse and translates Smalltalk's code into files and resources. The "Industry Misinterpretations" podcast has a long interview with one of the STDT developers. As an aside, Eclipse and Smalltalk should go together well, particulalry, as Rick DeNatale explains, because Eclipse grew out of IBM's Smalltalk efforts.
InfoQ: What's your elevator intro to the Smalltalk - how would you explain it to your, say, Perl friends?
Smalltalk - I can teach the *entire* syntax to you in 20 minutes. It's pure objects, and the debugger allows for live debugging, even in a web environment. Smalltalk has distributed source code management built in, and can talk to any library on the system either natively or via FFI. Smalltalk can talk to files, devices, and sockets as well as any Perl program can, and has been around for *far* longer. Every bit of your interaction with the system is open and editable and customizable, including your dev tools.
InfoQ: Who's behind Squeak nowadays - and how is development moving forward?
The Squeak Leadership team (including me) represents the community to oversee the overall project. We also have Web teams, Release teams, News teams, and so on, to handle the specifics. (http://www.squeak.org/Community/Teams/)
InfoQ: What features - language concepts or other - from Perl do you miss in Smalltalk, if any?
I still use Perl for command-line scripting. Smalltalk doesn't lend itself to small programs very well. :)
InfoQ: What's your opinion on Ruby's Open Classes (Monkey Patching)? Have you used Squeak's Traits?
It's nice that a package like Seaside can teach every object to "render itself" on a web page, with the class dispatch mechanism used for appropriate selection. Without that kind of patching, you have to build the equivalent of class dispatching at the user code level, and it's never as clean.
InfoQ: Ruby has seen many new implementations come along recently - Smalltalk has had many different runtimes from different vendors. Do you see the different implementations of Smalltalk as a problem or an asset?
The two big smalltalks I play with (Squeak and VisualWorks) actually shared a common ancestor (the original Xerox Parc image), so that's not much of an issue. However, projects like Seaside are actually helping to ensure that vendors stay fairly close in features, so this is a good thing.
For more information on Smalltalk by Randal, he's been interviewed on the Industry Misinterpretations podcast, and he co-hosts the FLOSS Weekly podcast. One episode is particularly interesting for everyone curious about Smalltalk: FLOSS 29: Interview with Dan Ingalls, who wrote the first Smalltalk runtime from a language spec by Alan Kay back in the early 1970s, and many of the following Smalltalk versions at PARC, as well as Squeak. Randal also blogs about Smalltalk.
For more information on Smalltalk and how Smalltalk developers approach software development, one source is Cincom's James Robertson, who blogs about Smalltalk and also publishes a daily screencast and a weekly podcast.
GemStone has a blog focussing on GLASS, their GemStone/Linux/Apache/Smalltalk/Seaside software stack.
Finally, a list of free books on Smalltalk is available online.