Hacker News Reader

Comment by toastal | Hacker News Reader

I'm never going to understand the 'mathmatical jargon' argument against Haskell (and similar). Yes, but this can be true in almost any language that allows abstractions. The math jargon is just a name for a concept and I'd prefer math and programming shared terminology where appropriate rather than coming up with an entirely separate vocabulary. Is Functor really works than Mappable? It's just a label for the abstraction and you'll have to learn the underlying concept regardless so you might as well share the same word.

View on HN

Thank you for the feedback. Maybe this short video clip can help.

Elm creator Evan Czaplicki illustrates it by way of the Monad:

https://youtu.be/oYk8CKH7OhE?t=1454 from 24:14 until 29:39.

I've also updated that section of the article, to provide some justification for my wish there, including a few more illustrative backing sources.

The Haskell concepts are not quite the same as the mathematical concepts; they're somewhat restricted, and different aspects of them are emphasized (e.g. monads---programmers generally think of bind as the basic operation and join as derived, mathematicians generally think of join as the basic operation and bind as derived). So different names could be justified for that reason. It's also not just "math jargon" but "category theory jargon", which is worse than ordinary math jargon.

Can you describe a monad without using the words "functor", "applicative," "endofunctor" or using Haskel syntax to describe it?

Sure, here's the practical description :

A monad is a data structure that holds one value, but that value may be of one of several types. It implements a `map` function which allows conversion to the same monad with different set of types, eg there is some function `map` defined as :

   fn map ( f : Tn -> Un, Monad<T1, T2, ..., Tn, ... TN>) -> Monad<T1, T2, ..., Um, ..., TN)

for each type the value may be in the Monad.

Two commonly used examples are the Optional and Result monads. An Optional is either a value of type T, or the empty type None. A Result is a value of type T or some error E.

The utility of monads is their ability to chain operations. With optionals, you can map the results of functions that may or may not return results without handling the None case explicitly. With Result types you may chain operations that return errors, and handle both the successes and cases where you need to convert errors.

Monads can be expressed in many languages, but they make the most sense in languages with algebraic data types (to express a value is one of a set of possible types, aka union/sum types) and first-class functions (where functions can be passed as an argument, or else implementing `map` may be difficult).

The mathematical parlance is really harmful to their adoption because as an abstraction, monads are stupidly easy to use.

I think you describe only a Functor, not a Monad. A Monad also has to have either a `bind` or a `flatmap` function, besides the `(f)map`.

Basically the point of a monad is to depend on the output of another monad data type of its kind — e.g. it can take an IO String and use the encapsulated String value to produce another IO X. This would be IO (IO X) without the flatmap, or the bind function that can remove this double encapsulation.

This is what I was attempting to describe. `bind` is implicit, it's the constructor of a monad.

In my definition `map` is serving the purpose of your flatmap, I didn't mean to imply double encapsulation.

Elm creator Evan Czaplicki can, in an elegant and pedagogical way that would feel familiar to at least developers coming from JS:

https://youtu.be/oYk8CKH7OhE?t=1454 from 24:14 until 29:39.

Haskell/FP/Math purists would probably balk at the oversimplification. But introducing intimidating concepts by way of such oversimplification (without entirely missing the target) is precisely the point! Beginners just need a very rough and coarse grained overview, so they are able to gain some basic familiarity with the concept. That gives them some already-familiar conceptual knobs to hang further details on, reduces fear, and inspires curiosity to investigate further.

It's not hard to describe what monads are, but it's probably not going to convince anyone of its importance without an appropriate language. The monad per se is an extremely simple idea. In fact, monadic interfaces are ubiquitous:

    Rust:  Result::and_then()
    Scala: Option.flatMap()
    JS:    Promise.then()
    ...

I agree it can take some time to discover the similarities between these interfaces. But a monad is just that. It's so simple that we are blind to see.

Unfortunately, it requires a sufficiently advanced language to express the concept of Monad. You need at least higher-kinded types and means to describe behaviors of HKTs.

Can you understand or describe monads in a less powerful language, say Rust? Definitely!

But will you appreciate the power that monads give you in Rust? Probably no.

A monad isn't a concrete thing, a monad is a pattern that lots of different types adhere to. So it makes sense to extract it into an interface, in that operations that only use the monadicness can be implemented once for all types that are monads. It doesn't make much sense to study monads apart from the things that implement the interface, because there is not much to it. It's just an interface for the abstract notion of an ordered sequence of actions.

"Overloaded semicolon with in-built assignment of the value of the first statement".

Wrappable, Mappable and Collapsable (i.e. return/pure, map and join)

  > I'd prefer math and programming shared terminology

there are many kinds of maths, from which one of them should they share terms?

If you pick one, some people will see similarities, some people will get weirded out by abstraction leak, and a lot of people will have no idea what you're going on about.

If you pick none at all, well, you mostly just get the last two.

Category theory seems like a good place to start

Algebra would be one candidate, since that is the field that deals with the structure of entities.

It's fine, just disallow jargon like functions, lambdas, addition, concatenation and so on...

>I'm never going to understand the 'mathmatical jargon' argument against Haskell (and similar). Yes, but this can be true in almost any language that allows abstractions.

Well, the author (and many others) wants them to allow less abstractions then.

Not necessarily. See this short clip where Elm creator Evan Czaplicki illustrates my point by way of the Monad:

https://youtu.be/oYk8CKH7OhE?t=1454 from 24:14 until 29:39.

as my program might not use math or 'mathematical jargon' I would expect the tree shaker to eliminate all math as dead code

but if my program happens to draw the sword of math beware! I am never going to understand Haskell, or should I say ∵⌷⊃○⌽⍉⌊⍟⊖∇⍫⍒∆

That's not a very Haskell thing to see that many Unicode operators. Are you thinking Agda or APL? At least in PureScript, all infix operators must have word name and is either a list of ASCII symbols or a single Unicode character. And even still, you see a massive amount of programmers abusing (and misusing) ligature fonts to make their code look more like math without embracing Unicode and the actual symbols. Why fight over composition operator being `.` or `<<` or `<<<` when you can use the one from math, `∘`? Using Vim, use the digraph `Ctrl+k` then `Ob` and now you have a `∘`.

Haskell is, however, fond of custom `operators' (infix functions made of symbols). For example, take <$>. It's barely even shorter than fmap! And Haskell even has a special syntax if you want to make fmap infix. Is it really worth the characters to write

    a <$> b

instead of (1 char longer)

    fmap a b

or (3 chars longer)

    a `fmap` b

I understand fmap, but <$> tripped me up for an embarrassingly long time when trying to read Haskell code. In any other language, I'd do a web search for the function I didn't understand, to learn more about it, but that doesn't work here because most search engines don't handle symbols well. You have to know to use Hoogle. But someone who's trying to teach themselves Haskell isn't just going to know that. Learning Haskell doesn't have to be harder than learning another language, but it does require inordinately more hand-holding.

I'm sure I'm not the only one. This is something I would call an "inessential weirdness"[0] of Haskell. There is a whole host of others— <>, $, and >>= are some from the Prelude alone; it becomes especially tricky when people don't use explicit or qualified imports.

[0]: A term I learned from this excellent talk, https://harihareswara.net/texts/inessential-weirdnesses-in-f... which you can watch at https://media.libreplanet.org/u/libreplanet/m/inessential-we...

You can search for <$> fine on Google. The top hit is a Stack Overflow question "What does <$> mean in Haskell?".

https://www.google.com/search?hl=en&q=%3C%24%3E

https://stackoverflow.com/questions/37286376/what-does-mean-...

Reply on news.ycombinator.com