47 ms·

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 abst

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.

mmphosis 5y ago
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 ∵⌷⊃○⌽⍉⌊⍟⊖∇⍫⍒∆
- toastal 5y ago
  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 `∘`.
  - smichel17 5y ago
    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-free-software-libreplanet-talk-2016/ https://harihareswara.net/texts/inessential-weirdnesses-in-f... which you can watch at https://media.libreplanet.org/u/libreplanet/m/inessential-weirdnesses-in-free-software/ https://media.libreplanet.org/u/libreplanet/m/inessential-we...
    - tome 5y ago
      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://www.google.com/search?hl=en&q=%3C%24%3E https://stackoverflow.com/questions/37286376/what-does-mean-in-haskell/37286470 https://stackoverflow.com/questions/37286376/what-does-mean-...
redbar0n 5y ago
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 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.
spc476 5y ago
Can you describe a monad without using the words "functor", "applicative," "endofunctor" or using Haskel syntax to describe it?
- redbar0n 5y ago
  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 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.
- dirkt 5y ago
  "Overloaded semicolon with in-built assignment of the value of the first statement".
- juxtapose 5y ago
  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.
- duped 5y ago
  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.
andrekandre 5y ago
> I'd prefer math and programming shared terminology there are many kinds of maths, from which one of them should they share terms?
- toastal 5y ago
  Category theory seems like a good place to start
- naniwaduni 5y ago
  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.
- elbear 5y ago
  Algebra would be one candidate, since that is the field that deals with the structure of entities.
coldtea 5y ago
>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.
- redbar0n 5y ago
  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 https://youtu.be/oYk8CKH7OhE?t=1454 from 24:14 until 29:39.
housecarpenter 5y ago
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.
seanparsons 5y ago
It's fine, just disallow jargon like functions, lambdas, addition, concatenation and so on...

mmphosis 5y ago

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 ∵⌷⊃○⌽⍉⌊⍟⊖∇⍫⍒∆

toastal 5y ago
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 `∘`.
- smichel17 5y ago
  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-free-software-libreplanet-talk-2016/ https://harihareswara.net/texts/inessential-weirdnesses-in-f... which you can watch at https://media.libreplanet.org/u/libreplanet/m/inessential-weirdnesses-in-free-software/ https://media.libreplanet.org/u/libreplanet/m/inessential-we...
  - tome 5y ago
    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://www.google.com/search?hl=en&q=%3C%24%3E https://stackoverflow.com/questions/37286376/what-does-mean-in-haskell/37286470 https://stackoverflow.com/questions/37286376/what-does-mean-...

redbar0n 5y ago

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

spc476 5y ago

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

redbar0n 5y ago
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 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.
dirkt 5y ago
"Overloaded semicolon with in-built assignment of the value of the first statement".
juxtapose 5y ago
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.
duped 5y ago
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.

andrekandre 5y ago

> I'd prefer math and programming shared terminology there are many kinds of maths, from which one of them should they share terms?

toastal 5y ago
Category theory seems like a good place to start
naniwaduni 5y ago
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.
elbear 5y ago
Algebra would be one candidate, since that is the field that deals with the structure of entities.

coldtea 5y ago

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

redbar0n 5y ago
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 https://youtu.be/oYk8CKH7OhE?t=1454 from 24:14 until 29:39.

housecarpenter 5y ago

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.

seanparsons 5y ago

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