What do you think about Ruby ?

Lex Spoon lex at lexspoon.org
Tue Aug 16 15:04:52 UTC 2005


The ongoing image supported by Smalltalk implementations is one of the
least respected features in this wonderful language.   It's so good that
I really don't understand why so few dynamic language implementations
include it.  Static languages have an excuse because of inflexibilities
due to the type checker.  But dynamic languages?

Ruby doesn't support it.  Python doesn't support it in any of its
implementations.  The closest systems I know that have it are not
general-purpose programming languages:

	- Macromedia Director is quite close.  (Squeak and Director have a lot
of room for cross fertalization.  If you like active essays, then you
really should try and do a project in Director+Lingo some time.)
	
	- Emacs, with its Emacs Lisp, is close.  It has ongoing images across
program changes, but only for individual sessions--i.e., it doesn't have
snapshots.  When you log out or reboot the computer, your Emacs image
goes away.
	
	- Mathematica, I want to say, allows you to snapshot your workspace to
a file, although I have not used it enough to be sure.  At any rate, it
certainly does not force you to reboot the environment every time you
redefine a function.
	

Matej's house metaphore hits the mark for me.  From the user's
perspective, the ongoing image is not a feature.  It's a lack of a
nuisance.  Objects you create continue to exist without any special
effort.  You don't have to write a serialization routine.  You don't
have to invoke an automatic serializer.  You don't have to open a file
and save stuff to it.  If you make an object it sticks around, even
across changes to the code.

To contrast, languages without this feature require frequent reboots. 
"Reboot" sounds harsh but that's exactly what you are doing when you
find a bug in your Ruby program, kill the program, edit the text, and
then restart the program.  After the restart your program must recreate
everything from a standard initial state just the same way that your
operating system must recreate everything it cares to retain by using
its boot scripts.  Imagine if you had to reboot your OS every time you
upgraded a program, edited a script, or changed a configuration setting?
 It makes a horrible OS, and it makes--by Smalltalk standards--a
horrible language implementation.

Without the ongoing image model you cannot create objects and expect
them to stick around.  Instead, you are limited to creating code.  It is
much like the difference between objects and classes in Smalltalk. 
Interesting objects can be created in workspaces and inspectors even
though there are no associated classes with those objects.  Classes
serve a vital need when your objects mature and you want to enshrine an
abstraction that describes a large set of similar objects, but
abstractions come with a cost.  Abstraction requires mental effort above
and beyond creating individual interesting objects.  The difference
between building objects and building classes is just like the
difference between cooking a lasagna and writing down a recipe for other
people to cook that same lasagna -- it requires substantially more
mental effort, especially if you have not actually practiced a few times
to cook individual lasagnas.


Damien rightly complains that this is all poetry.  While these poems
resonate for experienced Smalltalkers, they don't convey the advantage
to outsiders.  Herbert has already listed two concrete advantages to
having an ongoing-image facility in your language implementation; let me
add a few more.


The ongoing image is an excellent way to experiment with API's you don't
know very well.  You can open up an example instance of some class and
then send commands to it.  You don't have to make a test.java file, put
code in it to initialize everything, try it, edit your test.java file,
restart the whole thing again, etc.  You can open an inspector on an
interesting object do "self x" and "self topLeft" and "self extent: self
extent * 2" and see if the API's do what you expect.  You can try "self
hidden", "self isHidden", etc. until you find the correct wording for a
functionality you are pretty sure is present.

The ongoing image also help develop code when there is no a priori
choice that is correct.  That sounds obscure, so let me give some
examples.  Consider, for example, setting color schemes for a group of
widgets.  You can't look at a text buffer and decide, but instead, you
need to look at the object and then tweak the color around until it
looks right.  As another example, suppose there is an animation in your
GUI, and you have to choose how fast the animation runs.  There's no
right answer when you are staring at a text buffer; you need to load it
up and tweak the setting until it looks right.  In cases like this, the
ongoing image of Smalltalk means you with *no extra effort* you can
start your program up and then tweak the colors or the animation speed. 
Without the ongoing image, you can still do it, but you must write extra
code to, e.g., open up a slider bar attached to the setting in question.
 Smalltalkers can do it with the standard inspectors and code browsers.

Finally, it's nice to accumulate little workspace with both snippets of
code and useful objects.  File-based languages don't support this very
well.  You can save the code just fine, but saving objects is more of a
hassle.  In my type inference project, for example, I have a lot of
workspaces around that contain results from experimental data along with
snippets of code I use to analyze that data.  I use Squeak to process
grade spreadsheets when I teach classes, and I likewise have a workspace
that holds the current grade spreadsheet plus a variety of useful code
snippets.  These things are possible in a files-only language, but you
have to write extra infrastructure yourself every time you do it.

Overall, a better question is why Ruby and other dynamic languages do
*not* support ongoing images and image snapshots?  Why *should*
programmers be content to reboot their programs all the time?  There is
no tradeoff involved once you have dumped static typing.  It's a pure
win. Programmers can "use" it when they like--i.e., they decline a
gratuitous reboot--and they can use file-based stuff as their programs
mature and their abstractions crystalize.

I only know one compelling explanation for this development:  The
original PARC implementations had it, and no Smalltalker afterwards
would tolerate less, but it's still too difficult and too strange even
for the rest of the world's best language designers.  Kudos to Alan Kay
for prioritizing such a useful and sadly uncommon feature, and kudos to
Dan Ingalls and Ted Kaehler and many others down the line for
implementing such a difficult feature.  I wish more language
implementors would follow their lead.


-Lex



More information about the Squeak-dev mailing list