Why is there no Smalltalk-like IDE for Ruby?

[Cesar Rabak]

(e-mail address removed) escreveu:

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

 

[jarober]

In terms of Smalltalk methods?

(e-mail address removed) escreveu:

James,

I hope Bob Nemec is reading this post!

Unfortunately there are more reasons for 'a lot of text editing' than
messing up...

 

[Cesar Rabak]

(e-mail address removed) escreveu:

In terms of Smalltalk methods?

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]

[...] 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).

 

[jussij]

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

(e-mail address removed) escreveu:

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

 

[gregarican]

http://www.klov.com/G/Gorf.html

Um...Good Old Raisins and Fortran?

Jim
--
Jim Menard, (e-mail address removed), 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

 

[bpfurtado]

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.

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]

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.

 

[hanumizzle]

[...] 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?

 

[jussij]

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
http://www.zeusedit.com

 

[Isaac Gouy]

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"


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?


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
http://www.zeusedit.com

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]

(e-mail address removed) escreveu:
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]

Austin Ziegler escreveu:

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.

Interesting declarations. . . let's see if I got it correct:

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]

bpfurtado escreveu:

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.

And to enrich to this discussion, remembering that we can have
implementations that can be not file based...

 

[hanumizzle]

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.