Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Umm.. in my personal experience using IntelliJ IDEA for Java and JavaScript code, the refactoring experience is the same.


How could it possibly be? Refactoring a dynamic language will always be more difficult because you never know exactly what an expression refers to.


In Java you have dependency injection, which is fancy name for calling constructors/methods with reflection, depending on some XML file or annotations.

Which makes Java more dynamic at the cost of making it as hard to refactor automatically, as any dynamical language.

The part of code that doesn't use reflection is the part of code, that would be easy to refactor, even if it was written in javascript.


This comment packs a lot of confusion into very few words. You're conflating a factory abstraction like Spring with dependency injection.

void foo(Reader r) { /do stuff with r/ } ... foo(new BufferedReader(new FileReader("/log.txt")));

There, I just did dependency injection without a trace of reflection. Additionally, since everything is statically typed in Java, refactoring is still vastly simpler than with a dynamically typed language. The few spots in the code where you might be trying an invalid type cast are just that - a few spots. Such problems don't permeate the entire codebase as they do with a dynamic language. And I'm saying this as a huge fan of Clojure and Groovy, preferring them over Java on the JVM.

[edit: changed "strongly" to "statically"]


Just try it. I have no complaints when it comes to refactoring any code (Java, Python, JavaScript) with IntelliJ IDEA.

Scala with IDEA was tricky. But then I'm pretty poor with Scala, so it must be me!


If you write the IDE in the language itself, you can use reflection to access, query and manipulate the program's structure directly, while the program is running.


This is theoretically true and I am excited about LightTable but even then, there are many situations where automated refactoring simply isn't possible.

    var decoration = { topmargin: 10, bottommargin: 10 };
    ...
    function setMargin(where, value) {
        decoration[where + "margin"] = value;
    }
    ....
    setMargin("top", 20);


This is a hazard in pretty much any language though. At some point you're going to want to do something dynamic at run time just to get a particular feature to be possible- whether it's by using a built in feature of a language, or by importing an aircraft carrier to do it for you in Java. It's simply Godel's curse- every sufficiently powerful formal system has an escape port. Otherwise known as Greenspun's 10th rule.


Possibly he just uses the most obvious refactorings in the most straightforward js.




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: