STOP'15: Bracha v Felleisen 

tl;dr: Refactoring can be done using dynamic observations of the program, it doesn't require static knowledge. Automated Refactoring was invented, introduced, and implemented in Smalltalk before Smalltalkers started experimenting with types. The two are unrelated. This is part of what Gilad referred to with his early remarks on tooling: modern Java IDEs need types as for their features, because they ignore what is going on dynamically in the program. Smalltalk IDEs deeply integrate with the runtime system and gain deep insights into the dynamic behavior of the system. E.g. they observe what methods call which other methods, and you can do a Rename Method Refactoring automatically, because the IDE has observed and collected the flow of method calls through all the system during its entire lifetime and knows exactly which callsite calls that precise method and which callsite calls a different method which happens to have the same name. If you don't have that data, you need types to help you, but if you do have that dynamic information, you do not actually need the type information. Think about it this way: modern Java/C♯/C++ IDEs, even modern ECMAScript/Ruby/Python/PHP IDEs do a lot of static analysis. What does static analysis mean? It means figuring out what a program will do at runtime without running it. (And we know how hard this is, Rice's Theorem, the Halting Problem, the Function Problem, …) But there is another way of figuring out what a program will do at runtime: just run it! And since Smalltalk IDEs are so deeply integrated with the runtime system, and in fact, there is no difference between runtime and development time, runtime system and IDE, runtime system and program, they can observe the behavior of the program over long periods of time and over its entire evolution. (Remember, in Smalltalk, when you evolve a system, you don't edit some dead source code, compile it and replace it, you are modifying the live system as it runs. Classes and Methods are just objects that are part of the running program, and you simply call methods on them and ask them to change themselves while the system is running without ever stopping. Shutting down a Smalltalk system is more like hibernating your PC or snapshotting your VMWare/VirtualBox, it quite literally just serializes the entire memory space to disk. A Smalltalk system never shuts down, it is always running. If you download Squeak, there may be objects in there that have been running on Alan Kay's desk at Xerox in 1980 and have been running continuously for 35 years.) Especially with the rise of automated testing, continuous integration, test-before-commit, TDD, BDD and such, we run the program during development so often that it would just be wasteful to not collect all that dynamic information. And if we have that dynamic information, then we don't need static information. Just look at the amazing things HotSpot does purely based on observing your program dynamically, and imagine the IDE having that same level of insight. Which is what Smalltalk and Lisp IDEs do, and Eclipse, Visual Studio, IDEA and friends don't, even for dynamic languages. Does any of that rambling answer your question or even remotely make sense? :-D

Jörg W Mittag It doesn't make sense to me, primarily because I disagree with the assertion that "there is another way of figuring out what a program will do at runtime: just run it!" HotSpot's optimizations are optimistic, and have safe fallbacks when unpredicted contingencies occur. Code refactorings, on the other hand, need to be 100% correct at the time they are executed. I'm also not sure how well this dynamic-awareness-of-the-system would scale to a codebase with many many millions of lines of code.

My pleasure (it would have been even better if I was not in it)

Samantha Atkins, it's not simply a matter of not recognizing good ideas in Smalltalk, it's a question of having terrible taste, no sense of aesthetics, and a disrespect for programmers, and a disrespect for both Smalltalk and C++. Java has been a blight on academia and industry. A generation of programmers learning the worst imaginable way to write software, taught that thinking inside a box was the only morally correct way to do so. As someone who writes primarily in C#, JavaScript, C++, and Scala, I look at the pitiful pseudo lambdas that we're added to Java two decades too late, and it makes me laugh but also makes me sad (to understand why, read the Reactive Streams Specification). Java must die.