[schwurb]

Adressing the whitespread conception "It is hard to programm in Haskell because it is pure":

If you can write python, you can write Haskell. Don't believe me?

1. Write your program completely in the IO Monad, in a huge do-block

2. Factor out as much pure functionality as possible (= Have as little code in your big IO-programm as possible.)

Start at 1. and iterate 2. as many times as you please. It will already be a program that prevents many traps that would bite you in other langauges. Haskell knows exactly whether you are looping over an array of strings or an array of chars.

(Why all the buzz about pureness, effects and so on? Well, with Haskell you can design with a high granularity and reliability what sideeffect is caused where. But you are not forced to use that feature.)

Other tipps:

- Build small projects.

- Read as few tutorials on monads as possible. You might even get by with 0.

- The trifecta of Haskell typeclasses are the functor, applicative, monad. I would advise you to not try to understand their mathematical origins, but just look up how the are used. They will crop up naturally when you build even small projects and then they will make sense.

[zeepthee]

> The trifecta .. mathematical origins

Ends up reading Leibniz and converting to Catholicism.

[andi999]

I like the idea of iterating from imperative to functional. Here the devils advocate for your if you can do it in python you can do it in haskell: I use quite a bit of numpy, scipy and matplotlib, are there equivalent libraries for Haskell?

[AnimalMuppet]

Well... wasn't numpy, at least initially, a Python wrapper around Fortran libraries? Sure, that made them accessible to a bunch more people, but it wasn't some Python-only wonder. Someone could probably write the same bindings for Haskell, if they haven't already.

[cleancoder0]

What Haskell did with Monads is nice, but eventually Monads are just tags on what functionality the function uses.

That being said, I like that Nim and Koka did exactly that. You just tag the functions (IO, Async, Whatever) and it works.

In Haskell, you need monad transformers (which have a runtime costs) or whatever else was made to allow you to work with multiple different effects.

[siknad]

> which have a runtime costs

As monad is just an interface, it doesn't necessary cause runtime costs. Identity is a monad too. Effects may not always require sacrificing performance, but as they can be used to implement exceptions they are not just free compile time annotations. Also the differences discussed there: https://www.reddit.com/r/haskell/comments/3nkv2a/why_dont_we...

[Kototama]

It's hard because there are so many concepts to understand. After reading one Python book you can write solid programs in Python. Not so in Haskell, you would need to understand also the extensions of the language which are popular and understand the best practices (what to use to compose I/O and in which context for example), on top of all the basics. That and understand how to work with complex types in libraries: that require time. That would be too much for one book.

[schwurb]

> After reading one Python book you can write solid programs in Python.

Okay, so our goal is to write a solid program. Let's see...

> Not so in Haskell, you would need to understand also the extensions of the language which are popular

You can simply go with vanilla Haskell2010. Dealing with strings will be a bit cumbersome, dealing with records will be a bit cumbersome, but you are still at 50% the boilerplate of an average java codebase.

> and understand the best practices (what to use to compose I/O and in which context for example)

No! This is what I was aiming at: You don't have to understand these best practises to have a solid program. Throw everything into one massive do-Block and the resulting program will be at least as solid as the solid python program.

> That and understand how to work with complex types in libraries

I concur that Python documentation is heaps better than Haskell documentation, although we are slowly improving. That said, I think the work is not harder: Learning how to speak with a postgres database or do numerical tasks requires times, period. What is different to Python is that the time spent chasing runtime errors is spent chasing compile errors in Haskell.

Another user linked this comparison of numpy vs. the Haskell equivalent, hmatric. It does not look more complicated in my opinion: https://pechersky.github.io/haskell-numpy-docs/

[tome]

> you would need to understand also the extensions of the language

Not really. Extensions typically remove restrictions rather than add features, or rather, the ones you are likely to want to use do.