3 ms·

In my work, an IDE is beneficial in two main cases. First of all, for someone new to a language or library, auto-complete and instant doc lookup help you figur

by akeefer 18y ago

In my work, an IDE is beneficial in two main cases. First of all, for someone new to a language or library, 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. Secondly, refactoring and find usages is useful if you're working on medium-to-large projects with a large number of people; on a 500k+ codebase there are probably enough methods named "add" that just doing a text search is going to be pretty painful. The average Ruby project is probably a lot smaller than the average Java project because it's far more concise and powerful, which is a good thing and one of the huge advantages of the language. For smaller projects, smaller teams, and expert users, the weight of managing a project in an IDE could outweigh the benefits, so I can see how plenty of people would ignore an IDE in those situations even if it were the best tool in the world, simply because it might get in the way more than it would help. 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. But I can see how there are plenty of development scenarios where even the best IDE would just get in the way, and my judgment is probably just clouded by the fact that my current working scenarios (a few million lines of Java code, 80+ developers, working infrequently enough in Ruby that I forget everything in between) are greatly aided by an IDE. 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. But I'll accept that other people whose work style isn't tailored to using an IDE wouldn't find it as useful.

apotheon 18y ago
> 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: http://osteele.com/archives/2004/11/ides http://osteele.com/archives/2004/11/ides

by akeefer 18y ago

apotheon 18y ago

> 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: http://osteele.com/archives/2004/11/ides http://osteele.com/archives/2004/11/ides