Re: RubyConf.new(2002) - ideas for agenda

Bil Kleb <[e-mail]> wrote in message news:<[e-mail]>...
> Avi Bryant wrote:
> > 
> > "Why I Jumped Ship to Smalltalk, and How Ruby Can Learn From It".
> 
> You discussed this a bit on the IOWA list and a couple folks thought
> we should bring the discussion over here.  Are you up to providing
> a brief summary?

Julian's already answered this somewhat, but I'll give a brief summary
as well.

There were two huge advantages to Smalltalk for what I wanted to do
with IOWA.  They may not be as important to other people or projects,
but they were enough of an advantage for this particular purpose to
make the port more than worthwhile.  For other purposes, in other
contexts, I continue to use Ruby.

The first has to do with the environment.  The Smalltalk development
environment (and there's really only one, reproduced with minor
variations for every major dialect) is in itself beautiful: I can go
into great detail for those interested in IDEs, but suffice to say
that the integration of code browsers, debuggers, inspectors,
interactive workspaces, code analysis tools, etc, is unparalleled;
VisualAge for Java had a small hint of it, but Eclipse, for example,
doesn't even come close.  The crucial feature for me, however is this:
the Smalltalk environment has no concept of an edit/run cycle. 
Instead, your application is constantly running, in the same process
as the environment, and any change you make is made to running code
(for example, each method is compiled to byte code as you finish
editing it, and is inserted into the live class; if you add an
instance variable to a class, every instance of that class is tracked
down and copied into a new structure with space for the extra inst
var).  This is nice in general, but it is almost essential for web
development. On many occasions, I have pushed new code to a running
web application as a user was halfway through a session, in response
to their questions about bugs or missing features ("What do you mean,
that feature's not there? Look again...").  I would never trust Ruby
when doing this, as there are too many gotchas.  Modifying and
reloading a .rb file into a running app is not in general a safe
operation, and so the user's session would have to be interrupted, the
application restarted, and the session started again from scratch. 
Note that this isn't a problem with stateless web apps (ie, mod_ruby
or PHP scripts), but the style of web development I do involves long
running applications with large amounts of server side state.

The only reliable way to achieve this in Ruby is to have the
development environment track changes to source code as actions, not
simply diffs to a text file.  That is, removing a method from a class
should log somewhere a call to undef_method, changing the superclass
of a class should result in something like
MyClass = Class.new(NewSuper), and so on.  This leads naturally to a
system that stores code not in simple text files, but in some kind of
database that inherently knows about objects like classes and methods;
this, in turn, leads to the complaints about not being able to use
tools like CVS.  A likely less reliable alternative that I've thought
a bit about would be a smart diff reader - something that could infer
an undef_method from the removal of some lines from a text file.

The second has to do with reification.  Everything (and I mean
*everything*) in Smalltalk can be accessed and manipulated as
Smalltalk objects.  The particular instance of this that was useful to
me was the ability to manipulate stack frames: Seaside requires a
particular variant of call/cc to do some cool but necessary magic (of
which, more perhaps later).  Now, Smalltalk doesn't even have call/cc,
in general, but I was able to implement it in about 10 lines of
Smalltalk code because the stack was directly manipulatable.  If I
were doing the same thing in Ruby I would have to write a fairly
complex C module instead.  It's a little easier in Smalltalk because
so much of the core is directly written in Smalltalk itself (including
the compiler, standard library, development environment, etc), but I
strongly recommend that as much of Ruby's internals be exposed as Ruby
objects as possible.  Robert Feldt and the RubyVM folk have of course
done some work in this direction, but I would be very happy to see it
made more of a priority.

Cheers,
Avi