Ruby and Smalltalk like environment?

[@(none)]

Hi there,

I've been getting up to speed with Ruby in the hollidays. Tempted by the
combination of the Pickaxe 2nd ed, Gems and Rails, I've been using
Emacs/iruby like I would use Python (ipython) or Common Lisp (SLIME).

Though that's a proven and winning combo, 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.

Because Ruby is often compared with smalltalk and because of its dynamic
nature it seems to be an ideal language for these type of applications.
Haven't found any though: Ruby seems still to be firmly rooted in the
Unix/text/console world.

 

[Avi Bryant]

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

 

[Lothar Scholz]

Hello ,

n> Hi there,

n> I've been getting up to speed with Ruby in the hollidays. Tempted by the
n> combination of the Pickaxe 2nd ed, Gems and Rails, I've been using
n> Emacs/iruby like I would use Python (ipython) or Common Lisp (SLIME).

n> Though that's a proven and winning combo, I wonder whether there are any
n> attempts at creating more smalltalk-like environments like Squeak or
n> VisualWorks, for Ruby. They offer an advanced graphical environment

Ruby is not a image based language. Thats the huge difference.

n> ("IDE" doesn't do it justice). Just the classbrowser of smalltalk alone
n> is worth a virtual homocide.

There are two companies working at it at the moment.
There is no open-source project now.

n> Because Ruby is often compared with smalltalk and because of its dynamic
n> nature it seems to be an ideal language for these type of applications.
n> Haven't found any though: Ruby seems still to be firmly rooted in the
n> Unix/text/console world.

 

[Richard Dale]

There are two companies working at it at the moment.
There is no open-source project now.

What about FreeRIDE, Eclipse RDT or KDevelop? You may argue that Arachno is
the only production ready IDE or whatever, but saying 'There is no
open-source project' is misleading in my opinion. And which is the other
commercial company, I've only heard about Arachno as a commercial IDE?

I'm working on the combination of the QtRuby/Korundum bindings with
integrated Qt Designer support (for GUI design) and graphic source code
debugger for the KDevelop IDE. It is certainly a complete graphic RAD
environment for ruby. The debugger was based on code for a gdb front end,
but it also adds a Qt 'Object Inspector' that has capabilities similar to
this C++ product:

http://doc.trolltech.com/solutions/qtobjectinspector/overview.html

I'm mainly going after Qt/KDE programmers wanting a better language than C++
for developing their applications, and who are new to ruby, rather than
existing rubyists or smalltalkers, and so the fact the development
environment looks like an existing C++ one is a plus.

Because I'm working on both the bindings and the development environment
I've been able to integrate them to a greater extent than otherwise would
be possible. For instance, a variable of type Qt::Color appears as a color
in the KDevelop debugger Qt::Object property inspector.

You can get the current sources from the kdebindings and kdevelop modules -
they should both build against any KDE version from KDE 3.1 to 3.4. I hope
to do a new release and put it on the Korundum RubyForge site shortly to
make it easier for people to try out.

Ruby is not a image based language. Thats the huge difference.

Yes, you're right - that is the key point. I've wondered if it would be
possible to design a ruby development environment where the program was
'always running', and you replaced methods using a 'module_eval' call after
the IDE did the syntax checking on a newly changed method. Then the IDE
would need to keep the ruby sources sync'd as you changed them during
runtime. And perhaps keep a version history of changed methods so you could
revert and so on.

-- Richard

 

[Avi Bryant]

What about FreeRIDE, Eclipse RDT or KDevelop? You may argue that Arachno is
the only production ready IDE or whatever, but saying 'There is no
open-source project' is misleading in my opinion.

I found Lothar's post misleading in a different way - the original
poster was asking about a Smalltalk-like environment, and there isn't
anything, commercial or not, that provides this for Ruby. It was
explicitly not a question about IDEs in general (" 'IDE' doesn't do it
justice" was the OP's comment). I don't think Arachno is relevant in
this context.

However, he did say "working at it", so it's possible that he's
referring to something that hasn't yet been released. If so, I'd love
to hear more.

Avi

 

[gabriele renzi]

Richard Dale ha scritto:

Lothar Scholz wrote:



What about FreeRIDE, Eclipse RDT or KDevelop?

they're not Smalltalk-ish environments, I guess.

Yes, you're right - that is the key point. I've wondered if it would be
possible to design a ruby development environment where the program was
'always running', and you replaced methods using a 'module_eval' call after
the IDE did the syntax checking on a newly changed method. Then the IDE
would need to keep the ruby sources sync'd as you changed them during
runtime. And perhaps keep a version history of changed methods so you could
revert and so on.

does'nt SLIME for emacs somewhat work like this?

 

[Lothar Scholz]

Hello Richard,

RD> What about FreeRIDE, Eclipse RDT or KDevelop? You may argue that Arachno is
RD> the only production ready IDE or whatever, but saying 'There is no
RD> open-source project' is misleading in my opinion. And which is the other
RD> commercial company, I've only heard about Arachno as a commercial IDE?

The question was about a smalltalk like class brower.
FreeRIDE, Eclipse RDT or KDevelop, ArachnoRuby don't have something
like this.

Yes i'm working on it for Arachno (nothing published so far), the
other is a small but well known german company who is doing this for a
very very huge german company. They haven't announced anything so you
couldn't here about it yet.

RD> Yes, you're right - that is the key point. I've wondered if it would be
RD> possible to design a ruby development environment where the program was
RD> 'always running', and you replaced methods using a 'module_eval' call after
RD> the IDE did the syntax checking on a newly changed method. Then the IDE
RD> would need to keep the ruby sources sync'd as you changed them during
RD> runtime. And perhaps keep a version history of changed methods so you could
RD> revert and so on.

Sure this is possible but you would run into many problems when you
use existing runtime libraries. Almost all of them are not useable in
this way and you see it in web environments like rails (or
webware/zope for python).

But we discussed this many times in the past.

 

[Dick Davies]

What about FreeRIDE, Eclipse RDT or KDevelop?

A Smaltalk environment isn't an IDE, it's more like a
viewport into a running process.

 

[Lothar Scholz]

Hello Avi,

AB> However, he did say "working at it", so it's possible that he's
AB> referring to something that hasn't yet been released. If so, I'd love
AB> to hear more.

The idea is to extend an interactive console like irb with more
features, giving you at least a small part of the things possible
with smalltalk. The ideas are from an older IRB thread.

First you must write a startup file that contains all the require
statements for all libraries and files you want to include into your
"image". After loading this the console runs into the usual
eval-execute loop, waiting for interactive commands or signals from
the editor and other tools (like the mentioned class browser).

After receiving such a signal the console checks which of the required
files are modified and then they are reloaded.
But only the parts of the file that contains method/class/module definitions
are executed.

Modifying code during runtime is not very dangerous - even language
like Java/C++ have a edit/continue feature in state of the art
debuggers. Changing the data structure/global variables is much more
difficult. To get this right the i played with the following idea:

Source files can have two special sections marked by comments, for
example

##=> Once
All code after this special comment is executed only after an
explicit reset operation (console restart).

##=> Reload
All code after this line is executed on each reload.

So if you must define/modify some global data you can simply place
them into this sections and write them in a way that they are handled
correctly - this is a task for the programmer and not the ruby
environment.

With tools like parsetree and the introspection/reflection features
of ruby it's not very difficult to write a class browser that can show
the object space and synchronize it with the text found in the source
files. Coding conventions are very usefull here to give good results.

And please remember that the goal is not to make ruby a smalltalk with
a different grammer, it is to make development more interactive.

 

[Florian Gross]

The idea is to extend an interactive console like irb with more
features, giving you at least a small part of the things possible
with smalltalk. The ideas are from an older IRB thread.

First you must write a startup file that contains all the require
statements for all libraries and files you want to include into your
"image". After loading this the console runs into the usual
eval-execute loop, waiting for interactive commands or signals from
the editor and other tools (like the mentioned class browser).

After receiving such a signal the console checks which of the required
files are modified and then they are reloaded.
But only the parts of the file that contains method/class/module definitions
are executed.

This sounds a bit like Rails with the breakpoint.rb integration.

 

[Lothar Scholz]

Hello Florian,


FG> This sounds a bit like Rails with the breakpoint.rb integration.

Yes, there are not so many ways to do it if you don't plan to rewrite
ruby. It's only different when you get into a more detailed view.

 

[Nicholas Van Weerdenburg]

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

 

[Friedrich Dominicus]

Because Ruby is often compared with smalltalk and because of its
dynamic nature it seems to be an ideal language for these type of
applications. Haven't found any though: Ruby seems still to be firmly
rooted in the Unix/text/console world.

We do feel as you do and are trying to build such an IDE and yes we
are heavy influenced by Squeak ;-)

You may want to check out ArachnoRuby, which I found the best
available Ruby IDE at the moment.


Regards
Friedrich

 

[Friedrich Dominicus]

Because Ruby is often compared with smalltalk and because of its
dynamic nature it seems to be an ideal language for these type of
applications. Haven't found any though: Ruby seems still to be firmly
rooted in the Unix/text/console world.

Well yes that is or would be a really nice thing to have. If you like
you can check out ArachnoRuby which I found the best availabel Ruby
IDE at the moment. The browsing is not like in smalltalk but more in
the "tradition" of Windows IDE browsers, will say with trees. It's
second best for browsing but YMMV

Regards
Friedrich