[risto1]

Haskell is a much more complicated language than Ocaml:

- Laziness can be hard to reason about for newcomers who have really only had experience with strictness

- You have to learn a lot of concepts from category theory right off the bat, because it uses IO and monads. You need to know what a monad is, and almost all monad tutorials are notoriously bad at explaining what a monad is. You also don't know when to stop, when you've learned 'enough' category theory

- The community is full of clever tricks and idioms that aren't really necessary to write haskell code, but a beginner might think they need to know it. Examples: monad transformers, free monads, comonads, lenses, coroutines

- The type system is substantially more complex. Haskell has higher kinded polymorphism, rank-n-types, and a neverending set of extensions that a lot of haskellers use that'll keep you busy learning the rest of your life. Haskell code can also be very polymoprhic, and the type errors can be really confusing sometimes. Ocaml doesn't have these, but you can simulate the most important features: higher kinded polymorphism with functors, and rank-n-types with records

That's why Ocaml is easier to learn and use

[pyrale]

> - Laziness can be hard to reason about for newcomers

Yes

> - You have to learn a lot of concepts from category theory right off the bat, because it uses IO and monads.

No - in particular, you don't have to understand monads to use the IO monad. You just have to understand the IO monad API. That's pretty similar to not having to understand how motors work in order to drive a car.

> - The community is full of clever tricks and idioms that aren't really necessary to write haskell code, but a beginner might think they need to know it.

Yes, and that's the major mistake people may do when starting Haskell. You don't need (and you probably can't) know everything you read about in order to be efficient in Haskell. Just use the simple stuff and live the happy life.

> - The type system is substantially more complex.

Yes, but it shouldn't be a problem. See point above, learn only what you want/need and live the happy life.

(also, Ocaml is an amazing language. It's fine if you enjoy it and don't enjoy Haskell)

[risto1]

If you're writing Haskell code you need to be able to understand Haskell libraries and other people's code. You definitely need to understand the type system and what monads are, unless you're main objective is to just write a toy program

The evidence is overwhelming, considering how many people want to learn and write Haskell and how many people struggle with it. If people could ignore all of this stuff they would've figured that out by now, but they can't ignore it to really be productive. I like Haskell a lot btw, just don't think it's very practical, and it's most important contributions to FP are already being adopted in other languages without the additional complexity

[porker]

> You need to know what a monad is, and almost all monad tutorials are notoriously bad at explaining what a monad is.

Can you recommend good ones? I've read a few and don't feel I can say what a monad is or provide an example when asked.

[risto1]

See my answer to pouta

[pouta]

Could you point me to one of rare monad explanations?

[etatoby]

Just read Real World Haskell and do all the exercises. After you really understand functor and applicative, and do all the exercises, monad will not be much more complicated.

After you learn the math, that is, the algebraic structure that is called a monad (after, not before) you can watch a few YouTube videos and read some tutorials, until you find the wavy-handy explanation that makes more intuitive sense to you, personally.

[risto1]

I don't know of any to be honest, and I would seriously just avoid all of them. Read the fantasy land spec (functions + laws and how it's implemented) instead, and ask questions on an FP channel if you're stuck or confused

I've heard 'Professor Frisbee's Mostly Adequate Guide to Functional Programming' is ok, but I'm looking at the section on monads and the monad laws aren't even mentioned. Which is a huge red flag for me, because without the laws it isn't a monad and you can get really strange behavior if you use it like that. I would avoid reading that book

People write these tutorials because they want to improve their portfolio to further their career, but they often don't even understand it yet -- a perfect example of a perverse incentive.

An example is the guy who wrote "You Don't Know Js" [1]. All of these are completely wrong statements:

- "But what I will say is that a monad is basically a value type."

- "A monad is a data structure. It's a type."

- "Actually, a monad isn't a single data type, it's really more like a related collection of data types. It's kind of an interface that's implemented differently depending on the needs of different values. Each implementation is a different type of monad."

- Says "methods" a bunch of times, there are no methods involved with monads in any way, it's FP

- His example in "Just a Monad" isn't a monad

- "Actually, the Maybe monad is a particular pairing of two other simpler monads: Just and Nothing"

- "Many implementations of a JavaScript Maybe monad include a check (usually in map(..)) to see if the value is null/undefined, and skipping the behavior if so" - that makes it not a monad, it violates the laws. Java's Optional type isn't a monad for similar reasons

- "But... that approach to Maybe is not a pure monad." - there's no pure/impure monads, it's either a monad or it isn't

- "The core spirit of a Monad says that it must be valid for all values and cannot do any inspection of the value, at all -- not even a null check. So those other implementations are cutting corners for the sake of convenience. It's not a huge deal," - It is a huge deal, a whole lot of abstractions are built on top of monads, if it doesn't satisfy the laws exactly then you'll be entering a world of pain you really wish you didn't

I stopped reading the rest but you get the point. You don't want to end up in a situation where you have to unlearn a bunch of this stuff. Btw the guy who wrote the Professor Frisbee book wrote the foreword in this book, so you can see why a lot of this stuff raises red flags for experienced FPers. My suggestion is to read fantasy land and ask questions on an FP channel

[1] https://github.com/getify/Functional-Light-JS/blob/master/ma...