From: Nicholas Van Weerdenburg <vanweerd@...>
Date: 2005-01-02T12:06:25+09:00
Subject: Re: Ruby and Smalltalk like environment?

On Sat, 1 Jan 2005 20:21:39 +0900, Avi  Bryant <avi.bryant@gmail.com> wrote:
> 
> @(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
> 
> 

Thank you. This was very enlightening for me.

Nick
-- 
Nicholas Van Weerdenburg