Why is there no Smalltalk-like IDE for Ruby?
joe
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!
jar...@gmail.com
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
"joe" <joe....@gmail.com> wrote in message
news:1151175804.5...@b68g2000cwa.googlegroups.com...
> 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
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
> 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
> "joe" <joe....@gmail.com> wrote in message
> news:1151175804.5...@b68g2000cwa.googlegroups.com...
>
>>Hi all --
>>
>>I shout my question to the entire Ruby + Smalltalk community: Smalltalk
>>has had amazing IDEs for decades, why not Ruby?
>
>
>
> 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
AnalogFile wrote:
>
> 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
"Cesar Rabak" <csr...@yahoo.com.br> wrote in message
news:e7km4m$pku$1...@nntp.aioe.org...
> Huw Collingbourne escreveu:
>> 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.
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
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
at PythonWin and IDLE.
In the first pay an extra bit of attention on the browser and the
'intelisense' like completion capabilities.
Regards,
--
Cesar Rabak
zimbatm
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.
--
blog: http://www.akropolix.net/rik0/blogs | Uccidete i filosofi,
site: http://www.akropolix.net/rik0/ | tenetevi riso e
forum: http://www.akropolix.net/forum/ | bacchette per voi.
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
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...
itsme213
"Chronos" <alan.l...@gmail.com> wrote in message
> 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.
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.
But a Ruby IDE could, within a given session, offer many of the features of
a Smalltalk IDE. While that session's state is being modified, the IDE could
likely keep track of that state. However, the programmer would be
responsible to reflect all that transient session change in the appropriate
code in his Ruby files (with considerable potential for IDE assistance,
imo).
Cesar Rabak
> 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!
list...@gmail.com
* 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
--
Please remove just-for-news- to reply via e-mail.
joe
> Are you willing to pay for it?
Absolutely.
zimbatm
me too
gregarican
list...@gmail.com wrote:
> * 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
[...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
[...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.
list...@gmail.com
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
> "Chronos" <alan.l...@gmail.com> wrote in message
> > 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.
> 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
danbe...@gmail.com
> 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.
pdav...@gmail.com
Why not just use Smalltalk?
joe wrote:
> 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/
gregarican
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
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 <clau...@mpsahotmail.com>
=(UDIC)=
d++ e++ T--
K1!2!3!456!7!S a26
"Coffee is a mocker. So, I am going to mock."
- Me, lately.
itsme213
"Austin Ziegler" <halos...@gmail.com> wrote in message
>> 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.
We can call it a resource if you like, but the point here is that as long as
something like this is true (call it resource if you prefer), and the
requires can have arbitrary side effects on the state of running Ruby
"image", the meaning of "correct execution" of a Ruby program becomes
dependent on some file-based (ok, resource-based if you prefer)
locate-and-execute behavior. This makes it very difficult for a Ruby IDE to
be image-based in quite the same way a Smalltalk IDE is i.e. save the image
and come back later to continue.
btw, The docs (ri, pickaxe, etc.) all define require in terms of files,
filenames, file extensions, paths, directories...
hanum...@gmail.com
jar...@gmail.com wrote:
> 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
<hanum...@gmail.com> wrote in message
news:1151487334.7...@j72g2000cwa.googlegroups.com...
> 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
> <hanum...@gmail.com> wrote in message
> news:1151487334.7...@j72g2000cwa.googlegroups.com...
> > 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.
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
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.
Huw Collingbourne wrote:
> <hanum...@gmail.com> wrote in message
> news:1151487334.7...@j72g2000cwa.googlegroups.com...
>
<<snip>>
>
> 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
"Andre Schnoor" <andre_INSERT...@web.de> wrote in message
news:4gg0arF...@individual.net...
> hanum...@gmail.com wrote:
>> [...] 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!
jar...@gmail.com
Cesar Rabak
>
> 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?"
Cesar Rabak
> If you have to do a lot of text editing, then you've messed up.
James,
I hope Bob Nemec is reading this post!
Unfortunately there are more reasons for 'a lot of text editing' than
messing up...
jar...@gmail.com
Cesar Rabak
Yes!
You have code, comments, and even with Smalltalk philosophy on having
short methods, still a lot of a few lines of code makes a lot of text!
gregarican
Andre Schnoor wrote:
> [...] still lost way back in the 70's. It is *horrible* if one has
> to do [...]
And WHAT is wrong being lost back in the 70's? My 8-track quadraphonic
tape player is still holding up dandy in my AMC Gremlin X.
Seriously though, probably 80-90% of what I've seen in current
Smalltalk dialects are still rooted in what was defined in Smalltalk-80
over twenty years ago. Is that a bad thing? Not necessarily. Just goes
to show how far ahead of its time it was. A VM? Garbage collection?
I will say cosmetically some of the throwback trappings get a little
stale. Squeak is fun to learn on and play with but the GUI looks a
little GORF-ish (if that's a word).
jus...@zeusedit.com
> * A lot of people like to be dismissive of IDE's, refactoring
> browsers, code completion, etc.
As a 15 year veteran of software development I am amazed how
refactoring appears to be such a must have feature.
I have never worked on a system where massive numbers of name
changes have ever been required. On the rare occasions when a
global change was needed a simple grep of the source code allows
the change to be made within the space of a few minutes.
If such large numbers of changes are in fact needed, this would
suggest to me too much time is being spent coding and too little
time is being spent designing.
> Personally, I find a text editor the best for short things,
Personally I think the text editor is the most important thing.
Having invested many years training my figures to work with a
specific keyboard mapping, they are next to useless in any
editor that does not provide that mapping.
IMHO I would say developers that like IDE's generally also are
happy to code with the mouse, where as developers who work with
their favourite text editor hate the mouse with a passion.
I no that is the case with me ;)
Jussi Jumppanen
Author: Zeus for Windows IDE - http://www.zeusedit.com
Chris Uppal
> Personally I think the text editor is the most important thing.
>
> Having invested many years training my figures to work with a
> specific keyboard mapping, they are next to useless in any
> editor that does not provide that mapping.
[...]
> Author: Zeus for Windows IDE - http://www.zeusedit.com
Maybe the problem is that the authors of text editors rarely provide a way for
them to be used as a /component/ within a larger whole. So the IDE authors
cannot, say, embed vi in the IDE as a/the text editor component because vi
"knows" that it's a top-level program for editing files, never a sub-component
for editing text.
;-)
Just teasing, but I do think that there is /some/ truth in the observation.
-- chris
Cesar Rabak
> list...@gmail.com wrote:
>
>
>>* A lot of people like to be dismissive of IDE's, refactoring
>>browsers, code completion, etc.
>
>
> As a 15 year veteran of software development I am amazed how
> refactoring appears to be such a must have feature.
>
> I have never worked on a system where massive numbers of name
> changes have ever been required. On the rare occasions when a
> global change was needed a simple grep of the source code allows
> the change to be made within the space of a few minutes.
Your experience obviously is restricted to development on file based
sources, right?
>
> If such large numbers of changes are in fact needed, this would
> suggest to me too much time is being spent coding and too little
> time is being spent designing.
>
OK. But once you got a system that needs refactoring, you suggest to
redesign it?
>
>>Personally, I find a text editor the best for short things,
>
>
> Personally I think the text editor is the most important thing.
>
> Having invested many years training my figures to work with a
> specific keyboard mapping, they are next to useless in any
> editor that does not provide that mapping.
>
> IMHO I would say developers that like IDE's generally also are
> happy to code with the mouse, where as developers who work with
> their favourite text editor hate the mouse with a passion.
A counter claim could be done based on the same ad hominen about coding
versus design. . .
OTOH, development today includes GUI design, class diagram production, etc.
Have you lately done any UML diagram just with a text editor?
Jim Menard
> I will say cosmetically some of the throwback trappings get a little
> stale. Squeak is fun to learn on and play with but the GUI looks a
> little GORF-ish (if that's a word).
Um...Good Old Raisins and Fortran?
Jim
--
Jim Menard, ji...@io.com, http://www.io.com/~jimm/
"The reason why there is no good commercial Java develoment environment
is that the only folks that are good enough to write one all use EMACS."
-- Unknown, on comp.lang.java.programmer
gregarican
bpfu...@gmail.com
It's a few lines only the declaration of this attributes and its
acessor methods, but the true power of this kind of refactoring is to
trace the usage (invokation) of this methods a make the rename in this
places too. Without a refatoring tool you'd have this problem in Ruby
too.
bpfurtado
jus...@zeusedit.com wrote:
> I have never worked on a system where massive numbers of name
> changes have ever been required. On the rare occasions when a
> global change was needed a simple grep of the source code allows
> the change to be made within the space of a few minutes.
>
> If such large numbers of changes are in fact needed, this would
> suggest to me too much time is being spent coding and too little
> time is being spent designing.
>
Agile Modeling techniques requires constant refactorings, and not so
much as but still requiring we have the Interactive way (proposed by
RUP and UP). And certainly the 'waterfall' process is not the way...
IMHO refactorings are necessary.
hanum...@gmail.com
Andre Schnoor wrote:
> hanum...@gmail.com wrote:
> > [...] 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 second that. But this is nothing related to an intrinsic property of
Smalltalk. Refactoring, cross referencing, and live debugging all
depend on Smalltalk's dynamic nature and simple syntax. On the plus
side, I think VW has a parcel for Emacs-like behavior. MagicKeys was it?
jus...@zeusedit.com
> OK. But once you got a system that needs refactoring,
But this is the question. In what situation does a system
require such major code change?
Most "big systems" I have worked only go through incremental
changes. These systems tend to have code that old it has not
changed in decades.
And this is for good reason. These a mission critical system
which adopt the time tested adage:
"If it ain't broke don't fix it"
> you suggest to redesign it?
Are you saying there can have a situation where major code
change is required yet none of these code changes impact
on the design?
I would have though major code change would required
some sort of major redesign.
If this is not the case then why bother with a design in the
first place. Why not just start coding?
> Have you lately done any UML diagram just with a text editor?
Why not use a UML specific tool?
Does a builder have nothing but a hammer? No, he will have
a toolbox full of tools.
Why is any different for a software developer? The text editor
is just one tool in the software developer toolbox.
Jussi Jumppanen
Author: Zeus for Windows IDE
Isaac Gouy
The essential thing about refactoring is that it's behaviour
preserving. The fun thing about some refactoring tools is that you can
use them to change behaviour.
"Instead of performing many small transformations, we used the
facilities in Brant and Roberts' Smalltalk Refactoring Browser to make
more significant program transformations by defining our own program
transformation rules.
This allowed us to systematically make 17,200 changes almost bug free."
Transformation of an Application Data Layer
http://oopsla.acm.org/extra/pracreports/TransformDataLayerReport.pdf
Austin Ziegler
> It's a few lines only the declaration of this attributes and its
> acessor methods, but the true power of this kind of refactoring is to
> trace the usage (invokation) of this methods a make the rename in this
> places too. Without a refatoring tool you'd have this problem in Ruby
> too.
Really? You mean your code isn't well-encapsulated enough to be able to
understand this with simple grep or find/grep?
-austin
Austin Ziegler
> jus...@zeusedit.com escreveu:
> > IMHO I would say developers that like IDE's generally also are
> > happy to code with the mouse, where as developers who work with
> > their favourite text editor hate the mouse with a passion.
> A counter claim could be done based on the same ad hominen about coding
> versus design. . .
>
> OTOH, development today includes GUI design, class diagram production, etc.
>
> Have you lately done any UML diagram just with a text editor?
Do you know how many UML diagrams I've needed in my current (C++) job
where we've done some rather *serious* reengineering of our code
lately?
None.
I've needed some pictures to show interactions from time to time, but
those have all been on whiteboards.
IOW, there's something wrong when your development process *requires*
UML diagrams.
bpfurtado
> Really? You mean your code isn't well-encapsulated enough to be able to
> understand this with simple grep or find/grep?
>
> -austin
Encapsulation is not related to the usage of public operations of a
class. You can have a very well defined class, generic enough to be
used by a lot of other classes, with all its internal state or even
concrete class (if you use the right available interfaces) hidden from
its users.
No "grep or find/grep" can be faster than a Alt+Shift+R => Dialog
window with a TextField to the new name.
Cesar Rabak
1) You claim your experience show no need for designing using UML or
other OO modeling language;
2) Further, you affirm a development *process* that requires it so has
something wrong;
3) and some pictures can be used here and there in an informal way, but
can be discarded so will not be used for documentation, etc.
And specially in a project done in a so self documenting and clear
syntax like C++?
Cesar Rabak
implementations that can be not file based...
hanum...@gmail.com
Friedrich Dominicus wrote:
> "joe" <joe....@gmail.com> writes:
>
> > 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?
There is no such thing as free, so the distinction between paying and
not paying does not exist. With FOSS, the price is community effort,
including effort by the user.
Ron Jeffries
There's an issue that I think is more significant, which is that Smalltalk's
model is that all the classes and objects are there, all the time, in the image.
Ruby's model is that the classes are NOT there, but are brought in (via require)
only when the need is explicitly expressed in the source code.
As such, a Smalltalk-style experience is very difficult to produce. Chet
Hendrickson and I tried, and while we're not the best in the world, we're good
enough to be sure it's difficult.
I'd love to see someone do it, but it's not going to be easy, in my opinion.
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
itsme213
"Ron Jeffries" <ronje...@acm.org> wrote in message
> There's an issue that I think is more significant, which is that
> Smalltalk's
> model is that all the classes and objects are there, all the time, in the
> image.
> Ruby's model is that the classes are NOT there, but are brought in (via
> require)
> only when the need is explicitly expressed in the source code.
Monticello, the distributed package and version manager for Squeak, is a
very interesting halfway point. A Monticello package is *not* an image of
all classs and objects in some (possibly transient) state. Rather, it is
composed of a collection of classes and methods with explicitly represented
dependencies and initialization expressions.
Like a restricted Ruby "require" of a composite-collection of restricted
Ruby files.
For some things, like package management and distribution, Smalltalk needs
more. But it does not have to be at the granularity of a typical Ruby
required file. Monticello seems to hit a sweet spot (just started reading up
on it, really like it so far!). Wonder if its model can be compared in any
useful way to to gems.
One approximation to this with a Ruby IDE would be:
(1) Within a given session behave like a Smalltalk IDE (track objects,
classes, methods, etc.)
(2) At session boundaries, offer interactive tool help so the programmer can
reflect all that transient session change in the appropriate code in his
Ruby files.
There would likely have to be style restrictions on those Ruby files, just
as Monticello distills a package down to a declarative and explicit
structure of a set of classes, methods, relationships, and initializations.
Timothy Goddard
perfectly legal code if you fill in the class contents:
class ClassA
...
end
class ClassB
...
end
def switch_classes
ClassA, ClassB = ClassB, ClassA
end
Good luck getting an IDE to track the state of this. Ruby is simply too
dynamic a language to be modelled effectively without executing it.
llothar
Timothy Goddard wrote:
> Note that in Ruby a 'constant' is not actually constant. This is
> perfectly legal code if you fill in the class contents:
>
> class ClassA
> ...
> end
>
> class ClassB
> ...
> end
>
> def switch_classes
> ClassA, ClassB = ClassB, ClassA
> end
>
> Good luck getting an IDE to track the state of this. Ruby is simply too
> dynamic a language to be modelled effectively without executing it.
Well this belongs to the things i would forbid by style guides in an
Smalltalk-like-Ruby.
It's not that much a problem if it is done in existing library code
where everything the IDE must know is that it needs to do a "require
'library' "