[yamtaddle]

I find its syntax & idiomatic style incredibly difficult to follow, in a way nearly no other languages have been for me, including some functional languages (OCaml doesn't seem nearly as bad to me, for instance).

It's sometimes implied that those who trip over Haskell just aren't big-brained enough to understand various important concepts related to it, but I've found they're usually very easy to grasp, provided the explanation's not using Haskell examples. If all programming were Haskell, I probably never would have become a programmer in the first place. Would have taken me too long to figure any of it out, probably would have concluded I wasn't smart enough to be a programmer.

I do wonder if there are some shared experiences or common patterns to who tends to love Haskell, and those who don't. I also feel nigh-dyslexic trying to read math formulas. Human language and broadly C-family programming languages, on the other hand, seemed easy and natural to me, almost effortless to pick up. Wonder if there's a "mathy"-person versus "languagey"-person divide on finding Haskell legible.

I'm not sure it's the whole thing, but I think I've also figured out that I find algorithm-type reasoning far easier to follow and work with than equations or proofs. Like, the only way I can begin to get traction with an unfamiliar equation is to break down what each term and operation "does" to something "moving through" it—it's tedious as hell. Might be something there.

[Hirrolot]

I find the terminology that Haskell uses quite misleading for software engineering. It borrows concepts from category theory with quaint names such as a "monad", "endofunctor", "catamorphism", etc. The problem is that, instead of a "monad", we can say "brrrdogcogfog" and nothing will change -- the name is absolutely irrelevant to the problem being solved. Given that a monad is an interface for sequential computation, a much better name would be something like "Seq", "SeqComp", or something like that.

[consilient]

> Given that a monad is an interface for sequential computation, a much better name would be something like "Seq", "SeqComp", or something like that.

Just because you can look at something as describing a computation doesn't mean you always should. For example:

    data BinaryTree x = 
        | Leaf x
        | Node (BinaryTree x) (BinaryTree x)

    instance Monad BinaryTree where

        return :: a -> BinaryTree a
        return x = Leaf x

        bind :: (a -> BinaryTree b) -> BinaryTree a -> BinaryTree b
        bind f (Leaf x) = f x // replace a leaf with the result of calling f on its label
        bind f (Node l r) = Node (bind f l) (bind f r) // traverse down the tree, ultimately replacing all the leaf nodes with a new subtree

You can choose to interpret a binary tree as describing nondeterministic computation where you have two choices at every step, but I rarely do. Most of the time trees are just trees.

[hgsgm]

The tree is a tree, but the Monad instance is sequencing modifications to the tree.

[consilient]

Sure, Kleisli arrows `a -> m b` are generally best interpreted in a computational sense. But with something like `IO`, the actual objects `m b` are computations as well, and this intuition is not as broadly applicable.

[truculent]

As I understand it, monads help solve the problem of sequential computation in Haskell but the concept is not limited to that. For example, how would you consider the monadic properties of data type like Maybe or Either to be (exclusively?) interpreted through the lens of sequential computation? What about commutative monads where the order doesn’t matter?

[solomonb]

The `Monad` instance for `Maybe` and `Either` is precisely for doing sequential computation!

Consider the following:

    myBigSubroutine :: Maybe Int -> Maybe Int -> Maybe Bool
    myBigSubroutine ma mb = do
      a <- ma
      b <- mb
      return (a > b)

Here we are sequencing the "effect" of optionality. `ma` must be evaluated before `mb` and if it returns a `Nothing` then we short circuit and do not evaluate `mb`.

[gemstones]

I think the commenter who mentioned syntax is on to something. If I write this

    fn my_big_subroutine(ma: Option<isize>, mb: Option<isize>) -> Option<bool> {
        match (ma, mb) {
            (Some(a), Some(b)) => Some(a > b),
            (_, _) => None,
        }
    }

it’s clearer to me what the intent is. I’m not sure why the other syntax is so hard for me but it feels hard to understand for some reason.

[solomonb]

The `do` block I showed is more like this:

    fn my_big_subroutine(ma: Option<isize>, mb: Option<isize>) -> Option<bool> {
        match (ma) {
            (Some(a)) => 
              match (mb) {
                (Some(b)) => Some(a > b),
                _ => None
              }
            (_) => None,
        }
    }

Which in this case is equivalent in this example, however I'm trying to stress the sequencing. Imagine `mb` had some very expensive computation in it, then it will remain an unevaluated thunk if we shortcircuit on `ma`.

> it’s clearer to me what the intent is. I’m not sure why the other syntax is so hard for me but it feels hard to understand for some reason.

We can write `myBigSubroutine` with case matching:

    case ma of
      Nothing -> Nothing
      Just a ->
        case mb of
          Nothing -> Nothing
          Just b -> Just (a > b)

In fact, the `do` notation version desugars to something equivalent to this snippet.

The motivation for using the `Monad` instance (and thus `do` notation), is that it allows us to be polymorphic over the effect described by `>>=` (and thus `do`).

This lets us have a customized version of sequencing computations specialized to whatever "effect" we need, not just casing on optional values.

[truculent]

> `ma` must be evaluated before `mb`

No - either one can be evaluated first, with the other being short-circuited. If you swap the order of those lines, the function is exactly the same (in terms of inputs and outputs, at least).

[solomonb]

This `do` syntax desugars to binds like:

    ma >>= \a -> mb >>= \b -> return (a > b)

We can then inline the definition of `>>=` and `return` to get:

    case ma of
      Nothing -> Nothing
      Just a ->
        case mb of
          Nothing -> Nothing
          Just b -> Just (a > b)

Imagine that `mb` is actually a really expensive computation that we don't want to perform unless `ma` returns a value. Sequencing our case statements in this way allows us to do that. `mb` will remain an unevaluated thunk until `ma` evaluates to a `Just a` value.

[CyberDildonics]

monads help solve the problem of sequential computation in Haskell

It probably confuses people because this is a problem haskell created for itself.

[pharmakom]

F# calls them Computation Expressions which is far more approachable imo

[nequo]

That sounds almost as vague to me as “object” does in OOP. Don’t non-monadic functions also consist of expressions that describe computations?

[pharmakom]

Everything is vague. Hell, Haskell functions are not really functions in the mathematical sense.

[nequo]

To me, “computation expression” is significantly more vague than “function” is in Haskell. “Seq” as was suggested by someone else here seems clearer. But I would genuinely be happy to understand the F# point of view on this better.

[matheusmoreira]

> Given that a monad is an interface for sequential computation

And what the hell is an interface for sequential computation? I think I understand what these Maybe types are and what they accomplish but "interface for sequential computation" sounds a lot like those buzzwords people mix together that could mean anything.

[hgsgm]

It's an API for ensuring work gets done in a specified order.

Like opening the jar before sticking a knife into the peanut butter.

[matheusmoreira]

Yeah, well, so is every programming language ever created. When I write any code at all, it's to ensure the instructions are laid out in the correct order for the computer to execute.

[keithalewis]

Composition/SeqComp comes for free. A monad is how to wrap something up,apply a function to the wrapped up thing, and how to unwrap it.

[hgsgm]

Composition is not sequential in a pure, lazy language with a graph reduction runtime like Haskell.

[viscanti]

A monad is just a monoid in the category of endofunctors. Would most people know what "brrrdogcogfog" means? Couldn't we make that argument about literally any word? I don't see why it applies more here than elsewhere. For people who have experienced it before, it's straightforward and easy to work with, for those who haven't, then there's a learning curve. No one would likely have encountered "brrrdogcogfog" before and everyone would have to go through the learning curve.

[medstrom]

Like a Javascript ArrayBuffer? No, a Stream?

[throwaway17_17]

tl;dr -> I agree that the terminology is probably not something that enhances cohesion amongst devs using Haskell, and certainly can be distracting in a pedagogical setting.

I think the fact your experience leads you to believe that a monad is an interface for sequential computation. A monad is often used for ordering computations, but Haskell’s monads can also be commutative (like the Reader instance of monad) which do not order anything.

The real issue is that the naming convention where some typeclass is named after a concept in category theory means wildly different things to different developers. For instance, I would expect a type/typeclass named for some categorical construct to behave in the way the categorical construct behaves and that would be the extent of what I use it for. However, some developer may see a particular usage the same construct and extrapolate that said construct is intrinsically tied to that algorithmic pattern of usage.

So the problem is controlling expectation and managing consistency throughout the dev community. I doubt Haskell will ever get away from the category theory inspired libraries and the subsequent naming conventions. See the relatively lively development of the profunctor optics based work. But, I can certainly see how it may distract or confuse newcomers.

[yoyohello13]

My original degree was in Math and I can definitely 'feel' a difference when reading Haskell vs other languages.

Writing/Reading Haskell gives me a similar feeling to doing proofs than programming.

Even other functional programming languages don't give me that 'in the math class' feeling that Haskell does.

[jokoon]

I use generators, list comprehension and a lot of lambda stuff with python.

It's a bit fun because it's very short to write, it's concise and it helps a lot working only with dict and tuples etc.

Not sure if it's faster, but it's always a bit longer to write and think about, and I'm not sure it's easier to read and understand.

Sometimes it feels a bit like code golfing, because you can do a lot of things with very few lines.

It's immensely better to remove 99% of side effects, the code is shorter and more compartmentalized, so it's just easier to deal with.

Although I'm doing this alone, and I'm not confident that I could enforce this sort of software design in a team.

[alpaca128]

I'm in the exact same boat. Haskell code feels more like abstract maths and I feel more at home when I can just easily track the data flow. The language and community uses relatively abstract terminology due to its roots and it's just a bit too cryptic to me.

Though I'm glad newer languages are starting to adopt more features from the functional territory for the situations where it just makes more sense.

[mrkeen]

> I'm not sure it's the whole thing, but I think I've also figured out that I find algorithm-type reasoning far easier to follow and work with than equations or proofs.

For me it's the opposite. Once i figure out what an expression is, I do not want it to change on the next clock cycle.

[paddw]

I suspect you are right that there's a type of person Haskell feels very intuitive to. I think if your mind works that way you might have a hard time appreciating the degree of confusion "regular" programmers face when trying to decipher the mess of symbolic soup.

[yakshaving_jgt]

There is no reason for Haskell to be a "mess of symbolic soup".

You can make Haskell about as human-readable as Ruby if you choose to.

[WorldMaker]

Syntactically Haskell and OCaml are extremely close. A lot of the surface difference between the two languages has nothing to do with syntax and has so much more to do with how things are named by default in the standard libraries. (There are massive differences in the type system and all sorts of subtle differences below the surface, of course.)

[hgsgm]

Regular programmers were pretty happy with Perl soup.