Newbie question from a smalltalker

[Adriano_Volpones]

Dear all,

I am a seasoned Smalltalk developer and I’m playing with Ruby which I found
the best script language in the spirit of Smalltalk.

What I cannot find in it is the entire world of programming and refactoring
tools that are for long time available in every Smalltalk environment.

For example the simple list of “implementors” and “senders” of a method is
invaluable when the project begins to grow up to hundreds of classes.

The value of a language is in it’s “elegance” but in a day-by-day work the
tools for the programmers are of the same or greater interest.

Am I wrong in something about the use of Ruby ?

Could some one else explain to me the management of medium and large size of
projects in Ruby ?.

Tnx,

Adriano

[Lyle_Johnson6 (Lyle Johnson)]

Adriano Volpones wrote:

I am a seasoned Smalltalk developer and I’m playing with Ruby which I found
the best script language in the spirit of Smalltalk.

What I cannot find in it is the entire world of programming and refactoring
tools that are for long time available in every Smalltalk environment.

For example the simple list of “implementors” and “senders” of a method is
invaluable when the project begins to grow up to hundreds of classes.

The value of a language is in it’s “elegance” but in a day-by-day work the
tools for the programmers are of the same or greater interest.

Am I wrong in something about the use of Ruby?

I will be interested to see some of the other replies to your questions,
but I think the answer is that there aren’t any tools (for Ruby) quite
like what you’re describing.

Refactoring tools, as well as tools to extract lists of method
implementors/senders, must rely on some kind of “database” of all of the
known classes. From what little I know about Smalltalk, this is a
central concept in the Smalltalk development environment. There is no
such concept in Ruby (or any other programming language that I’ve worked
with).

The closest thing we have for this in Ruby is the FreeRIDE project,
which is building an IDE for Ruby development. One of the long-term
goals is to be able to provide support for tools like refactoring. But I
think that’s probably still a ways off.

[Mark_Wilson]

I hope that you can put together a list of the tools you would like to
see in Ruby from your perspective based on experience with Smalltalk.

It should be possible to create a list of implementors and senders of a
method using the ObjectSpace module and each object’s built-in
introspection methods (class, respond_to?, methods,
methods.include?(), etc.).

Regards,

Mark

···

On Wednesday, August 6, 2003, at 09:02 AM, Adriano Volpones wrote:

Dear all,

I am a seasoned Smalltalk developer and I’m playing with Ruby which I
found
the best script language in the spirit of Smalltalk.

What I cannot find in it is the entire world of programming and
refactoring
tools that are for long time available in every Smalltalk environment.

For example the simple list of “implementors” and “senders” of a
method is
invaluable when the project begins to grow up to hundreds of classes.
[snip]

[Gavin_Sinclair]

I’d like to read about how the Smalltalk environment fits together
like this. All I know is the joke about it having an image problem.

IntelliJ and Eclipse both do a brilliant job at code refactoring and
navigation for Java - probably as good as any Smalltalk environment.
However, if an add-on can do this for Java (whose static typing makes
it possible), yet it can also somehow be done for non-statically-typed
Smalltalk, then there’s hope for Ruby. I suspect the Ruby-in-Ruby
interpreter is the key.

Gavin

···

On Wednesday, August 6, 2003, 11:22:21 PM, Lyle wrote:

[…]
Refactoring tools, as well as tools to extract lists of method
implementors/senders, must rely on some kind of “database” of all of the
known classes. From what little I know about Smalltalk, this is a
central concept in the Smalltalk development environment. There is no
such concept in Ruby (or any other programming language that I’ve worked
with).

[Robert]

“Mark Wilson” mwilson13@cox.net schrieb im Newsbeitrag
news:5DE47352-C818-11D7-93B4-000393876156@cox.net…

Dear all,

I am a seasoned Smalltalk developer and I’m playing with Ruby which I
found
the best script language in the spirit of Smalltalk.

What I cannot find in it is the entire world of programming and
refactoring
tools that are for long time available in every Smalltalk environment.

For example the simple list of “implementors” and “senders” of a
method is
invaluable when the project begins to grow up to hundreds of classes.
[snip]

I hope that you can put together a list of the tools you would like to
see in Ruby from your perspective based on experience with Smalltalk.

It should be possible to create a list of implementors and senders of a
method using the ObjectSpace module and each object’s built-in
introspection methods (class, respond_to?, methods,
methods.include?(), etc.).

Yep, apart from the fact that you won’t find the senders - which is a
quite important thing to know. The closes you can get is a script that
wades through the sources and prints out all occurrences of "<any

."; you would only miss those cases where some
instance invokes the method on itself - but these are easy to find anyway.

Other than that it’ll be difficult because of the dynamic typing of the
language. You can’t determine from “foo.size()” whether it’s the size
method of class Array or String - which is a bit of a difference.

Regards

robert

Just some code to play with in IRB:

def implementors(sym, type=nil)
sym = sym.intern if sym.kind_of? String

if type.nil?
ObjectSpace.each_object() do |obj|
p obj if obj.respond_to? sym
end
else
ObjectSpace.each_object( type ) do |obj|
case type
when Class, Module
begin
inst = obj.new
p obj if inst.respond_to? sym
rescue
# ignore
end
else
p obj if obj.respond_to? sym
end
end
end
end

···

On Wednesday, August 6, 2003, at 09:02 AM, Adriano Volpones wrote:

[Wsdng]

The main strenght of Smalltalk IDEs are the debugging features.

In a Smalltalk IDE every unhandled exception opens the debugger. The
debugger works on a copy of the actual stack including every context
information you might need. You have to have a very close look at the
code to recognise that the stack is only a copy. In fact you are able
to change every single aspect of the stack and restart execution of
the stack at every position you want.

This changes the way of programming completely because it supports one
of the key postulations of eXtreme programming: Test first. You write
the test, let it fail and do the complete programming in the debugger.
The end of the process is a running testcase.

It’s very hard to explain. You’ll need to look over the shoulder of an
an experienced Smalltalker to get a glimpse of what is possible!

The obvious way to have similar features in a ruby IDE would be the
Ruby in Ruby approach. But you don’t need to go that far. The key
feature for such an “image based” IDE is some kind of Binary Object
Storage. Store the state of IRB and you got a handy bootstrap for
creating everything you need.

I like Ruby very much and I would be very happy to see anything
similar in Ruby but to be honest: If I need a powerful debugging IDE
I’m better off with Smalltalk.

Cheers
Sascha

···

Mark Wilson mwilson13@cox.net wrote:

I hope that you can put together a list of the tools you would like to
see in Ruby from your perspective based on experience with Smalltalk.

[Lyle_Johnson6 (Lyle Johnson)]

Gavin Sinclair wrote:

I’d like to read about how the Smalltalk environment fits together
like this. All I know is the joke about it having an image problem.

I’ve only played around with Squeak Smalltalk, but I assume that all of
the Smalltalk environments follow the same basic approach. All of your
code – everything – exists inside the core Smalltalk “image” that you
referred to. When you start up Smalltalk, this image is loaded into
memory. As you make changes (i.e. adding and removing classes or
methods) the image is updated. At any time, you can identify (for
example) all of the classes that implement the “foo” method, because
they’re all right there. When you shut down Smalltalk, the image is
saved back to disk.

It’s a very interesting approach, and different from any other
programming environment I’ve worked with.

IntelliJ and Eclipse both do a brilliant job at code refactoring and
navigation for Java - probably as good as any Smalltalk environment.
However, if an add-on can do this for Java (whose static typing makes
it possible), yet it can also somehow be done for non-statically-typed
Smalltalk, then there’s hope for Ruby. I suspect the Ruby-in-Ruby
interpreter is the key.

You may be right. I haven’t used IntelliJ or Eclipse either, but I’m
assuming that they work with a project-based approach, where a “project”
is a collection of a particular set of source files and build a database
of classes and methods based on those. And we’d need to do something
similar for Ruby.

[David_A_Black2 (David A. Black)]

Hi –

···

On Thu, 7 Aug 2003, Robert Klemme wrote:

sym = sym.intern if sym.kind_of? String

Just a quick 1.8.0-only enhancement:

sym = sym.to_sym

David

–
David Alan Black
home: dblack@superlink.net
work: blackdav@shu.edu
Web: http://pirate.shu.edu/~blackdav

[Ben_Giddings]

For what it’s worth, I think a tool that could do what Adriano’s asking for
would be incredibly useful, if only as a learning tool. Years and years ago,
when I was first learning Java, I had a copy of the first edition of Java in
a Nutshell. One of the best features of the book were some indices at the
back that listed (in dead-tree format) exactly this sort of information. If
I remember correctly, they might have even had an index of where certain
classes were used as function parameters.

What made this great as a learning tool was that you could easily find
examples of how a certain function was used, or quickly find all the
different IO classes that could do what you were trying to do.

Sometime I’ll have to get around to playing with Smalltalk and see how it
works there.

Ben

···

On Wed August 6 2003 11:02 am, Robert Klemme wrote:

Yep, apart from the fact that you won’t find the senders - which is a
quite important thing to know. The closes you can get is a script that
wades through the sources and prints out all occurrences of "<any

."; you would only miss those cases where some
instance invokes the method on itself - but these are easy to find anyway.

Other than that it’ll be difficult because of the dynamic typing of the
language. You can’t determine from “foo.size()” whether it’s the size
method of class Array or String - which is a bit of a difference.

[Dave_Mail_Archive]

Lyle Johnson wrote:

You may be right. I haven’t used IntelliJ or Eclipse either, but I’m
assuming that they work with a project-based approach, where a
“project” is a collection of a particular set of source files and
build a database of classes and methods based on those. And we’d need
to do something similar for Ruby.

I agree that IDEs are a great environment for some folks. But just for
balance I’d point out that it’s possible to write decent sized
applications without a class browser and refactoring tools. My biggest
Ruby app so far has 460 classes, and when I need to refactor a method
name I find “grep-find” very usable.

Cheers

Dave

[Wsdng]

Ben Giddings ben@thingmagic.com wrote in message news:200308061159.53695.ben@thingmagic.com…

Yep, apart from the fact that you won’t find the senders - which is a
quite important thing to know. The closes you can get is a script that
wades through the sources and prints out all occurrences of "<any

."; you would only miss those cases where some
instance invokes the method on itself - but these are easy to find anyway.

Other than that it’ll be difficult because of the dynamic typing of the
language. You can’t determine from “foo.size()” whether it’s the size
method of class Array or String - which is a bit of a difference.

For what it’s worth, I think a tool that could do what Adriano’s asking for
would be incredibly useful, if only as a learning tool. Years and years ago,
when I was first learning Java, I had a copy of the first edition of Java in
a Nutshell. One of the best features of the book were some indices at the
back that listed (in dead-tree format) exactly this sort of information. If
I remember correctly, they might have even had an index of where certain
classes were used as function parameters.

What made this great as a learning tool was that you could easily find
examples of how a certain function was used, or quickly find all the
different IO classes that could do what you were trying to do.

Sometime I’ll have to get around to playing with Smalltalk and see how it
works there.

If you do so, have a look at the RefactoringBrowser, Smalllint and the
RewriteTool:
http://st-www.cs.uiuc.edu/~brant/Refactory/Rewrite/index.htm

You’ll notice that these tools do a lot more than simply find senders
or implementors. They find some kind of parse tree patterns and allow
advanced analysis and replacement based on these patterns.

Cheers
Sascha

···

On Wed August 6 2003 11:02 am, Robert Klemme wrote:

[Adriano_Volpones]

Dave Thomas wrote:

I agree that IDEs are a great environment for some folks. But just for
balance I’d point out that it’s possible to write decent sized
applications without a class browser and refactoring tools. My biggest
Ruby app so far has 460 classes, and when I need to refactor a method
name I find “grep-find” very usable.

You are right! You can always emulate every tool and bell and whistle with
lots of grep+find+cut+paste+… is only a matter of time.

What I can say is that (for me) the real fun in programming comes from
designing and not from typing, where the last is a mere obstacle to obtain
the first.

Adriano

[Michael_Garriss1 (Michael Garriss)]

Dave Thomas wrote:

Lyle Johnson wrote:

You may be right. I haven’t used IntelliJ or Eclipse either, but I’m
assuming that they work with a project-based approach, where a
“project” is a collection of a particular set of source files and
build a database of classes and methods based on those. And we’d need
to do something similar for Ruby.

I agree that IDEs are a great environment for some folks. But just for
balance I’d point out that it’s possible to write decent sized
applications without a class browser and refactoring tools. My biggest
Ruby app so far has 460 classes, and when I need to refactor a method
name I find “grep-find” very usable.

Cheers

Dave

Although I can’t test it in my current enviroment, I believe that ctags
works on ruby too. Sure it’s a bit dumb (ctags) but combined with vim
or emacs it can be quite useful.

Michael Garriss

[Dave_Mail_Archive]

Adriano Volpones wrote:

Dave Thomas wrote:

I agree that IDEs are a great environment for some folks. But just for
balance I’d point out that it’s possible to write decent sized
applications without a class browser and refactoring tools. My biggest
Ruby app so far has 460 classes, and when I need to refactor a method
name I find “grep-find” very usable.

You are right! You can always emulate every tool and bell and whistle with
lots of grep+find+cut+paste+… is only a matter of time.

What I can say is that (for me) the real fun in programming comes from
designing and not from typing, where the last is a mere obstacle to obtain
the first.

Design? Where’s the productivity is design? You’re only working when
you’re typing, so the more you do, the harder you’re working.

[Lyle_Johnson4 (Lyle Johnson)]

Michael Garriss wrote:

Although I can’t test it in my current enviroment, I believe that ctags
works on ruby too. Sure it’s a bit dumb (ctags) but combined with vim
or emacs it can be quite useful.

Actually, I can confirm it I use the CodeBrowser (I think that’s its
name) plugin for JEdit and it uses ctags under the hood to generate the
list of classes, methods etc. for the current file. Works pretty well
for Ruby, although the method names are not fully-qualified (i.e. no
distinction between “A::foo” and “B::foo”, both appear as “foo”). Not
sure if this latter problem is a defect of ctags or of CodeBrowser’s use
of the ctags file information.

[Mark_Wilson]

One thing Ruby offers here is an excellent unit testing framework.
First, you type (as in typing, not data type) your test and then you
write the code. Then repeat.

As it happens, depending on your level of familiarity with Ruby and the
clarity of your perception of the problem you are trying to solve,
typing a test that fails can be very non-trivial – then implementing
the method can feel like bicycling downhill.

Regards,

Mark

···

On Wednesday, August 6, 2003, at 11:22 AM, Adriano Volpones wrote:

[snip]

What I can say is that (for me) the real fun in programming comes from
designing and not from typing, where the last is a mere obstacle to
obtain
the first.
[snip]

[Brett_H_Williams]

Yikes! Maybe you can define working harder as more typing, but I don’t see
that as productivity!

Design leads to productivity because you don’t have to retype things you
didn’t plan carefully.

···

On Aug 7, Dave Thomas wrote:

Design? Where’s the productivity is design? You’re only working when
you’re typing, so the more you do, the harder you’re working.

[HAL_9000]

What I can say is that (for me) the real fun in programming comes from
designing and not from typing, where the last is a mere obstacle to
obtain
the first.

Design? Where’s the productivity is design? You’re only working when
you’re typing, so the more you do, the harder you’re working.

post.append(“:)”)

…right?

Hal

···

----- Original Message -----
From: “Dave Thomas” dave@pragprog.com
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Wednesday, August 06, 2003 10:55 AM
Subject: Re: newbie question from a smalltalker

[Wesley_J_Landaker]

Apparently, Dave Thomas recently wrote:

What I can say is that (for me) the real fun in programming comes from
designing and not from typing, where the last is a mere obstacle to
obtain the first.

Design? Where’s the productivity is design? You’re only working when
you’re typing, so the more you do, the harder you’re working.

Wow, this is a good idea! I can just see it: you hook up a little device
to the keyboards of your employees that is wired to a lightblub on top of
their monitors. Every time they press a key, it increments a counter, and
every time some determined amount of time passes, say, a few seconds, the
counter is decremented… then, the lightblub is hooked up so that it is
as bright as the counter is large.

This way, if a employee is typing a lot, the lightbulb will be very
bright, but if they stop for more than a few seconds, it will start to get
dimmer and dimmer until it finally goes off, which would take, say, a
minute.

Yeah, this is great! So now all the boss has to do is walk around and look
at people’s lightbulb and he’ll know who to go have a little talk with, to
let them know that they are “not pressing enough keys”, and thus not
working hard enough.

OH! Better yet! The wires for the lightbulbs could run into a big back
room and be hooked up in a grid… yeah, and someone could sit and monitor
them and when they start to go dim, the person monitoring would do
something… like… yes! good idea! press a button that gives the person
with a dim lightbulb an ELECTRIC SHOCK!!! Sweet!

… I think I’m going to go implement this right now. (Maybe I could write
the lightbulb interface in Ruby?)

Wes

[Michael_Garriss1 (Michael Garriss)]

Lyle Johnson wrote:

Michael Garriss wrote:

Although I can’t test it in my current enviroment, I believe that
ctags works on ruby too. Sure it’s a bit dumb (ctags) but combined
with vim or emacs it can be quite useful.

Actually, I can confirm it I use the CodeBrowser (I think that’s
its name) plugin for JEdit and it uses ctags under the hood to
generate the list of classes, methods etc. for the current file. Works
pretty well for Ruby, although the method names are not
fully-qualified (i.e. no distinction between “A::foo” and “B::foo”,
both appear as “foo”). Not sure if this latter problem is a defect of
ctags or of CodeBrowser’s use of the ctags file information.

Yea…If I remember right, ctags was much better at some languages then
if was at others. I believe there is a version of ctags out there that
is open source. It would be interesting to rewrite it in ruby and then
add on the power of rubyish things…like ObjectSpace. If it produced
output in the same format as ctags it would still plug-in to 3rd-party
tools.