I watched the video. Just to clarify, his argument is that it's hard to refactor...

pixie_ · on June 4, 2012

Definitely agree with this. I've re factored large C# apps, moving thousands of lines of code into different places and have had it up and running again very quickly with no bugs.

Contrast this to refactoring huge javascript or python programs because the compiler isn't going to check if what you refactored 'fits' into the place you put it. It's always very nerve racking for me when refactoring large pieces of javascript or python because even if it runs, often many bugs remain lurking that won't be found out until the unit tests are re-written.

factorialboy · on June 4, 2012

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

cachehit · on June 4, 2012

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

ajuc · on June 4, 2012

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.

h_r · on June 4, 2012

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"]

factorialboy · on June 4, 2012

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!

ZenPsycho · on June 4, 2012

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.

cachehit · on June 4, 2012

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);

ZenPsycho · on June 5, 2012

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.

batista · on June 4, 2012

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

masklinn · on June 4, 2012

> In other words, it's likely that large web-applications written in javascript will be having difficulties to innovate.

Do you mean "iterate"? Because refactoring has little link to innovation.

Chris_Newton · on June 4, 2012

Because refactoring has little link to innovation.

What about rapid prototyping? Perhaps the biggest strength of the lighter, more dynamic languages is that they require much less work to play around with ideas in the early days. On the other hand, if you can’t then tidy up the code that sticks, to make it into something that is more systematic and maintainable over the long term, you’re either going to waste effort rewriting it or you’re going to take on ever-increasing levels of technical debt, and either way your progress will be slower.

masklinn · on June 5, 2012

> What about rapid prototyping?

Refactoring really, truly and absolutely has nothing to do with rapid prototyping, nor does rapid prototyping has any use for refactoring.

> you’re either going to waste effort rewriting it

Throwing one away isn't "wasted effort", it good practices: you created a turd the first time around and learned a lot, polishing that turd would be wasting time.