Hacker News new | ask | show | jobs
by watwut 3326 days ago
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.

1 comments

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.

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.

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.

> 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.