4 ms·

You need an IDE in Ruby just as much as in Java. It's the easiest way to browse the code, navigate from place to place, get some auto completion and auto import

You need an IDE in Ruby just as much as in Java. It's the easiest way to browse the code, navigate from place to place, get some auto completion and auto imports, etc... Of course, Ruby being dynamically typed makes it impossible to have most of the refactorings that statically typed languages take for granted, but that's a separate topic. Look at it this way: you might think you are productive with Emacs/TextMate/vi, but you would be even more productive with an IDE of the Eclipse or IDEA caliber. An IDE is nevery mandatory, it just makes you more productive.

ekiru 16y ago
"Of course, Ruby being dynamically typed makes it impossible to have most of the refactorings that statically typed languages take for granted, but that's a separate topic." Most of the refactoring tools that Java IDEs have originated in Smalltalk, an extremely dynamic language.
- billmcneale 16y ago
  Most of these refactorings required human intervention, even for simple refactorings like "Rename". When the IDE doesn't have types, some refactorings are simply impossible to perform automatically. For more details and examples: http://beust.com/weblog/2006/10/01/dynamic-language-refactoring-ide-pick-one/ http://beust.com/weblog/2006/10/01/dynamic-language-refactor...
  - ekiru 16y ago
    The arguments in your linked article are inaccurate. For example: the Refactoring Browser described in "A Refactoring Tool for Smalltalk"(at http://st-www.cs.uiuc.edu/users/droberts/tapos.pdf http://st-www.cs.uiuc.edu/users/droberts/tapos.pdf ), was capable of determining which sends of a renamed message were to the class on which it is to be renamed by analysis of the program's dynamic behavior. There's of course a limitation on this. To quote the paper: "The major drawback to this style of refac- toring is that the analysis is only as good as your test suite. If there are pieces of code that are not executed, they will never be analyzed, and the refactoring will not be completed for that par- ticular section of code. "
    - billmcneale 16y ago
      The impracticality of this technique notwithstanding, the article is perfectly accurate based on your own summary: in a dynamically typed languages, automatic refactorings are never 100% safe.

ekiru 16y ago

"Of course, Ruby being dynamically typed makes it impossible to have most of the refactorings that statically typed languages take for granted, but that's a separate topic." Most of the refactoring tools that Java IDEs have originated in Smalltalk, an extremely dynamic language.

billmcneale 16y ago
Most of these refactorings required human intervention, even for simple refactorings like "Rename". When the IDE doesn't have types, some refactorings are simply impossible to perform automatically. For more details and examples: http://beust.com/weblog/2006/10/01/dynamic-language-refactoring-ide-pick-one/ http://beust.com/weblog/2006/10/01/dynamic-language-refactor...
- ekiru 16y ago
  The arguments in your linked article are inaccurate. For example: the Refactoring Browser described in "A Refactoring Tool for Smalltalk"(at http://st-www.cs.uiuc.edu/users/droberts/tapos.pdf http://st-www.cs.uiuc.edu/users/droberts/tapos.pdf ), was capable of determining which sends of a renamed message were to the class on which it is to be renamed by analysis of the program's dynamic behavior. There's of course a limitation on this. To quote the paper: "The major drawback to this style of refac- toring is that the analysis is only as good as your test suite. If there are pieces of code that are not executed, they will never be analyzed, and the refactoring will not be completed for that par- ticular section of code. "
  - billmcneale 16y ago
    The impracticality of this technique notwithstanding, the article is perfectly accurate based on your own summary: in a dynamically typed languages, automatic refactorings are never 100% safe.