Victor is a ruby developer at Nulogy. He has worked a lot with Java and Ruby platforms. Being a big fan of domain specific languages he likes to blog about implementing them using Groovy, Ruby or Clojure. Victor is a DZone MVB and is not an employee of DZone and has posted 43 posts at DZone. You can read more from them at their website. View Full User Profile

Why Every Ruby Developer Should Learn Smalltalk

02.02.2012
| 4626 views |
  • submit to reddit

No matter what kind of programming you are doing these days you probably heard a lot about Smalltalk. And there is a reason for that. Its influence on what we are doing and using right now is hard to overestimate. Refactoring, XP, TDD, many VM technologies came from the Smalltalk community.

As programmers we tend to become excited about new shiny things and don’t appreciate the history of our craft. Node.js is making a lot of buzz. Let’s all learn Node and will talk only about it! As a result we are solving the same problems over and over again and often not choosing the best tools for the job. In my opinion, we all need to learn some historically important technologies such as Smalltalk or Lisp.

What is interesting about Smalltalk

1. Smalltalk syntax
in Smalltalk:
service := WeatherForecastService forLocation: 'Toronto'.
forecast := service forecastForDays: 5 format: 'Xml'. 

in Ruby:
service = WeatherForecastService.forLoctaion 'Toronto'
forecast = server.forecastForDaysInFormat(5, "xml")

It’s much closer to English that, for instance, Ruby. Though it’s a little bit unusual for people who used to use dot as a message-sending operator the Smalltalk version of this snippet, in my view, is more readable.

Another syntax feature I really like in Smalltalk is having block literals. If you need to pass multiple blocks to a method in Ruby it always looks clunky and probably that’s why it’s not a common idiom:

service.forecastFor ->{puts "Do stuff"}, ->{puts "handling errors"}

The same code will look better in Smalltalk:

service forecastFor: [Transcript show: 'Do stuff'] error: [Transcript show: 'Error!'].

This feature leads to a huge variety of interesting patterns Smalltalk programmers use a lot and Ruby programmers don’t.

2. Minimalistic language

Smalltalk has very few concepts. For instance, there is no special syntax for loops or conditionals.

(1 = 1) ifTrue: [Transcript show: 'True'] ifFalse: [Transcript show: 'False']

 

That’s how you do conditionals in Smalltalk. It’s just the ifTrue:ifFalse message you send to a boolean. Why is it cool? Because it makes the language more flexible. People often complain that in Ruby 0 and an empty list are truthy.

if []
  puts 'true'
else
  puts 'false'
end

The snippet above will print ‘true’ and you cannot do anything to change it in Ruby. But you can easily change this behavior for Smalltlak. If you want to send the ifTrue:ifFalse message to your OrderedCollection and treat an empty collection as ‘false’ just define ifTrue:ifFalse method. As there is no special syntax for loops and conditionas just defining a method solves the problem. And you don’t need to use any magical “hooks” the VM knows about.

Don’t get me wrong. I’m not saying that the Ruby language is worse than Smalltalk. It’s a very different approach. Ruby’s syntax is very rich. It has tons of special constructs for solving special problems, which often leads to a very elegant code. Smalltalk, on the other hand, gives you a few basic constructs that scale very well.

3. It’s imaged based

But syntax is not the most remarkable feature of Smalltalk. What really differentiates it from other languages is that it’s more than just a language.

Smalltalk = VM + Language Smalltalk Program = VM

When you start writing a new app in Smalltalk you don’t open Emacs or RubyMine you launch a VM. And the VM gives you all tools such as a class browser or a debugger to write your code. Using these tools you make changes to the VM, that’s how you write applications in Smalltalk. Basically, every Ruby app can be viewed as source code and as a running app. The source code is just text and the running app is a group of objects interacting with each other. In Smalltalk there is no such separation. You view the source code of your application while running the application. Platforms that don’t have this separation are called image based. Each time you close your VM a new version of an image will be saved on disk. Next time you run it you will start from exactly the same state you left it last time. When your app is ready Smalltalk can generate a production image by extracting only parts of the VM your code depend on. So the image you deploy to production won’t contain IDE parts in it.

4. Awesome tools

The fact that Smalltalk knows about itself makes the process of developing tools easier. Even today, after 40 years since the first release of Smalltalk its tools can amaze you. Though the language is extremely dynamic refactoring really works. Debugging is also amazing. If you try to send a message that Smalltalk doesn’t understand it will ask you if it’s a typo and suggest a few messages that you most likely tried to send. If your app raises an exception it will display a dialog with a backtrace. You can click on each level of the stack and inspect all objects. Isn’t it awesome?

5. … and more

There are a lot of really awesome things in Smalltalk I haven’t mentioned in this post that you should check out: distributed object stores, continuations etc.

6. Implementations

If you’ve decided to give it a try there are 2 implementations I’d like to recommend:

http://www.pharo-project.org/home

http://squeak.org/

 

From http://victorsavkin.com/post/16375110741/why-smalltalk

Published at DZone with permission of Victor Savkin, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Andreas Haufler replied on Thu, 2012/02/02 - 3:41am

Nice post Victor. I totally agree with you, when I first saw the beaty of the syntax and the excellent design of the overall system, I immediatelly fell in love with SmallTalk. Let alone the ability redefine the "if" clause really amazes me. Since Squeak, and I think also Pharo contain the complete source code of the vm and runtime system, you can learn a lot from it.

regards Andy

Otengi Miloskov replied on Thu, 2012/02/02 - 4:51am

I will throw from the windows any day any language or platform if SmallTalks become main stream with competitive virtual machine(performance as JVM) and good IDEs as Eclipse, If that day comes where do I sing. Even Ruby looks ugly compared to SmallTalk!.

James Ladd replied on Mon, 2013/06/17 - 6:20pm

You might also want to try Redline Smalltalk

It is a Smalltalk for the Java Virtual Machine and it uses the same tooling you
are using today. This might ease you into a Smalltalk based on an image.

- James.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.