> auto-complete and instant doc lookup help you figure out what's available to call and what the various methods and classes do. That's also useful if you only use a particular library occasionally and just don't remember how it works.
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:
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