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