[mpweiher]

> Yup. Because they can't.

Actually they can.

> incapable of offering automated refactorings without human supervision

> (and yes, that includes Smalltalk IDE's)

Patently false. Everyone repeat after me: automated refactoring was invented on Smalltalk with the Refactoring Browser. Again. Automated refactoring was invented on Smalltalk with the Refactoring Browser.

The lack of static type information was considered a major potential problem by the authors when they started the project. They later reported how they were surprised when it turned out it wasn't.

So please stop spreading misinformation.

'This is absolutely the greatest piece of programming software to come out since the original Smalltalk browser. It completely changes the way you think about programming. All those niggling little "well, I should change this name but..." thoughts go away, because you just change the name because there is always a single menu item to just change the name. When I started using it, I spent about two hours refactoring at my old pace. I would do a refactoring, then just kind of stare off into space for the five minutes it would have taken me to do the refactoring by hand, then do another, stare into space again. After a while, I caught myself and realized that I had to learn to think BiggerRefactoringThoughts, and think them faster. Now I use probably half and half refactoring and entering new code, all at the same speed (I should instrument to measure this). -- KentBeck'

http://wiki.c2.com/?RefactoringBrowser

http://www.refactory.com/tools/refactoring-browser

https://link.springer.com/chapter/10.1007/3-540-49255-0_180

[ubertaco]

Here's the thing: guided, interactive refactoring is not the same as automatic refactoring. If I can hit a button to inline all usages of a method (as in IntelliJ), that's not the same as using a tool that can point out candidate locations for inlining what might be the method.

Furthermore, the reason Smalltalk pulled all this off is because it is/was metadata-heavy. Every object could be interrogated about its shape and capabilities (in the form of asking about its "slots"), even though there were no static type annotations. It's sorta like the runtime-typing stuff done by Dialyzer in the Erlang/Elixir world nowadays, and the tooling and code all ran together in the same runtime/VM instance.

Clearly this is not the case for Python, Ruby, or Javascript, where the tooling runs in a separate process from the code, and there's very little metadata that tooling can query without just up and executing the whole program. In fact, this particular lack of metadata is why PEP-484 exists (https://www.python.org/dev/peps/pep-0484/) adding "type annotations" that are really just runtime metadata hints.

So no, a language without static typing or metadata is not as tooling-friendly as a language with such requisite available analyzable information, and certain categories of refactoring cannot confidently be done automatically.

Smalltalk was not as "loose" as Javascript or Python, not by a long ways. The level of metaprogramming it was capable of was only enabled by the level of metadata it made available to its hybrid, in-process runtime/design-time tooling.

[hota_mazi]

> Clearly this is not the case for Python, Ruby, or Javascript,

Javascript objects are inspectable and modifiable in exactly the same way as Smalltalk objects are. All browsers support this today.

This inspection capability has nothing to do with static/dynamic typing.

> So no, a language without static typing or metadata is not as tooling-friendly as a language with such requisite available analyzable information, and certain categories of refactoring cannot confidently be done automatically.

Yes, they are. You can do anything with IDEA/Eclipse + Java that you could do in Smalltalk + IDE.

[hota_mazi]

> > (and yes, that includes Smalltalk IDE's)

> Patently false.

It's a mathematical fact.

Without type annotations, refactorings are never safe and need supervision from a human.

Did you notice that the "Refactoring Browser" calls itself just that, not "Automatic"?

Because it can't provide that guarantee. Even renaming a function is dangerous and can break a program when you don't have type annotations.

I have a lot of respect for Smalltalk and the pioneering work it accomplished, but the refactoring browser was just a powerful string replacement engine, nothing more. Which is not a knock on the engineers and scientists who invented it: it simply, mathematically, could not do more than that.

[mpweiher]

> Without type annotations, refactorings are never safe

There is a difference between "I can prove this is safe" and "this is safe". You guys need to start figuring out the difference between theory and practice.

[dahauns]

In practice, "this is safe" often transforms to "I thought this was safe" at the most inopportune moment.

[mpweiher]

Nope, your theory says it should. In practice it doesn't.

[dahauns]

Please. With all due respect towards Smalltalk and all the pioneering work it did, stop it with the Refactoring Browser as a shining example for automated refactoring.

No, it really can't, not with the correctness guarantees of a statically typed language.

If you are required to run tests to do refactoring, you're simply not on the same level.

The last paragraphs in this link for an example (Ironic title, I know. :) ):

http://wiki.c2.com/?DynamicTypesEaseRefactoring

[watwut]

Automatic refactoring in dynamic languages are nowhere need to those in java. Just rename method - with static typing you know it was changed correctly everywhere, full stop. Implementation of refactoring code is easy. With javascript, you just don't know what can potentially come in as argument of function, so you don't know whether object function call can or can not be renamed.

Smalltalk authors seeing static typing as major potential problem when started years ago does not make it actual problem today.

[mpweiher]

Please: re-read the comment and preferably the links as well. Once again: automatic refactoring tools were invented on Smalltalk.

> Smalltalk authors seeing static typing as major potential problem

Authors saw lack of static typing as a major potential problem. It just wasn't. Again: reading helps. A lot.

[irishsultan]

This may depend a lot on coding style and uniformity of coding conventions, something likely to be the case on the Smalltalk system (as it was designed by a small and focussed team) and less likely to be the case on a system using many different libraries, some of which might have names conflicting with names you use.

Even then you still need manual supervision in that it may work in 99% of the cases, but for a particular method it is more difficult to automate (because it's meaning is more overloaded).

And of course just because the authors foresaw problems and decided that it was fine doesn't mean someone used to refactoring in static type system can't have more stringent norms.

[mpweiher]

Yours is first and foremost a theoretical argument. The authors of the Refactoring Browser and I understand these theoretical concerns (about not having static type safety). However, there is theory and there is practice. The two are not identical, and practice trumps theory (see also: science). And in practice, that theoretical concern appears to not have been an issue.

You also argue with hypotheticals (may...depend, likely be the case etc.). Why is that so? Is it because you can't accept that reality doesn't conform to your theory?

Once again: the argument was "you can't". That is as patently false as can be, in reality is it not just "you most definitely can", but "this system is extremely well suited for building this type of tool and in fact the whole category was invented on that system".

And your theoretical concerns notwithstanding, people who have actually used the system consider it best-of-breed.

A scientific approach adapts theory to observation. Theology adapts observation to theory.

[irishsultan]

> You also argue with hypotheticals (may...depend, likely be the case etc.). Why is that so?

Partly because my experience with Smalltalk has always been that my experience is less positive than what others claim to encounter (this is not just about refactoring, where at least once I wanted to rename a method, but this method name was also used in a different context where it shouldn't be renamed, typing would have made this irrelevant; but also about things like Monticello where I got far more conflicts and things that didn't work out of the box than I consider reasonable or knew how to handle). This may have been the way I got introduced to the platform, but it colors my skepticism about the generality of the observations.

[mitsoz]

Well, he/she isn't saying anything about smalltalk, but talking about python. Are you sure these two pose the same problems when it comes to automated refactoring? Apart from just lack of static typing, these languages could be miles apart when it comes to how dynamic they are and what problems this poses to automated refactoring. For example, the fact that attribute access in python can be delegated to a function that will receive the attribute name as an argument and decide whether that object has this attribute or not and what it is, or the fact that you can dynamically generate a new class whose attribute names and implementation come from outside as function arguments. How would you deal with automating the renaming of such an attribute when it is defined and used across wildly varying circumstances. I have no idea if smalltalk can do this, or even if my examples are good examples of showcasing the automated refactoring problem, but just raising a point.

[klibertp]

> I have no idea if smalltalk can do this,

It can.

> if my examples are good examples of showcasing the automated refactoring problem

They're not.

More to the point: Smalltalk is as dynamic a language as practically possible and was like that for two decades before Python existed. The `__getattr__` from Python, `method_missing` from Ruby, and `__index` from Lua are all inspired by Smalltalk's `doesNotUnderstand`. The concepts of metaclasses and first-class message sends was invented in Smalltalk. The idea of inspecting code using a GUI instead of flat text files also originates with Smalltalk. Refactoring, as noted by GP, also came out of Smalltalk-land. Smalltalk gives you all that without any static typing in sight.

How? Smalltalk is special. Normally, you have your code: a static blueprint of what's going to happen; and a program: part of computer memory which your code gets loaded into and gets executed. This is true for both statically and dynamically typed languages: the familiar type something -> hit "Run" -> see if it worked cycle works equally well in Java and in Python.

Smalltalk is not like this. With Smalltalk, all you have is a program. It's always running. You hand it the code and it patches itself dynamically in memory. The classes are live objects you can query. Metaclasses are, too, objects you can query. They implement methods for refactoring. It's easy, because there's no need for any parsing, statical analysis of any kind: you just iterate over all the classes in your system and ask them one by one: "do you call such-and-such method?" And the classes inspect themselves and say: "why, yes, I call it when handling such-and-such messages, here's the list".

Really, Smalltalk is special. It's not unique: Forth and Common Lisp come to mind, Self, Lua and Io too. But it's special and very few modern languages come close to its capabilities.

[mpweiher]

> isn't saying anything about smalltalk

Very specifically was: "(and yes, that includes Smalltalk IDE's)"