On Thu, Mar 20, 2014 at 1:21 AM, Nadir Sampaoli <nadirsampaoli@gmail.com> wrote:

As the saying goes, less code means less potential for bugs :)

But you should look out for code golf, which isn't helpful.

As someone who is still struggling to get past that learning phase where you only solve "simple" (usually one-liner) exercises, I'd like to ask you (and anyone reading this) how do you reason at a larger level?

There's a lot of low-lying fruit that's easily plucked leveraging functional programming. I list the easiest ones that I know of here:

http://www.atamo.com/blog/low-lying-fruits-of-fp-1/

Of course, you still have to grapple and understand your specific problem domain, whether it's web apps or auto music generation.

How do you work at a larger (module/project) level? Do you need to have mastered all the main monads (beyond list amd maybe) and monad transformers?

Don't sweat them monads. The codebase for GHC doesn't even use monad transformers iirc.

Sorry for the long rant.

Not at all. Haskell mailing lists used to have long, discursive discussions, but somehow this one turned into some kind of rapid-fire Q&A. Most of the interesting knowledge can't be unpacked in that format.

-- Kim-Ee