Magic refactoring with Unison: much more than a new programming language
I recognise it, I am obsessed with refactoring. When I program, I keep changing the names of the variables, methods or classes again and again. Or, for example, there are no functions to which the arguments do not change without stopping, until finally I am slightly satisfied. I always have the feeling that something more can and should be done.
That is why I was surprised by the refactoring capacity of this new programming language called Unison. As I said, I rename things obsessively, but this has a cost. For example, when renaming a function, you have to modify all references, or, what is the same, you have to modify all the files where there are functions or methods that invoke the renamed function. Let’s say that in the project there are a thousand files with calls to that function: this implies that after the renamed, in the code commit, of the 1001 files it will contain, only one will have a relevant change, while the changes in the rest of the files only generate noise. But… could it be otherwise?
And, of course, the answer is yes (otherwise this article would not make sense, right? 🤷🏼♀️).
In Unison, to change the name of a function, we use the move command:
.> move.term base.List.foldl base.List.foldLeft
