[slydo]

Refactoring haskell like that would be a lot easier when you implement a function you're familiar with. Take for example parsing CSV. What i noticed, what haskell feels to me, is that for a different kind of problem you seem to be using a different part of the language. In a simple OO-kind of language you just have classes, objects, methods, and so on. And you build patterns on top of that to express certain idioms (see GoF and what not). In haskell you have to enable a language extension or use a slight variation of a language construct (like "data .. where" could be such a variation to just "data") [1]. Do you really need all those design patterns? For good software practises .. likely. But just to get it to work you can do without a lot of "features", at the cost of boilerplate, maintainability, performance and so on.

I found it easier to just start using certain language constructs and libraries, even though i didn't really have the feeling that i understood them. When you know what to use for your problem, open the documentation on it and look at the types. Then play a bit of "fit the type"-game with the compiler. You can already get a long way with that. To figure out which language features or library to use for your particular problem take a look at a book like real world haskell. After reading through a bunch of stuff and asking around a bit you will have a clue whether to use monad X, Y or Z for what you are trying to solve. The knowledge of how to do nice refactering will come over time. This is muscle memory you will train automatically. So maybe you will ask the wrong question when you are focused on refactering code rather than solving your problem. The way the author refactors his own code seems to be new to him also. A lot of people prefer to start out with expressing their problem in the types first, before writing functions.

[1] https://stackoverflow.com/questions/8245288/what-does-data-w...