Hacker News Reader

Comment by hacker_9 | Hacker News Reader

Main reason I don't make the jump into fully functional language, is the difficulty of refactoring. It's nice if you get the program structure right first time, but of course that doesn't happen and so the inability to easily pivot makes me stay away. saying that, I do get hit by bugs that come from state, and each time I wished I'd used the functional approach, but it's not enough of a reason to make me switch.

View on HN

That's the weirdest argument I have heard against Haskell so far. Re-factoring is the single best thing in Haskell IMO. 90% of cases are 1/ change type 2/ fix fall-out 3/ done.

If I add a new member to a type, because of immutability, if I change the member it means I have to think about creating new instances all the way up the chain. And then in turn handling how that change propagates out. It makes for more hassle and time needed to make changes compared to just having mutable instances.

Not quite sure what you're talking about but it sounds like you want lenses.

Mutability is definitely not less hassle or time if you account for the dramatic difference in error rates and maintenance costs.

If you add a new member to a type aren't you usually describing new behavior? Isn't it sensible to have to implement that behavior everywhere?

What language don't you have to do that in where not doing so also won't change behavior and result in an error?

That's… exactly the opposite of my experience, and that of every Haskeller I know. Refactoring is 100x easier in Haskell than any other language I've worked in.

What was the biggest and oldest codebase you worked on?

A few years and maybe ~50k lines of code, iirc. I've heard the exact same reports from people who work on multi-million-line Haskell codebases, though (e.g. Standard Chartered).

100 times easier than right-click refactor in a modern Java IDE? I beg to differ--if we are talking about your typical Haskell vim/text editor rig. For a language with such powerful types, it's like a gun with no bullets lacking a good IDE to take full advantage.

I've never used a modern Java IDE (as I've been fortunate enough to never have to program in Java), but still feel confident in the claim that refactoring Haskell is 100 times easier, yes.

Then you probably should, before making such claims. IntelliJ can do refactorings like the following:

Extract code into a function, automatically suggested by duplicated code detection. Inline functions back into call sites.

Convert imperative for-loops to functional style streams and back again.

Change function prototypes globally by adding or removing parameters.

Extract classes and interfaces.

Common sub-expression elimination (i.e. select an expression, introduce a new variable, all uses of that expression can be replaced as well)

Detect dead code and automatically remove it.

Refactorings across languages.

Replace inheritance with delegation or vice-versa.

Automatically generify code. Extraction of type variables.

Obviously a whole suite of structural code changes like renamings and other smaller things.

That's without getting into all the other code intelligence features.

Regardless of how fancy you feel the type system of a language is, these sorts of keyboard-driven refactorings are tremendously helpful for getting code and APIs right.

> For a language with such powerful types, it's like a gun with no bullets lacking a good IDE to take full advantage.

Agreed, though hare is trying (has, but needs editor integrations?) to address this:

https://github.com/RefactoringTools/HaRe

If your idea of "refactor" is "change name of variable", then I guess Java wins. However, the refactors I do are frequently much more complicated, involving logic swaps that are far beyond a right click action.

Java IDEs only handle a few of the simplest cases of refactoring. That's useful, but it's not enough to make refactoring easy in general.

Reply on news.ycombinator.com