Why is there no Smalltalk-like IDE for Ruby?

[joe]

Hi all --

I shout my question to the entire Ruby + Smalltalk community: Smalltalk
has had amazing IDEs for decades, why not Ruby? Smalltalkers, Ruby
needs your help!

I'm hoping to start a centralized discussion about this topic, since my
searches have only turned up scattered comments.

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? How has Smalltalk overcome the issues?
What can Ruby tool builders (such as the RadRails folks and, hopefully,
me) learn from the Smalltalk IDE builders? Reasons I've heard for
Ruby's lack of tool support include:
- Ruby is not a compiled language
- Ruby does not execute in a VM or run-time
- Ruby is a loosely-typed language and has blocks, etc.
- Nobody really cares enough about a Ruby IDE to make one
- vi is all you need!

Regarding the compiled language and VM arguments: what about Ruby's
irb? Regarding loose typing, blocks, etc: Smalltalk has these! I
don't pretend to understand all of the issues, but I want to learn.
Unless there is something I simply don't "get", it seems that the Ruby
community does not care or see the benefit of real tool support, which
leads me to believe that (again) the Smalltalk community is not very
interested in Ruby.

I've only been working with Ruby for 8 months after 7 years of Java,
but I almost feel like a Smalltalker by association, having worked
with, and for, Old Dudes Who Know Smalltalk (yes, I said it) my entire
career. I've stepped back into the stone age regarding IDE support
after using VisualAge for Java, Eclipse, and InilliJ IDEA. No
refactoring, no fast debugger support, not even
code-completion/suggestion. To the current tools, Ruby is text to
colorize. Smalltalkers, you've cracked this nut years ago, help us
understand how to do it again in Ruby!

-- Joe
http://www.josephmoore.net/

 

[jarober]

IMHO, the reason there isn't one is simple - lack of funding. The free
Java IDEs are all funded (Eclipse by IBM, Netbeans by Sun). Smalltalk
IDEs (other than Squeak) are all commercially funded, and Squeak's
initial IDE was funded (way back when) by Xerox. Building a coherent
IDE takes a team of developers who are all focused on the same thing -
and I simply don't see that happening in the absence of funding.

 

[Huw Collingbourne]

Hi all --

I shout my question to the entire Ruby + Smalltalk community: Smalltalk
has had amazing IDEs for decades, why not Ruby?

I am generally in sympathy with your views. However, there are some good
reasons why a Smalltalk-like environment isn't as neat a fit with Ruby as it
is with Smalltalk. The main reason is that Ruby wasn't designed from the
ground up to integrate seamlessly into a graphical ide. With Smalltalk, the
"join" between the language and the development environment is hard to find
for the simple reason that the creators of Smalltalk built everything to
work together. Write some code in a 'notepad' (or Transcript) and just try
it out. Browse for a class in the hierarchy browser and write some code
while you're there. etc. etc.

The Smalltalk language 'knows about' its development environment at quite a
deep level. The fact that Ruby does not have any built-in knowledge of an
environment makes it relatively hard work to make the language work
'seamlessly' in an IDE - I speak as someone who is trying to do just that
;-)

In order to get Ruby to work tightly with an IDE you have to let the Ruby
interpreter run bits of code and return values (such as output or debugging
information) and then figure out how to use those values in the IDE (say to
set breakpoints). As Ruby essentially doesn't know you are doing this, it
doesn't necessarily provide you with the most useful information for making
best use of the IDE. Unlike Smalltalk, Ruby doesn't know about any hierarchy
browsers or Transcripts that you may wish to use so sometimes you have to
grab the information from it almost by 'brute force'.

While it would be nice to have Ruby work in Smalltalk-like partnership with
its development environment, there are positive points about decoupling the
programming from the environment. In Smalltalk you are constantly modifying
the class library from one session to the next - and it is quite possible to
introduce behaviour that may have seemed neat this time last week but does
not seem anything like as good now (and worse still, you can't remember
which bit of the hierarchy you modified this time last week - eek!) The fact
that Smalltalk saves images of its state not only makes this kind of
accidental modification-embedding a constant hazard but it also has
disadvantages when you want to write small, lightweight, self-contained
programs - the kind of thing that Ruby excels at.

That said, there are things in Smalltalk (the browsers, the
context-sensitivity, the ability to evaluate code on the fly) which would be
very attractive, imo, in a Ruby development environment.

Hmmm.... speaking of which, I have work to do

best wishes
Huw

http://www.sapphiresteel.com
Ruby Programming In Visual Studio 2005

 

[gregarican]

This would be a tough order. Because the IDE/image aspect would be
tacked on after the fact, as opposed to being part of the initial way
Ruby was designed from the get-go. Without a major undertaking by a
considerable group of developers I would fear that this "tacked on"
scenario would be a bit disjointed. Kind of like how Perl added OO
elements over time. Kind of fugly

 

[joe]

Hi Huw --

The Smalltalk language 'knows about' its development environment at quite a
deep level. The fact that Ruby does not have any built-in knowledge of an
environment makes it relatively hard work to make the language work
'seamlessly' in an IDE

Now that makes sense! Not being a Smalltalker myself, I did not
realize that the development environment was so deeply integrated into
Smalltalk itself. This really sheds some light on the problems faced
by Ruby IDE developers (such as yourself): given a language that is not
statically typed (like Java) that does not know about it's development
environment (like Smalltalk), how do you know "what's going on"? Thank
you for that perspective.

Also, keep up the good work. As you know, I'm cheering for Steel.

-- Joe
http://www.josephmoore.net

 

[Kelly Hall]

IMHO, the reason there isn't one is simple - lack of funding. The free
Java IDEs are all funded (Eclipse by IBM, Netbeans by Sun).

My favorite Java IDE is BlueJ - www.bluej.org It's simple and works well.

Kelly

 

[Cesar Rabak]

Huw Collingbourne escreveu:

Hi all --

I shout my question to the entire Ruby + Smalltalk community: Smalltalk
has had amazing IDEs for decades, why not Ruby?

[snipped]


The Smalltalk language 'knows about' its development environment at quite a
deep level. The fact that Ruby does not have any built-in knowledge of an
environment makes it relatively hard work to make the language work
'seamlessly' in an IDE - I speak as someone who is trying to do just that
;-)

I'm affraid this is one possibility, but not the only one. If we take
the counter example from Python (another 'scripting' language) the IDEs
for it are very capable although its design is fundamentally similar to
Ruby.

In fact there are a few features I miss even in more recent ST IDEs!

my 0.019999...

 

[AnalogFile]

Hi all --

I shout my question to the entire Ruby + Smalltalk community: Smalltalk
has had amazing IDEs for decades, why not Ruby? Smalltalkers, Ruby
needs your help! ....
What is holding Ruby back? How has Smalltalk overcome the issues?
What can Ruby tool builders (such as the RadRails folks and, hopefully,
me) learn from the Smalltalk IDE builders? Reasons I've heard for
Ruby's lack of tool support include:
- Ruby is not a compiled language

The totally interpreted nature of ruby is, IMO, what makes a Smalltalk
kind of IDE plain impossible.

Smalltalk does have interactive read-compile-execute support. But it is
mostly compiled. Classes are compiled in and mostly you add methods and
class at development time, then use them at runtime.
You CAN add a method at runtime (because the compiler itself is an
object in the Smalltalk image). But that's not what you normally do.

Ruby is different. Sure you do have many classes available up front. But
mostly you create your classes at runtime. At EACH run the classes and
methods are recreated.

Here's something to get you thinking:

if ....
def ...

The def is probably adding a method to some class. But is it?
It actually depends on the if condition. That is it depends on runtime.
Maybe the above is within a method. And maybe that method is called 3
times and only after the 3rd call the if condition triggers and a new
method is added to some class.

Now: how's that supposed to be done in a smalltalk like IDE?

You may initially think of adding just the "main" definitions to the
types-database and consider the code above a runtime trick (like it were
a text string passed to smalltalk compiler at runtime).
Except EVERITHING in ruby is like that.
You generally do not intermix class and method definitions with
"executable statements". But that's just an mental abstraction of yours:
class and method definitions, in ruby, ARE executable statements.

Think about it.

 

[Chronos]

class and method definitions, in ruby, ARE executable statements.

Just as they are in Smalltalk.

The problem isn't that Smalltalk has "designed in" the notion of it's
IDE. The problem is that Ruby has "designed in" the notion of a
traditional, file-based IDE, where the world must be recreated de novo
for every reification of a program. That this is the problem is
evident from the fact that nothing about the Smaltalk language, per se,
prevents the use of a "traditional" file-based development paradigm.
GNU Smalltalk is an example.

 

[Huw Collingbourne]

Huw Collingbourne escreveu:

I'm affraid this is one possibility, but not the only one. If we take the
counter example from Python (another 'scripting' language) the IDEs for it
are very capable although its design is fundamentally similar to Ruby.

Can you recommend a good Python IDE? I personally have only used Komodo for
Python (and looked at Iron Python) but if there are better than these I'd
certainly be interested to take a look.

best wishes
Huw Collingbourne
http://www.sapphiresteel.com

 

[gregarican]

For me I have found Komodo sufficient as a Python IDE. For smaller
scale projects it seems to fit the bill. Offhand I recall looking at
Eclipse but it just seemed to resource intensive, slow, etc. I know
other swear by Eclipse but to each their own I suppose.

 

[Cesar Rabak]

Huw Collingbourne escreveu:

Can you recommend a good Python IDE? I personally have only used Komodo for
Python (and looked at Iron Python) but if there are better than these I'd
certainly be interested to take a look.

I never used Komodo, so I can only suggest you give a look (on Windows)
at PythonWin and IDLE.

In the first pay an extra bit of attention on the browser and the
'intelisense' like completion capabilities.

Regards,

 

[zimbatm]

I think that the main difference is that Ruby is not capable of
restoring the parsed source code. When you call ruby on a script it
will be transformed in an AST tree. All the source code comments will
be lost. Reference to the source code is stored but if you have a
Squeak like VM, everything is an eval'ed code.

I've played a little bit with Squeak and it looks like every bit of
information you write is retained. There is also a lot of work involved
in the bytecode on disk storage and restoring which wasn't even
approached in the ruby community. Maybe introdocing a bytecode VM like
YARV will change that status ?

Cheers,
zimbatm

 

[Mc Osten]

I personally have only used Komodo for
Python (and looked at Iron Python) but if there are better than these I'd
certainly be interested to take a look.

Some time ago I used WingIDE. Very good in my opinion. Unfortunately
it's GTK stuff, and that means on MacOS X runs as a X11 application.

Komodo is nice. However, I prefer TextMate. Through snippets and
shortcuts IMHO on an interpreted beast does even better than most IDEs.
Even if I have to admit that RadRails is great.

 

[Chris Uppal]

Smalltalk does have interactive read-compile-execute support. But it is
mostly compiled. Classes are compiled in and mostly you add methods and
class at development time, then use them at runtime.
You CAN add a method at runtime (because the compiler itself is an
object in the Smalltalk image). But that's not what you normally do.

Actually (in most Smalltalks), methods and classes are /always/ added at
runtime -- just as in Ruby.

The difference is that Smalltalk doesn't initialise itself by reading and
executing a sequence of class- and method-creation expressions. The
definitions already existed when your restarted your image. If you define new
classes or methods, /then/ these are compiled at runtime and added to the
image, so that if you save the image, they will be saved too.

It makes Smalltalk /look/ as if it's like (say) C++ -- with a list of classes
and methods which "just exist" and you browse over them in the IDE. But that's
not at all what is actually happening -- what you are browsing are class and
method objects which have been created at various times over the life of the
image, and which have not yet been deleted or overwritten, so they are still
there.

It would certainly be possible to create something similar for Ruby, but first
it would have to have some way of preserving the state of the /entire/
computation between runs.

-- chris

 

[Chris Uppal]

I shout my question to the entire Ruby + Smalltalk community: Smalltalk
has had amazing IDEs for decades, why not Ruby?

Some speculations (note that word well!):

Not many/enough Ruby programmers know what a real execution environment (as
opposed to a mere IDE = editor + debugger + fluff[*]) is like.

Ruby isn't designed to trigger change notifications as methods classes, etc are
redefined (presumably easy to fix).

Ruby is hard to parse. It just comes in undifferentiated files which have to
be executed to set up the runtime environment.

Ruby has no concept of an image, so the evolving state of the system (including
the definitions of classes etc) is not preserved between runs.

Ruby programmers /want/ to write scripts, which they write /then/ run, rather
than work in the Smalltalk way.

People who /do/ want to work in the Smalltalk way use Smalltalk instead of
trying to fix Ruby ;-)

-- chris

("fluff": intellisense, CVS integration, and that kind of thing -- useful but
hardly significant.)

 

[gregarican]

For me I steer away from code completion like the plague. It seems to
get in my way. I guess if you are new to a certain language and using
an IDE I suppose it helps you get familiar with what valid choices you
have in the code. But once you get your feet under you if the IDE can
disable this feature all the better...

 

[Cesar Rabak]

gregarican escreveu:

For me I steer away from code completion like the plague. It seems to
get in my way. I guess if you are new to a certain language and using
an IDE I suppose it helps you get familiar with what valid choices you
have in the code. But once you get your feet under you if the IDE can
disable this feature all the better...

I think in systems like Smalltalk that have 1500+ classes, even if you
have your feet arrmored in steel, you'll always need some help, and
being so, be it in the completion!

 

[listrecv]

I'll add a few points:

* A lot of people shy away when they get to fringe cases, like the if
....; def ...; end ...; end ...; posted earlier. I think it's important
to remember that IDE's are examples of "Good Enough" use cases. I'm
not going to drop my IDE if it misses that fringe case. If you offer
me an IDE which can understand half my code, and help with it - I'll
take it. I'll know that it's not complete, but I'm no worse off with
it than without it.

* There are two basic approaches to getting methods and type info: One
is to run the code in some type of sandbox. The other is to parse it,
and guess. If you just called dog.jump, and classes Canine and Feline
define jump, show all of their methods. Sure, dog may be a Canine and
not a Feline, but if you can't know, it doesn't matter.

* A lot of people like to be dismissive of IDE's, refactoring browsers,
code completion, etc. Then again, a lot of people working on very
large projects site these as the major reason they don't use Ruby.
Personally, I find a text editor the best for short things, but when
I'm going to be working on the same code for several weeks, it's worth
it for me to shell out, buy some extra RAM, and load up an IDE.

 

[Friedrich Dominicus]

Hi all --

I shout my question to the entire Ruby + Smalltalk community: Smalltalk
has had amazing IDEs for decades, why not Ruby? Smalltalkers, Ruby
needs your help!

Are you willing to pay for it?

Regards
Friedrich