From: Avi  Bryant <avi.bryant@...>
Date: 2005-01-01T20:21:39+09:00
Subject: Re: Ruby and Smalltalk like environment?


@(none) wrote:

> I wonder whether there are any
> attempts at creating more smalltalk-like environments like Squeak or
> VisualWorks, for Ruby. They offer an advanced graphical environment
> ("IDE" doesn't do it justice). Just the classbrowser of smalltalk
alone
> is worth a virtual homocide.

I suspect that part of the reason that nobody has put any serious
effort into this is that, if that kind of an environment is important
to someone, it's too easy for them just to use Squeak instead.  That's
certainly what happened to me: I used Ruby until the lack of
environment bothered me too much and then switched to Smalltalk.  If
Ruby had a comparable environment I probably would never have left, but
it's hard to justify investing much time rebuilding what I already have
in Squeak.  The exact same argument explains why nobody's built good
command line tools or emacs support for Squeak - anyone who wanted that
would be using Ruby instead.

Another reason might be an underlying difference in philosophy as to
what makes up a program.  In Ruby, as in Lisp, a program is a narrative
that builds up a particular state (of classes and methods) that then
gets used for the computation.    What the programmer is interested in,
and what gets preserved, is this narrative rather than the final state
of the program.  For example, although attr_accessor has the effect of
adding two methods to a class, you don't ever directly see or edit
those two methods, but only the single line that creates them.

A Smalltalk class browser, however, is designed to edit the current
state of the program.  *How* the state gets built up is never captured:
it's done by user interaction with a live program over a long period of
time.  The developer might (through an IDE menu, say) evaluate
something akin to attr_accessor, but the class browser wouldn't see
that - it would only see the new getter and setter methods that were
created.  And when you check your program into source control, it's the
getter and setter that would get saved, and the call to attr_accessor
would get lost.  What gets preserved is always the current declarative
state of the classes and methods in the system, no matter how they got
there.

As anyone who's worked in Smalltalk knows, there are a lot of
advantages to the declarative or state-based approach, particularly in
the level of automatic tool support that's possible - attr_accessor and
the like don't play so well with refactoring, for example.  But that
kind of runtime code generation is a big part of the gestalt of using
Ruby, and I suspect people would be loathe to give it up.

Avi