Re: Why is there no Smalltalk-like IDE for Ruby?

On Sun, 2006-06-25 at 05:20 +0900, Joseph M. wrote:

Ruby should have IDE support approaching Smalltalk’s based on the
following gross generalization: Ruby and Smalltalk are pretty much the
same. Yes, I know there are many differences, and not trying to
provoke a Ruby vs. Smalltalk cage-match, but based on language features
and constructs, they are very similar.

What is holding Ruby back?

I agree. People who say they don’t want code completion or refactoring
just haven’t used it enough to know how much time it saves. I’m wicked
fast with vim search and replace, but it’s not nearly as smart as it
needs to be in order to be comparable to even a simple method-rename.
One major problem with just about every IDE that causes resistance is
that the editor component sucks in comparison to vim or emacs, which is
what many people know. Once you have wired your brain to speak through
your fingers the mouse just doesn’t work, and at least for me I think
it’s going to take something real amazing to move away from a moded
editor. (Vim 7 just came out with back-end support for code
completion…)

What makes this hard in ruby? I think loose typing and run-time
generation/manipulation of code. That’s pretty much the big barrier to
creating tools at the level of the Java world, but it is also one of the
main reasons ruby is such a joy to use. Smalltalk gets around the issue
by being inside a live environment, and having a unique sort of program
life cycle. (You don’t really generate methods at run-time, because it
is always run-time…) The tool can inspect live memory to make sure
that it refactors correctly. Also, in a Smalltalk environment every
class is defined in the browser, which gives you a much cleaner
perspective to work from. In Java the IDEs use the front end of a
compiler to build an abstract model of your program. The refactorings
are actually applied to the model in a provably correct way, and then
the changes are reflected back in the code. Having things like method
generators, method_missing and dynamic structs makes this impossible to
do without being inside a running program that can be inspected, which
just won’t work for a ruby IDE unless you turn it into a live memory
type environment.

Even with those problems though, I think many people agree that a best
effort type of approach could still be successful for a large number of
problems. If you search the list you’ll find that there are people who
are collecting refactorings for ruby. Google for the ‘ruby inertia’
project and you’ll find a pretty cool start to an openGL based
environment ala squeak. Once YARV is out it will help make all ruby
systems like that more realistic too. The RadRails project is doing
great stuff, but I have a feeling that many people in the ruby community
are allergic to bloated beasts like Eclipse that require a gig of ram to
be useful. Seems to me like any self respecting ruby-ide is going to
have to be written in ruby. (At least most of it.) The freeride
project seems to be moving along though, and I think with their
pluggable architecture it’s not too hard to jump in and add new
features. You might want to start there.

Hopefully that helps.

-Jeff

Hello Jeff,

JR> One major problem with just about every IDE that causes resistance
is
JR> that the editor component sucks in comparison to vim or emacs

Well this is your opinion.

JR> main reasons ruby is such a joy to use. Smalltalk gets around the
issue
JR> by being inside a live environment, and having a unique sort of
program

Have you ever used SmallTalk ?
It does not get around this.

JR> life cycle. (You don’t really generate methods at run-time, because
it
JR> is always run-time…) The tool can inspect live memory to make
sure
JR> that it refactors correctly. Also, in a Smalltalk environment every
JR> class is defined in the browser, which gives you a much cleaner
JR> perspective to work from.

The most important is that Smalltalk names are not as short as the
ruby ones and so you have less conflicts. Remember that Smalltalk
methods
names include parts of the parameter signature. And Smalltalk is far
from
being so overloaded.

Also while possible the coding style of Smalltalk is much cleaner then
the ruby one where people like to use the run-time features much more.
This has indeed to do with the fact that Ruby does not live in an
image.

JR> be useful. Seems to me like any self respecting ruby-ide is going
to
JR> have to be written in ruby. (At least most of it.)

Well the two projects FreeRide and Mondrian shows that you are wrong
here.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs