3 ms·
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,
by hacker_9 10y ago
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.
- nbouscal 10y agoThat'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.
- izacus 10y agoWhat was the biggest and oldest codebase you worked on?
- nbouscal 10y agoA 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).
- preordained 10y ago100 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.
- nbouscal 10y agoI'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.
- zigzigzag 10y agoThen 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.
- codygman 10y ago> 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 https://github.com/RefactoringTools/HaRe
- kqr 10y agoIf 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.
- TheCoelacanth 10y agoJava 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.
- teh 10y agoThat'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.
- hacker_9 10y agoIf 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.
- nbouscal 10y agoNot 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.
- montanonic 10y agoIf 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?
- codygman 10y agoWhat language don't you have to do that in where not doing so also won't change behavior and result in an error?