Why is there no Smalltalk-like IDE for Ruby?

[joe]

Are you willing to pay for it?

Absolutely.

 

[zimbatm]

Absolutely.

me too

 

[gregarican]

* 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.

I agree. The reason I wouldn't prefer code completion and most of the
other bells and whistles in a Ruby IDE is perhaps 90% of the time I'm
using it is for smaller scripts where something simple like Scite would
suffice. If I need to track countless classes and methods I've created
and would have a hard time remembering which methods I could apply when
coding then perhaps a comprehensive IDE would help. To me this is the
reason why (as a "fer instance") Java programmers become so dependent
on an IDE. If the environment gets complicated, convoluted, and
ungainly then not using an IDE leaves someone handcuffed.

 

[Michael Voss]

Cesar Rabak wrote:

[...snip...]

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!

[...snip...]

Well, currently working on a Smalltalk system with about 7000 classes, and I
do not miss code completion at all (my IDE doesn't offer it), although I
like it (e. g. in Visual Studio) for statically typed languages. if you need
any information about classes or methods, it's right at your fingertips.
Good browsers are a lot more helpful than code completion.

 

[Michael Voss]

Huw Collingbourne wrote:
[...snip...]

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!)

[...]

Well, yes, but Smalltalk browsers make it very easy to find out what exactly
you changed last week, and to reload the version before. So, since a
Smalltalk developer ist used to have access to every version of every method
he (or someone else) ever saveded, and he will be able to reload any of
these versions without having to bother with something like
checkin/checkout, and since no code will be lost and any code can be
reverted to any prior version, many Smalltalk developers don't care about
that, just a few clicks and the image is back to normal.

 

[listrecv]

me too

As a lot of people are moving their professional development to Ruby,
there will be a lot of "me too's". Ruby used to primarily a
language-of-love, but when it came to business, it wasn't used (except
maybe for scripting). Now, a lot of those fans are moving their
business use to it - at least when they have the ability.

Personally, I'm moving all new consulting projects to Ruby, at least
when I can convince the client of it. Which means that an IDE which
makes me 5% more effecient on large projects is worth thousands to me.

And, like I said, there will be a lot of "me's".

 

[Austin Ziegler]

This is a big difference and it does impact what an IDE would need do to.
The Ruby language requires ruby at the file "require" level. Hence, a Ruby
IDE is not likely to be image-based in quite the same way a Smalltalk IDE is
i.e. save the image and come back later to continue.

Um. Almost. Matz has indicated that #require deals with resources, not
files per se. Right now, these resources map to files. Nothing says
that they have to. It could be a network resource (of which there have
been two implementations) or something else entirely.

-austin

 

[danbernier+ruby]

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.

I love Eclipse for Java, but after getting used to scite and irb, I
can't make myself wait the minute it takes to start up. For Ruby, I
don't need all of Eclipse's features (like code-gen and
auto-refactoring), I think because Ruby gets in my way less. Suppose I
have a class with 5 attributes. In Java, these are private variables,
and I have to provide setters & getters for each of them. In Ruby, I
use attr_reader and attr_writer. If I want to change the name of one,
in Java, it's a pain (unless I have an auto-refactoring tool)...in
Ruby, it's a few lines.

 

[pdavidow]

Can someone please explain what advantage Ruby has over Smalltalk?
Why not just use Smalltalk?

 

[gregarican]

For me personally I find Ruby better suited for quick scripting needs
as opposed to larger scale projects where Smalltalk might be a better
fit. Ruby offers basic OO functionality, is relatively logical with the
way my mind works, and has an active and friendly user community. The
community is a huge selling point, as often asking questions as a
newbie can lead to rude abrupt replies in other programming language
forums.

While I have created larger GUI applications using Ruby (an employee
review survey, wireless handheld CRM app, etc.), most of the time I use
it to whip up something quickly that might take more time an effort to
strip down from a Smalltalk image into a standalone executable. In
terms of quick scripting needs I am talking about SQL query data
exports, text logfile parsing, Win32 OLE app automation, and the like.
Nothing super complicated or high end. But automated scripts that
perhaps save me an hour of day of manual work.

 

[Neil Wilson]

You're probably better off working on the environmental factors.

 

[Claus Dragon]

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!

Have a look here:

http://www.ruby-ide.com/ruby/ruby_ide_and_ruby_editor.php

--
Claus Dragon <[email protected]>
=(UDIC)=
d++ e++ T--
K1!2!3!456!7!S a26
"Coffee is a mocker. So, I am going to mock."

- Me, lately.

 

[hanumizzle]

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.

I beg your pardon; this is a rather specious claim. The lack of a
robust IDE in the vein of Smalltalk for Ruby is a consequence of the
goals and attitudes of the language -- and consequently those of its
community, who furnish both supply and demand for editing and code
production tools, including IDEs. No one can be certain, but it would
seem that most Ruby users prefer to use capable text editors like Vim
and Emacs. (I personally use Emacs 22 from CVS.) Ruby has attracted a
lot of hackers who find its expedience and expressive power greatly
appealing. This crowd, as you might already know, tends to gravitate
towards traditional editors rather than IDEs. Note that Python has
several excellent free IDEs (for those who like them!); it would seem
that Python's fan base is somewhat more diverse, and probably larger
due to Python's age wrt Ruby. The highly regular nature of its syntax
further reinforces the difference between the two. (c.f. Smalltalk,
whose syntax could be described on a postcard, and features some of the
most sophisticated IDEs in the world; and Perl, which seems to have no
major IDEs )

Consider an analogy to human language: Smalltalk is to Ruby as Sanskrit
is to Thai. Yet in either case they are two completely different
languages. Ruby may have inherited much of Smalltalk's object-oriented
wizardry, but it serves a purpose of a wholly different nature.

 

[Huw Collingbourne]

No one can be certain, but it would
seem that most Ruby users prefer to use capable text editors like Vim
and Emacs. (I personally use Emacs 22 from CVS.) Ruby has attracted a
lot of hackers who find its expedience and expressive power greatly
appealing. This crowd, as you might already know, tends to gravitate
towards traditional editors rather than IDEs.

That has possibly been the case up to now. I believe that Ruby is now
attracting the attentions of a new group of developers who expect and
require sophisticated IDEs. Somebody who has hitherto been used to
programming a language such as C#, say, using Visual Studio (or another
integrated environment such as the Borland Developer Studio) probably isn't
going to be hugely enthusiastic about switching to a text editor when
writing Ruby applications.

I have to say that I personally found the poor quality of development tools
to be a huge disincentive when I first began using Ruby. While I agree that
Ruby is a very different beast from Smalltalk and may not lend itself to a
completely Smalltalk-like environment; in my view, it does lend itself very
well to an environment which, at the very least, offers good editing,
debugging, error trapping and code navigation - and I can't really see how
an environment lacking those features offers productivity advantages to a
developer.

I suppose my own prejudice is that Smalltalk 'showed the way forward' and
now, a quarter of a century later, we should be trying to find even better
ways. For me, reverting to a text editor would be like reverting to a time
before Smalltalk. And that just isn't an option.

best wishes
Huw Collingbourne

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

 

[Austin Ziegler]

That has possibly been the case up to now. I believe that Ruby is now
attracting the attentions of a new group of developers who expect and
require sophisticated IDEs. Somebody who has hitherto been used to
programming a language such as C#, say, using Visual Studio (or another
integrated environment such as the Borland Developer Studio) probably isn't
going to be hugely enthusiastic about switching to a text editor when
writing Ruby applications.

Someone who has been programming in C# or Java has *required* something
sophisticated to deal with stupid languages and overengineered and
overlarge libraries.

I have to say that I personally found the poor quality of development tools
to be a huge disincentive when I first began using Ruby. While I agree that
Ruby is a very different beast from Smalltalk and may not lend itself to a
completely Smalltalk-like environment; in my view, it does lend itself very
well to an environment which, at the very least, offers good editing,
debugging, error trapping and code navigation - and I can't really see how
an environment lacking those features offers productivity advantages to a
developer.

Um. The number one thing that IDEs cannot do is provide a good editing
environment. Visual Studio has perhaps the *worst* editor I've ever
used (except maybe notepad), and that's saying something because the
Delphi editor is pretty damned bad, too. The only time that I had
something close to usable in VS is when I tried an extension which gave
me vi-like semantics. Aside from that, I've also found that most IDEs
suck at "code navigation" such that I am faster in vim navigating the
code than I am in VS. This means that for my professional C++ and C#
development, I *edit* and *navigate* in gvim and relegate VS to the
things that it's good for -- building and debugging. And I'm not even
sure it's all that good at building.

I suppose my own prejudice is that Smalltalk 'showed the way forward' and
now, a quarter of a century later, we should be trying to find even better
ways. For me, reverting to a text editor would be like reverting to a time
before Smalltalk. And that just isn't an option.

I think that what you might be missing is that sometimes the "I" part
of an IDE leads to a larger problem than other DEs that are available.
Visual Studio is a perfect example of this: if you *don't* want to work
the VS way, it's painful. Not impossible, but painful. But it makes it
very hard to integrate an editor that may often be much smarter or
better for a developer, or an improved code browser, or ... My
development environment doesn't include just gvim, though -- I also use
Total Commander on Windows. Between those two tools, I have faster and
better editing than most people with VS. I keep VS open (when I'm
developing on Windows) for builds, but I've got a similarly solid --
and arguably easier to use -- development environment on the five
Unix(-like) platforms for which I develop.

-austin

 

[Timothy Goddard]

I've had some interesting experiences with IDEs. I've been using Java
quite a bit recently and find that for strict, statically typed
languages an IDE is completely essential. Java's verbosity requires
that you use a good IDE with built in code assistance utilities (I use
Eclipse).

On the opposite hand, trying to use IDEs like Eclipse's ruby plugin has
been almost completely futile. It isn't simply that the IDEs are
underdeveloped, it's that the language is much more complicated to
predict than languages such as Java or C.

Smalltalk's IDEs deal with this by lugging round a huge mass of extra
information along with the source code. Ruby programmers have learned
to use good techniques for sorting files. Either works, it's simply a
question of taste.

I suppose my own prejudice is that Smalltalk 'showed the way forward' and
now, a quarter of a century later, we should be trying to find even better
ways. For me, reverting to a text editor would be like reverting to a time
before Smalltalk. And that just isn't an option.

No language ever truly 'shows the way forward' in terms of editing
techniques. These are entirely dependent on the type of task to be
performed, as is the choice of language. If I want to write a script to
sort through some files a text editor is the easiest option. If I were
to write a database I would want more sophisticated tools.

Your comment here betrays a rather narrow view. I personally refuse to
identify myself as a 'Ruby programmer', or restrict myself to any one
way of doing things, however much I may like it for my current
purposes. It's very easy to get so used to one way of doing things and
lock ourselves in to one way of thinking. It is essential to remain
flexible, allowing you to cope with anything thrown at you.

 

[Andre Schnoor]

[...] Smalltalk, whose syntax could be described on a postcard, and
features some of the most sophisticated IDEs in the world [...]

Well, that's rather a myth. There's no doubt that refactoring, cross
referencing and live debugging is second to none. BUT .. the source
editor is still lost way back in the 70's. It is *horrible* if one has
to do a lot of text-based editing (search & replace, indent, undo).

I am currently copying the source code into UltraEdit or SciTe, edit it
there and paste it back into the IDE when done! I admit, however, that
this is due to a few very large and unusual methods (defining big
dictionaries).

Andre

 

[Huw Collingbourne]

[...] Smalltalk, whose syntax could be described on a postcard, and
features some of the most sophisticated IDEs in the world [...]

Well, that's rather a myth. There's no doubt that refactoring, cross
referencing and live debugging is second to none. BUT .. the source editor
is still lost way back in the 70's. It is *horrible* if one has to do a
lot of text-based editing (search & replace, indent, undo).

It's worth mentioning that not all implementations of Smalltalk offer the
same editing features. Dolphin Smalltalk, for example (the system I
generally use) has a pretty decent editor with syntax colouring, multi-level
undo, search/replace with regular expressions - even code completion!

best wishes
Huw Collingbourne

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

 

[jarober]

If you have to do a lot of text editing, then you've messed up.

[...] Smalltalk, whose syntax could be described on a postcard, and
features some of the most sophisticated IDEs in the world [...]

Well, that's rather a myth. There's no doubt that refactoring, cross
referencing and live debugging is second to none. BUT .. the source
editor is still lost way back in the 70's. It is *horrible* if one has
to do a lot of text-based editing (search & replace, indent, undo).

I am currently copying the source code into UltraEdit or SciTe, edit it
there and paste it back into the IDE when done! I admit, however, that
this is due to a few very large and unusual methods (defining big
dictionaries).

Andre

 

[Cesar Rabak]

Huw Collingbourne escreveu:

news:[email protected]... [snipped]


I suppose my own prejudice is that Smalltalk 'showed the way forward' and
now, a quarter of a century later, we should be trying to find even better
ways. For me, reverting to a text editor would be like reverting to a time
before Smalltalk. And that just isn't an option.

Huw,

Then the already posed question (in this thread) pertains: "Then why not
program in Smalltalk instead of longing for features that already
exist?" Or in another POV: "What has Ruby that's lacking in Smalltalk?"