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

The idea that refactoring requires static types is ahistoric and simply incorrect.

The first automatic refactoring tool was the Refactoring Browser, in Smalltalk.

https://refactory.com/refactoring-browser/

https://www.researchgate.net/publication/220346807_A_Refacto...



Because the technique it uses is "clever" and at the same time terrible. It only works if you have 100% code coverage in automatic or monkey testing. The key quote from the paper is.

""" as the program is exercised, it converges towards a correctly refactored program. """

This occurs because the refactoring engine uses runtime data to discover the correct types and thus correct refactorings.

It is certainly not the same robustness in refactoring that you get with a statically typed language. I don't want my refactoring to "converge". I want it done.


The key quote from the paper is — "We do not attempt to automatically refactor code."

"A very large Smalltalk application was developed at Cargill to support the operation of grain elevators and the associated commodity trading activities. The Smalltalk client application has 385 windows and over 5,000 classes. About 2,000 classes in this application interacted with an early (circa 1993) data access framework. The framework dynamically performed a mapping of object attributes to data table columns.

Analysis showed that although dynamic look up consumed 40% of the client execution time, it was unnecessary.

A new data layer interface was developed that required the business class to provide the object attribute to column mapping in an explicitly coded method. Testing showed that this interface was orders of magnitude faster. The issue was how to change the 2,100 business class users of the data layer.

A large application under development cannot freeze code while a transformation of an interface is constructed and tested. We had to construct and test the transformations in a parallel branch of the code repository from the main development stream. When the transformation was fully tested, then it was applied to the main code stream in a single operation.

Less than 35 bugs were found in the 17,100 changes. All of the bugs were quickly resolved in a three-week period.

If the changes were done manually we estimate that it would have taken 8,500 hours, compared with 235 hours to develop the transformation rules.

The task was completed in 3% of the expected time by using Rewrite Rules. This is an improvement by a factor of 36."

from “Transformation of an application data layer” Will Loew-Blosser OOPSLA 2002

http://portal.acm.org/citation.cfm?id=604258


  > This occurs because the refactoring engine uses runtime data to discover the correct types and thus correct refactorings.
in smalltalk is not like other languages where you have a bunch of text files and you "build" it from there and need static types... it has to do it at runtime because thats all there is!


The PDF[1] that the second link points to gives a very good background on why a refactoring tool should be part of any software engineer's toolkit.

Thanks for sharing!

[1] https://www.researchgate.net/profile/Don-Roberts-4/publicati...


I don't understand why this is the bottom comment instead of the top one.




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

Search: