Of course MS Windows is better It has Visual Studio

Translation:

"I think Ruby is a fantastic language, except that it can't be used effectively with an IDE as good as VS, which is a glaring flaw in the language."

My point:

"I think Ruby is a fantastic language, and the fact it may not be usable with an IDE like VS is not a flaw -- it is the result of design decisions based on a different approach to programming than that mandated by use of a VS-like IDE."

> If there was an IDE for Ruby that reliably did refactorings like "rename method"

That sort of thing is trivially accomplished by very simple tools that are present in every full Unix environment implementation. You don't need an IDE for that. The same is true for other IDE features you mentioned. I don't need all that stuff integrated into a single monolithic application to be able to use them effectively.

> To me the author is incorrect in essentially arguing that people don't use IDEs with Ruby because they're too limiting

They're too limiting for Ruby.

> IDEs for Ruby aren't good enough to make it worthwhile to deal with those limitations

More accurately, what an IDE provides over the tools people tend to use with Ruby isn't enough to offset the limitations, because what an IDE provides is for the most part superfluous for Ruby, and the IDE way of approaching programming isn't very compatible with the characteristics of the language that make common IDE "benefits" superfluous.

It seems our main point of disagreement is something like this:

1. You think the fact Ruby doesn't have good IDEs is that it's designed in a way that prevents it from benefiting from them, because it just wasn't planned out well enough to take advantage of IDEs. As a result, Ruby will always lack the benefits of IDEs.

2. I think the fact Ruby doesn't have good IDEs is that it's designed in a way that ensures it doesn't need IDEs, and IDE functionality wouldn't really be a benefit because it's superfluous to a language like Ruby. As a result, Ruby will never need the benefits of IDEs. Instead, it's more geared to taking advantage of the benefits of powerful text processing applications like Vim and Emacs.

Lucky for me, I can have those things with languages like Perl and Ruby without having to resort to an IDE.

> on a 500k+ codebase there are probably enough methods named "add" that just doing a text search is going to be pretty painful.

The kind of tools you describe as being better than a text search are, in essence, just text search (and replace) tools. They're obviously much more powerful than the search and replace tools familiar to many MS Windows users thanks to the style of search functionality offered with editors like Notepad, Wordpad, and even MS Word -- but then again, so are the search tools available in a typical Unix environment, especially when using an editor like Vim or Emacs.

> I think that there are other situations, primarily for working on larger projects but also for people new to the language or who use it less frequently, where the benefits of a really good IDE would still help out Ruby.

I think that applies more for people who are used to an IDE approach to programming, really. The kind of development done with Ruby without an IDE near at hand actually uses a very different approach to development than an IDE-centric approach, and for someone used to that IDE-centric approach, having an IDE to help make the transition might be very helpful.

Maybe an IDE for Ruby will eventually be a clear win, but before that happens I think a whole new set of IDE features will have to be invented -- features that are both necessary and otherwise rare for tools suited to developing in Ruby. In other words, IDEs as they currently exist probably won't ever cut it as the best way to develop for a language like Ruby, even if the dynamic nature of the language can be accounted for to make the current common IDE features work with it where they don't already.

> So personally my work style is now tailored to using an IDE, which slows me down when I have to shift out of that mode, and I'd use a great Ruby IDE instead of Emacs if one were available.

That makes sense. As Oliver Steele pointed out in "The IDE Divide", language-centric and IDE-centric approaches to development are almost mutually exclusive in a way that supports the idea that for some people, IDE-oriented languages coupled with excellent IDEs are more productive, while for others, languages that (currently) are not well-suited to IDEs because IDEs that interact well with their more powerful capabilities are the more productive choice.

I'm not sure I buy Steele's reasoning, exactly, but he makes some excellent points about the difference in development approaches between IDE-centric developers (what he calls "tool mavens") and language-centric developers (what he calls "language mavens").

Err, the URL, in case that sounds like a topic of interest:

http://osteele.com/archives/2004/11/ides