Writing code. Failing. Trying again and again. Slowly, at some point, it starts clicking, and before you know it, you're much more productive than you used to be in Ruby or whatever else, and then you're cursed by lambda.

I wrote this as an exploratory bit of Haskell before I knew monad transformers : http://www.parsonsmatt.org/2015/05/02/scotty_and_persistent....

Three months after that, I had a fulltime Haskell internship, and a year after that, I'm working full time doing Haskell.

How did you overcome the cabal hell? Sandbox? VM? Nix? ...

Just use stack these days:

https://docs.haskellstack.org/en/stable/README/

It's easy to use and completely solves the problem. I could never use Haskell seriously until I found stack.

It may be easy to use but hard to install if you don't want to depend on binary downloads. Since I always prefer source compilation for reproducible installations on new platforms I tried to install an up-to-date Haskell platform on Debian 7 to use stack. After being stuck in the cabal hell again I tried several upgrades and downgrads of ghc just to make a cabal upgrade. Nothing worked. I couldn't even compile the built-in cabal-install of ghc. At least this should work.

Haskell is a really nice language, and I admire the work of the developers who provide GHC for free, but installation from source is really immature and painful, at least on Linux. If the Haskell platform were just self-hosting ...

That's an interesting point. I've never tried to build it directly from source. I'm not sure if this actually addresses what you want to do, but maybe you could start with the prebuilt binaries and then do `stack upgrade`, which will fetch and build the latest release from source?

I will say that I won't touch the Haskell platform with a 10 foot pole. I had nothing but issues with it in the past and it drove me away from using Haskell for years prior to finding stack.

> start with the prebuilt binaries and then do `stack upgrade`

Thanks but in this case I could also download the newest binaries instantly. The point is that I don't want to be dependent on any binaries. Compilation from scratch doesn't work.

Btw Rust has the same problem - it also depends on binary upgrades. Nim (nim-lang.org) proves how easy self-hosting can be - which also means how easy porting to other platforms can be.

I've never experienced cabal hell since stack came around.

Some links that might be of interest:

http://bitemyapp.com/posts/2014-12-31-functional-education.h...

http://bitemyapp.com/posts/2015-08-23-why-we-dont-chuck-read...

http://bitemyapp.com/posts/2016-02-06-haskell-is-not-trivial...

https://github.com/bitemyapp/learnhaskell

http://haskellbook.com/ by the above author

There's not a huge gap between understanding types and monads and stuff like that and being able to write useful code. You just have to try things so you can learn the ecosystem and the idioms people use. I found multiple times learning Haskell that I'd re-invented a concept someone else had already turned into a popular library.

Building a website is a good place to start. Haskell has several very good web frameworks. "Very good" means fast, correct, and well-designed. I don't recommend Snap for beginners; it uses too many strange idioms that aren't used elsewhere in Haskell.

I personally use Happstack because it's very straightforward; it just gives you a monad in which you can do "web stuff" like inspect the URL, read cookies, send back HTTP responses, etc. You can start doing everything the "manual" way, like passing around state in arguments or doing janky text formatting yourself. As you get fed up with that, you can gradually integrate things like monad transformers, custom monads with typeclass derivation, various high-performance formatting libs like blaze, aeson, heist, etc. If you do database stuff you can learn about weird template Haskell and typeclass stuff with Persistent and Esqueleto.

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...

You might consider Rust instead. It has a nontrivial type system, but the benefits are a lot more clear.

I hypothesize that if you're still interested in Haskell after that that you may find it easier to learn. Don't know if many people have walked that path, though.

It's the purity that's the challenge; you can basically construct your types just as accurate or inaccurate as you want. But purity forces you to understand a couple of things first, in order to be productive (eg. monads, monad transformers, type classes).

In my view, Haskell is in the opposite spectrum of Rust when it comes to performance over abstraction. Haskell abstracts everything away, and only manages to get good performance because of purity (I would argue), while Rust wants to be close to the metal, preferring performance over abstraction (e.g. with zero cost abstractions).

"In my view, Haskell is in the opposite spectrum of Rust when it comes to performance over abstraction."

That is why I suggested it. It's a different "hair shirt" than Haskell, but it's one that's a lot easier to explain the benefits of.

Rust won't help much with Haskell.