R
Rick DeNatale
This is an intriguing idea. I'd love to have a Smalltalk-like IDE for
Ruby. I think that there are issues which make this an interesting
(i.e. difficult) task, so it might be worthwhile to discuss those
issues.
For those who aren't familiar with Smalltalk, most Smalltalk
implementations combine run-time with the development environment.
That is to say that the development tools (browser/editors, debugger,
object inspectors, ...) are written in Smalltalk and run in the same
process as the code under development. This gives a great deal of
power to the ide, for example in Smalltalk, it's quite possible (and
common) to run your code, and when it brings up the debugger on an
exception or a breakpoint, edit the source code IN THE DEBUGGER,
maintaining as much ofthe execution state of the program as is
possible given the point on the execution stack of the change. Then
you can continue excution. I'll call this the 'always running'
feature.
Another feature of most Smalltalk environments is that the running
state is persistent, When you leave the environment you can save the
memory image, and when you come back everything is as it was,
including instantiated objects, and the state of any threads which
were running/suspended at the time of image save.
Another feature was that in traditional Smalltalk implementations,
source code was saved in the image, usually via offsets in the methods
to a 'changes' file. The system kept every edit of every method and
class definition, both to give an audit trail, and to allow recovery.
I think that this is what Richard is hinting about when he talks about
an 'image-based' vs. 'file-based' language. I'd say that this is a
feature of the development environment rather than the language
per-se. It's really an issue of just how integrated the I in IDE is.
Most IDEs today are really just extensions of the 'emacs as shell'
idea, in that they are editors with the ability to invoke and interact
with other development tools to a greater of lesser extent. Smalltalk
ides tended to be integrated in that they subsumed the functions of
most if not all of those other tools.
Now these features have both good and bad aspects. From a developer's
perspective. It gives great freedom and power. On the other hand it
poses issues for deployment. Tools were needed to strip the image of
the development tools if you wanted to ship a streamlined application.
Another issue is/was that the source code system didn't play well with
other source control/configuration management tools. To a large
extent, the Smalltalk community went its own way on this one,
extending the change file/log approache with Smalltak based SC/SM
solutions to allow team development and tailoring Smalltalk
applications to a particular platform or environment. Probably the
most popular of these extensions was Envy/Developer from OTI which
kept source code in a repository. Rather than a check-out/check-in
model with optimistic locking a la CVC or SVN, Envy saved every edit
in the repository. The equivalent of checking out was to mark the
current set of edits in a developers image with a tag.
I think that this 'file-based' vs. 'image-based' question can be
separated from the other issues. Of course if you want to be able to
save execution state in an image, it's probably important to be able
to keep track of what the current source code is whether it's stored
in files/a repository/or someplace else.
But I digress. The real issues which interest me in starting this
thread are those which revolve around making an ide for Ruby with the
'always running' features of the Smalltalk IDE. One issue I see here
is that Ruby as it stands right now doesn't really have a strong
enough introspection model of the execution state. For example,
walkbacks are strictly textual, whereas in Smalltalk the development
environment could obtain objects from the VM which represented the
execution stack and could be manipulated by tools like the debugger.
Richard also brings up the idea of using run-time introspection as an
aid to features like code-completion. FIrst let me say that I can't
really recall much support for code-completion in Smalltalk
environments. What they typically provided was the ability to select
text in a browser and ask for an 'explanation' which told you as much
as could be determined about a variable, message, etc. You could also
do things like finding all senders of a message you were looking at
(what this really means is that you are looking at say Foo#bar it
would show you every method which invoked bar against any receiver),
or find all the implementors of the methods, or find the
senders/implementors of any methods sent by the methods being browsed,
etc. The problem of code completion in both Smalltalk and Ruby is
that if you are looking just at the source you really don't know all
the possible bindings of a variable to objects. If you are looking at
a stack frame in the debugger, you know the current binding so you
could do code completion based on the current object, but I don't see
that as a general solution.
And of course Ruby ups the ante here because it's got a much more
dynamic notion of objects, including singleton methods, dynamically
created instance variables, modules ...
Saving the state between runs likely requires support from the
interpreter/VM, it's really a matter of saving a relocatable memory
dump, then having the VM load and relocate the image on startup and
restore execution state from the relocated image.
And I'd see this not as a simple 'interactive visual irb.' As useful
as irb is, it's really not a good basis for an IDE, I see it as a nice
eval-print-loop tool for trying out ideas, but an IDE needs lots more,
the function which irb brings to the table is pretty small in
comparison to the whole job that I'd think it would be better to start
from scratch here.
Now, I'm not trying to throw cold water on this idea, I'm actually
quite interested in a discussion of how some of these issues could be
attacked so as to get a more dynamic IDE for Ruby.