3 ms·

Until you can 'get work done' without the equivalent of graduate-level math classes The problem is the name "monad", not the concept itself. You don't actually

Until you can 'get work done' without the equivalent of graduate-level math classes The problem is the name "monad", not the concept itself. You don't actually need to know anything about category theory to do I/O. You just need enough exposure to the concepts to know why the Monad type class is so repeatedly relevant as to be given a named abstraction. People have a hard time getting past the name. You don't need to be a category theorist to use monads in Haskell.

jaggederest 12y ago
> You don't need to be a category theorist to use monads in Haskell. I find that demonstrably false. Every time I run into problems and ask for help, the answer is "there is this other mathematical concept that solves that problem". It's not just monads, it's comonads, monad transformers, GADTs, Functors, phantom types, arrows, arrow transformers, the list keeps going. In addition, they're only described in terms of other mathematical terms - the same problem that plagues monads: nomenclature. And these aren't just 'things you can use', if you want to understand the libraries you're using, you need to be able to keep up with all of those and more. It's not like lisp, where you can mostly rearrange cons cells to make nearly any data type you like - there's no way to bootstrap your brain into understanding arrows from a standing start, at least in my experience as an autodidact trying to learn.
- michaelochurch 12y ago
  This is an excellent resource: http://dev.stephendiehl.com/hask/ http://dev.stephendiehl.com/hask/ There's also Chris Allen's guide: https://github.com/bitemyapp/learnhaskell https://github.com/bitemyapp/learnhaskell . You can also go through the (good, but very dated) book, Real World Haskell. Sometimes you have to find the tutorials and blog posts first. The lens type signatures aren't the easiest to understand, and sometimes its easier to just use things "empirically" without fully understanding them, and then get a sense of the type signatures when you really want to know what the compiler's actually doing. Being able to use lenses is not as hard as understanding why its intimidating rank-2 type signature is the right one. Finally, sometimes it helps to de-generalize. To replace (Monad m) with IO, for example, and think about what that special case might mean. For example, the type signature for Control.Arrow.first is: first :: Arrow a => a b c -> a (b, d) (c, d) If you're a beginning Haskeller, your reaction is going to be "WTF"? Well "Arrow" is a type class more general than function. (It could be the "effectful function" type or Kleisli arrow, a -> IO b.) If you specialize with a = (->), you get the more concrete type signature: first :: (b -> c) -> (b, d) -> (c, d) ... and it's much more clear what it does. As for nomenclature, I don't disagree. I had this discussion with Brian Hurt (and owe him for the insights): we'd be more marketable if we called Monoid "Appendable" and Functor "Mappable". Monad is one where it's hard to come up with a more accessible name for it: it abstracts over computational context (i.e. what do we actually mean when we talk about computational effects) but that would be a mouthful of words and not any more clear.
  - jaggederest 12y ago
    I know all these things now - my point is that it took me years to get them to a level where I understand what they mean well enough to implement them anew. You can't say that about other languages. Nobody is going to 'build a community' around a language that is so effectively obtuse, and when called on it, says 'here are tutorials' - tutorials are not the point. RTFM isn't a decent response to 'your language is difficult to learn and use'.
- sclv 12y ago
  GADTs, phantom types, and arrows (not to mention monad transformers) aren't "mathematical terms" in that the names aren't borrowed from mathematical terminology. They're just _terms_. But to you they are new terms. So you call them "mathematical terms" because obviously if you haven't heard of it, then it must be complicated math. It isn't. If you stop thinking that every new concept you meet in the world (or at least in Haskell) is a "mathematical concept" and start thinking it is "just a thing that is new and I can learn" then maybe you will stop feeling this way. For that matter, none of the things you list except for Functors and Monad Transformers (which are just "ways to build monads") are idiomatic for "basic" haskell programming, and the next step up, GADTs is a straightforward feature to learn when you need. If you read something like RWH or LYAH, you'll notice they don't cover arrows or GADTs that much. That's because they're not considered core concepts. If you set out to learn "all the things" and then discover that there are a lot of things, perhaps the problem is just that you set out to learn "all the things" under the false impression that you need to in some immediate way.
- dllthomas 12y ago
  To a first approximation, no one uses arrows aside from the function instance. I've never encountered an arrow transformer in the wild.
  - dllthomas 12y ago
    I should amend this. I have never noticed something to be an arrow transformer in the wild, neither because it was called out in documentation or naming, nor independently. I have much less confidence nothing I have encountered has ever been an arrow transformer...

jaggederest 12y ago

> You don't need to be a category theorist to use monads in Haskell. I find that demonstrably false. Every time I run into problems and ask for help, the answer is "there is this other mathematical concept that solves that problem". It's not just monads, it's comonads, monad transformers, GADTs, Functors, phantom types, arrows, arrow transformers, the list keeps going. In addition, they're only described in terms of other mathematical terms - the same problem that plagues monads: nomenclature. And these aren't just 'things you can use', if you want to understand the libraries you're using, you need to be able to keep up with all of those and more. It's not like lisp, where you can mostly rearrange cons cells to make nearly any data type you like - there's no way to bootstrap your brain into understanding arrows from a standing start, at least in my experience as an autodidact trying to learn.

michaelochurch 12y ago
This is an excellent resource: http://dev.stephendiehl.com/hask/ http://dev.stephendiehl.com/hask/ There's also Chris Allen's guide: https://github.com/bitemyapp/learnhaskell https://github.com/bitemyapp/learnhaskell . You can also go through the (good, but very dated) book, Real World Haskell. Sometimes you have to find the tutorials and blog posts first. The lens type signatures aren't the easiest to understand, and sometimes its easier to just use things "empirically" without fully understanding them, and then get a sense of the type signatures when you really want to know what the compiler's actually doing. Being able to use lenses is not as hard as understanding why its intimidating rank-2 type signature is the right one. Finally, sometimes it helps to de-generalize. To replace (Monad m) with IO, for example, and think about what that special case might mean. For example, the type signature for Control.Arrow.first is: first :: Arrow a => a b c -> a (b, d) (c, d) If you're a beginning Haskeller, your reaction is going to be "WTF"? Well "Arrow" is a type class more general than function. (It could be the "effectful function" type or Kleisli arrow, a -> IO b.) If you specialize with a = (->), you get the more concrete type signature: first :: (b -> c) -> (b, d) -> (c, d) ... and it's much more clear what it does. As for nomenclature, I don't disagree. I had this discussion with Brian Hurt (and owe him for the insights): we'd be more marketable if we called Monoid "Appendable" and Functor "Mappable". Monad is one where it's hard to come up with a more accessible name for it: it abstracts over computational context (i.e. what do we actually mean when we talk about computational effects) but that would be a mouthful of words and not any more clear.
- jaggederest 12y ago
  I know all these things now - my point is that it took me years to get them to a level where I understand what they mean well enough to implement them anew. You can't say that about other languages. Nobody is going to 'build a community' around a language that is so effectively obtuse, and when called on it, says 'here are tutorials' - tutorials are not the point. RTFM isn't a decent response to 'your language is difficult to learn and use'.
sclv 12y ago
GADTs, phantom types, and arrows (not to mention monad transformers) aren't "mathematical terms" in that the names aren't borrowed from mathematical terminology. They're just _terms_. But to you they are new terms. So you call them "mathematical terms" because obviously if you haven't heard of it, then it must be complicated math. It isn't. If you stop thinking that every new concept you meet in the world (or at least in Haskell) is a "mathematical concept" and start thinking it is "just a thing that is new and I can learn" then maybe you will stop feeling this way. For that matter, none of the things you list except for Functors and Monad Transformers (which are just "ways to build monads") are idiomatic for "basic" haskell programming, and the next step up, GADTs is a straightforward feature to learn when you need. If you read something like RWH or LYAH, you'll notice they don't cover arrows or GADTs that much. That's because they're not considered core concepts. If you set out to learn "all the things" and then discover that there are a lot of things, perhaps the problem is just that you set out to learn "all the things" under the false impression that you need to in some immediate way.
dllthomas 12y ago
To a first approximation, no one uses arrows aside from the function instance. I've never encountered an arrow transformer in the wild.
- dllthomas 12y ago
  I should amend this. I have never noticed something to be an arrow transformer in the wild, neither because it was called out in documentation or naming, nor independently. I have much less confidence nothing I have encountered has ever been an arrow transformer...