3 ms·

I'll also say it's hard to put a finger on all the details why, but it's a really easy language to refactor in I'd be interested in some data on exactly what r

I'll also say it's hard to put a finger on all the details why, but it's a really easy language to refactor in I'd be interested in some data on exactly what refactoring operations are most common in your practice. Back in the Smalltalk Refactoring Browser heyday, "Extract Method" was by far the most common operation. I'm not so sure that's going to be the case for golang. My situation might be idiosyncratic, but I find myself thinking, I did this with a struct, but this really should have been an Interface!

jerf 7y ago
In these particular bits of code, the "brushing up" I'm referring to is removing global variables and init functions (or local equivalents) and putting them into structs with New functions (in Go, local equivalents in the other languages), adding the local equivalent of dependency injection (even with the framework the code was using, most difficult in Java) and making it so development test code was not directly hitting production infrastructure with that (!). Mostly I wasn't doing "extract method" types of refactoring in these particular cases. Go isn't necessarily the easiest in any particular category, but it probably wins globally. Python is the easiest to refactor some code without making any modifications to some code that uses it, with all of its magic methods and such, but if you keep doing that to a given code base, after a few rounds of that you get into the sorts of situations where you really have no idea what "a.b = c.d(e.f, f.g())" is really doing. On the other hand, you end up missing that stuff when you're trying to refactor the Perl, which is nowhere near as good at that stuff. Java's the worst one, and I have to admit I ended up giving up even trying to clean it up; even with IDE support it takes a lot more cognitive effort than Go, the changes run deeper and spread farther, and in the end, you only end up with as much as you would have gotten with Go, not anything particularly better. It's funny; on the one hand I'm all about how the cognitive affordances of programming languages produce different results, on the other hand, when it really comes down to it, an awful lot of code is written in a way that means those affordances don't even matter because it's just too darned easy to assume the entire rest of your infrastructure is up and it's OK to bring in production resources because they're there and they're going to work... and what can your language really do about that? Who cares if that code is written with mutable or immutable variables? We lost at a much deeper level than that.

jerf 7y ago

In these particular bits of code, the "brushing up" I'm referring to is removing global variables and init functions (or local equivalents) and putting them into structs with New functions (in Go, local equivalents in the other languages), adding the local equivalent of dependency injection (even with the framework the code was using, most difficult in Java) and making it so development test code was not directly hitting production infrastructure with that (!). Mostly I wasn't doing "extract method" types of refactoring in these particular cases. Go isn't necessarily the easiest in any particular category, but it probably wins globally. Python is the easiest to refactor some code without making any modifications to some code that uses it, with all of its magic methods and such, but if you keep doing that to a given code base, after a few rounds of that you get into the sorts of situations where you really have no idea what "a.b = c.d(e.f, f.g())" is really doing. On the other hand, you end up missing that stuff when you're trying to refactor the Perl, which is nowhere near as good at that stuff. Java's the worst one, and I have to admit I ended up giving up even trying to clean it up; even with IDE support it takes a lot more cognitive effort than Go, the changes run deeper and spread farther, and in the end, you only end up with as much as you would have gotten with Go, not anything particularly better. It's funny; on the one hand I'm all about how the cognitive affordances of programming languages produce different results, on the other hand, when it really comes down to it, an awful lot of code is written in a way that means those affordances don't even matter because it's just too darned easy to assume the entire rest of your infrastructure is up and it's OK to bring in production resources because they're there and they're going to work... and what can your language really do about that? Who cares if that code is written with mutable or immutable variables? We lost at a much deeper level than that.