Why Every Ruby Developer Should Learn Smalltalk

DZone 's Guide to

Why Every Ruby Developer Should Learn Smalltalk

· Java Zone ·
Free Resource

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'
  puts 'false'

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:




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


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}