9 ms·

What I Wish I Knew When Learning Haskell

164 points by psibi 13y ago

ufo 13y ago
Holy shit how did I never know about the ":r" shortcut??? This changes everything.
jrockway 13y ago
Agree with the advice about monads. You're going to think monads are weird because the first one you encounter is used to hide a particular detail of how Haskell works in the real world, namely that Haskell can't mutate objects, but that running your program mutates the real world. Ignore this use case, because while interesting, it's a messy implementation detail, not something to model in your own code. Use monads for bailing out of computations early (Maybe/Either) or passing some state along through a computation (State). When you're comfortable with those concepts, look at ST for a generalization of what IO does. That is something you can actually use to simplify your own programs.
- anon_d 13y ago
  Do not agree! Monads were always this vague weird thing until I started using IO heavily. Once I was comfortable with IO, applying the abstraction to other things was obvious. I've also helped some other people learn Haskell, and being able to just explain how IO works is much easier than trying to explain the Monad abstraction.
  - jrockway 13y ago
    Yes, it's easier to explain a specific concrete example rather than an abstract concept. You don't study literature learning about iambic pentameter and then ending your studies; you also read Shakespeare to see how it's applied in real life. But, you also don't learn to read by starting with Shakespeare. You start with something simpler. The IO abstraction is deep and the implementation messy. So start with State or Writer or something, and go from there.
    - anon_d 13y ago
      Sure, but IO gives you answers to the main questions that new people have. How do I write hello world? How do read a line from standard input? How can you DO things in a language without side effects? You can't even write programs without IO, and it's really not confusing. On the other hand, I think avoiding do-syntax makes sense at first.
- JoshTriplett 13y ago
  Exactly. IO is nearly the worst first Monad to learn, because none of the internals are visible, making it look far too magic. (Only something like Cont would be worse.) The best choice would be something like Writer or State, where you can see exactly what the abstraction hides, why you'd want it, and how it would look if done via explicit state-passing.
  - jrockway 13y ago
    Yes, something like WriterT Error is a great "default state" for your functions: they can produce a correct answer, an error, and some logging information. Programmers love punting things like error handling to higher levels of their program; why not do that with logs, too? (And, given a correct implementation of Writer, if you ignore the log messages, they aren't computed. Try that with Java!)
- mjn 13y ago
  The State monad is what really sold me on the concept. Right before encountering a tutorial that mentioned it, I had just spent some time writing some code in Common Lisp, where I was trying to find a nice abstraction to avoid threading a state variable through absolutely everything. So this came across as "dear god, the abstraction does exist!" Whereas the IO monad at first blush comes across as "lol PLs geeks realized they had to actually do I/O", which is not as compelling, in part because that version comes across as a solution to a self-inflicted problem. It's slightly disappointing, though, that State doesn't work that well when translated back to Lisp: http://marijnhaverbeke.nl/monad.html http://marijnhaverbeke.nl/monad.html
  - jrockway 13y ago
    State is exactly the right abstraction for this. When people using other languages come up with an "abstraction" for state, it is always becomes a testing/debugging nightmare. With State, it really is just a parameter to your function, which you're allowed to hide if you feel like it.
jkrems 13y ago
I really wish people would start treating languages as languages. `(m >>= f) >>= g ≡ m >>= (\x -> f x >>= g)` is not easy to understand because the symbols don't have names. I can't read it. How is "m >>= f" pronounced?
- flebron 13y ago
  I think of it as "feed m to f".
  - platz 13y ago
    Except what gets fed to f is the 'unwrapped' value, not the whole monad
- insn 13y ago
  m bind f
- bsamuels 13y ago
  >How is "m >>= f" pronounced? The pronunciation is a sort of bestial hissing that is difficult to describe; when you say it correctly, the terminal may be slightly moist.
  - jkrems 13y ago
    I'll start using it.
- rollo 13y ago
  Programming languages are not natural languages. And where imperative programming can benefit from something that looks like a series of instructions resembling natural language, functional, declarative programming works better with the language being closer to mathematical notation.
  - jkrems 13y ago
    If I can't talk to you about it (e.g. I have to literally say "Oh, you forgot to declare a way to apply the greater than-greater-than-equal operator!"), it's hard to actually reason about a problem domain. It's like the magic moment where you go from stumbling through cryptic signs to being able to fluently read (aloud) complex math or logic formulas. I doesn't need to resolve to a normal, casual sentence you'd drop chatting with your cab driver - but there should be a way to pronounce it. P.S.: I guess what I'm trying to say is - every normal mathematical expression has a way to pronounce it. "plus", "for all x", "there exists an x", "sum of", "element of", ...
codygman 13y ago
As someone who has been learning haskell for the past 6~ months this is very valuable. I will be studying this and toying around with the examples quite a bit, thanks for this resource!
sillysaurus2 13y ago
Would someone please explain what a monad is and why they're useful, in down-to-Earth, simple language that an engineer can appreciate? I know (and use) basically every other CS concept. Monads, though, I've never bothered looking into, because it seems like everyone who talks about them can't resist the urge to use flowery descriptions of their possibilities, rather than examples of their pragmatism. Also, it's suspicious that pg has never once mentioned monads: https://www.google.com/search?q=site%3Apaulgraham.com%20%22monad%22 https://www.google.com/search?q=site%3Apaulgraham.com%20%22m... If they're useful, you'd think one of the best hackers would have said something about it. He spent a good deal of his career talking about closures, types, objects, functions, computing theory, lambda calculus, etc. But no monads. So, are they useful? Would anyone please give examples of their usefulness? EDIT: You know what's worse than hero worship? Not being able to make a reasonable argument which uses someone as an example without being accused of hero worship.
- iskander 13y ago
  They're a very simple abstract interface that happens to capture a surprisingly large class of data structures and computations. You need to implement two operations to make a monad: (1) take a normal value and put it in the monad (2) add a function to the pipeline of stuff being performed on the monad. If your language gives special syntax for these two functions, then you get to write generic code that does lots of different but related things depending on which monad that code gets called with. So, monads are just a handy and often-occurring interface. There's not a ton to understand here conceptually, you just use them and get used to the abstraction. edit: pg likes dynamic languages, monads don't pop up there as much. They're more useful when you (1) you have special syntax for them and (2) the type system helps you keep track of what code is not in a monad, generically using any monad, or using one particular monad. So, you'll typically only see monads in expressive/high-level static languages
  - sillysaurus2 13y ago
    Ok. So if I understand correctly, I could give a monad an open file descriptor to "numbers.txt" as its value, along with a "read line" function and a "convert string to int" function, and I'd get back a list of numbers?
parallelist 13y ago
Anyone got any solutions for cabal hell? I barely use Haskell because 50%+ of everything I try to install fails and I don’t have a freaking clue how to fix it.
- jbezos 13y ago
  Use the new sandboxing feature of cabal: http://coldwa.st/e/blog/2013-08-20-Cabal-sandbox.html http://coldwa.st/e/blog/2013-08-20-Cabal-sandbox.html
- mhitza 13y ago
  If you're using cabal to install applications from hackage, it gets a bit hairy. But if you just want to resolve your dependencies mkdir project cabal sandbox init cabal install dependency cabal repl # for a ghci instance inside the sandbox Recommended is still to generate a .cabal file and specify your dependencies there.
- thetwiceler 13y ago
  Take a look at this [1], particularly the second answer, which links to a Github Gist for "ghc-pkg-clean." I tend to use that when I run into trouble. [1] http://stackoverflow.com/questions/7961604/fixing-issues-noted-by-ghc-pkg-check http://stackoverflow.com/questions/7961604/fixing-issues-not...
- wging 13y ago
  Try checking the version of ghc you have installed.
freyrs3 13y ago
It's humorous that most of the article is not about monads, yet the entire discussion around it is about monads. Seriously, monads are only a small part of Haskell.
platz 13y ago
Not sure how I feel about this thread. A hundred folks who probably haven't investigated how to effectively teach adults, try to explain monads in the space of 3 tweets (probably not the best medium). And then we wonder why folks steer towards less abstract tools. For every person who visits which gains monad satori, how many have we turned away, never to return?
szany 13y ago
SET : Group MAN : Lie Group TOP : Topological Group GRP : Objects The last line should really be "GRP : Abelian Group" See http://en.wikipedia.org/wiki/Eckmann-Hilton_argument http://en.wikipedia.org/wiki/Eckmann-Hilton_argument

164 points by psibi 13y ago

ufo 13y ago

Holy shit how did I never know about the ":r" shortcut??? This changes everything.

Agree with the advice about monads. You're going to think monads are weird because the first one you encounter is used to hide a particular detail of how Haskell works in the real world, namely that Haskell can't mutate objects, but that running your program mutates the real world. Ignore this use case, because while interesting, it's a messy implementation detail, not something to model in your own code. Use monads for bailing out of computations early (Maybe/Either) or passing some state along through a computation (State). When you're comfortable with those concepts, look at ST for a generalization of what IO does. That is something you can actually use to simplify your own programs.

anon_d 13y ago
Do not agree! Monads were always this vague weird thing until I started using IO heavily. Once I was comfortable with IO, applying the abstraction to other things was obvious. I've also helped some other people learn Haskell, and being able to just explain how IO works is much easier than trying to explain the Monad abstraction.
- jrockway 13y ago
  Yes, it's easier to explain a specific concrete example rather than an abstract concept. You don't study literature learning about iambic pentameter and then ending your studies; you also read Shakespeare to see how it's applied in real life. But, you also don't learn to read by starting with Shakespeare. You start with something simpler. The IO abstraction is deep and the implementation messy. So start with State or Writer or something, and go from there.
  - anon_d 13y ago
    Sure, but IO gives you answers to the main questions that new people have. How do I write hello world? How do read a line from standard input? How can you DO things in a language without side effects? You can't even write programs without IO, and it's really not confusing. On the other hand, I think avoiding do-syntax makes sense at first.
JoshTriplett 13y ago
Exactly. IO is nearly the worst first Monad to learn, because none of the internals are visible, making it look far too magic. (Only something like Cont would be worse.) The best choice would be something like Writer or State, where you can see exactly what the abstraction hides, why you'd want it, and how it would look if done via explicit state-passing.
- jrockway 13y ago
  Yes, something like WriterT Error is a great "default state" for your functions: they can produce a correct answer, an error, and some logging information. Programmers love punting things like error handling to higher levels of their program; why not do that with logs, too? (And, given a correct implementation of Writer, if you ignore the log messages, they aren't computed. Try that with Java!)
mjn 13y ago
The State monad is what really sold me on the concept. Right before encountering a tutorial that mentioned it, I had just spent some time writing some code in Common Lisp, where I was trying to find a nice abstraction to avoid threading a state variable through absolutely everything. So this came across as "dear god, the abstraction does exist!" Whereas the IO monad at first blush comes across as "lol PLs geeks realized they had to actually do I/O", which is not as compelling, in part because that version comes across as a solution to a self-inflicted problem. It's slightly disappointing, though, that State doesn't work that well when translated back to Lisp: http://marijnhaverbeke.nl/monad.html http://marijnhaverbeke.nl/monad.html
- jrockway 13y ago
  State is exactly the right abstraction for this. When people using other languages come up with an "abstraction" for state, it is always becomes a testing/debugging nightmare. With State, it really is just a parameter to your function, which you're allowed to hide if you feel like it.

jkrems 13y ago

I really wish people would start treating languages as languages. `(m >>= f) >>= g ≡ m >>= (\x -> f x >>= g)` is not easy to understand because the symbols don't have names. I can't read it. How is "m >>= f" pronounced?

flebron 13y ago
I think of it as "feed m to f".
- platz 13y ago
  Except what gets fed to f is the 'unwrapped' value, not the whole monad
insn 13y ago
m bind f
bsamuels 13y ago
>How is "m >>= f" pronounced? The pronunciation is a sort of bestial hissing that is difficult to describe; when you say it correctly, the terminal may be slightly moist.
- jkrems 13y ago
  I'll start using it.
rollo 13y ago
Programming languages are not natural languages. And where imperative programming can benefit from something that looks like a series of instructions resembling natural language, functional, declarative programming works better with the language being closer to mathematical notation.
- jkrems 13y ago
  If I can't talk to you about it (e.g. I have to literally say "Oh, you forgot to declare a way to apply the greater than-greater-than-equal operator!"), it's hard to actually reason about a problem domain. It's like the magic moment where you go from stumbling through cryptic signs to being able to fluently read (aloud) complex math or logic formulas. I doesn't need to resolve to a normal, casual sentence you'd drop chatting with your cab driver - but there should be a way to pronounce it. P.S.: I guess what I'm trying to say is - every normal mathematical expression has a way to pronounce it. "plus", "for all x", "there exists an x", "sum of", "element of", ...

codygman 13y ago

As someone who has been learning haskell for the past 6~ months this is very valuable. I will be studying this and toying around with the examples quite a bit, thanks for this resource!

sillysaurus2 13y ago

Would someone please explain what a monad is and why they're useful, in down-to-Earth, simple language that an engineer can appreciate? I know (and use) basically every other CS concept. Monads, though, I've never bothered looking into, because it seems like everyone who talks about them can't resist the urge to use flowery descriptions of their possibilities, rather than examples of their pragmatism. Also, it's suspicious that pg has never once mentioned monads: https://www.google.com/search?q=site%3Apaulgraham.com%20%22monad%22 https://www.google.com/search?q=site%3Apaulgraham.com%20%22m... If they're useful, you'd think one of the best hackers would have said something about it. He spent a good deal of his career talking about closures, types, objects, functions, computing theory, lambda calculus, etc. But no monads. So, are they useful? Would anyone please give examples of their usefulness? EDIT: You know what's worse than hero worship? Not being able to make a reasonable argument which uses someone as an example without being accused of hero worship.

iskander 13y ago
They're a very simple abstract interface that happens to capture a surprisingly large class of data structures and computations. You need to implement two operations to make a monad: (1) take a normal value and put it in the monad (2) add a function to the pipeline of stuff being performed on the monad. If your language gives special syntax for these two functions, then you get to write generic code that does lots of different but related things depending on which monad that code gets called with. So, monads are just a handy and often-occurring interface. There's not a ton to understand here conceptually, you just use them and get used to the abstraction. edit: pg likes dynamic languages, monads don't pop up there as much. They're more useful when you (1) you have special syntax for them and (2) the type system helps you keep track of what code is not in a monad, generically using any monad, or using one particular monad. So, you'll typically only see monads in expressive/high-level static languages
- sillysaurus2 13y ago
  Ok. So if I understand correctly, I could give a monad an open file descriptor to "numbers.txt" as its value, along with a "read line" function and a "convert string to int" function, and I'd get back a list of numbers?

parallelist 13y ago

Anyone got any solutions for cabal hell? I barely use Haskell because 50%+ of everything I try to install fails and I don’t have a freaking clue how to fix it.

jbezos 13y ago
Use the new sandboxing feature of cabal: http://coldwa.st/e/blog/2013-08-20-Cabal-sandbox.html http://coldwa.st/e/blog/2013-08-20-Cabal-sandbox.html
mhitza 13y ago
If you're using cabal to install applications from hackage, it gets a bit hairy. But if you just want to resolve your dependencies mkdir project cabal sandbox init cabal install dependency cabal repl # for a ghci instance inside the sandbox Recommended is still to generate a .cabal file and specify your dependencies there.
thetwiceler 13y ago
Take a look at this [1], particularly the second answer, which links to a Github Gist for "ghc-pkg-clean." I tend to use that when I run into trouble. [1] http://stackoverflow.com/questions/7961604/fixing-issues-noted-by-ghc-pkg-check http://stackoverflow.com/questions/7961604/fixing-issues-not...
wging 13y ago
Try checking the version of ghc you have installed.

freyrs3 13y ago

It's humorous that most of the article is not about monads, yet the entire discussion around it is about monads. Seriously, monads are only a small part of Haskell.

platz 13y ago

Not sure how I feel about this thread. A hundred folks who probably haven't investigated how to effectively teach adults, try to explain monads in the space of 3 tweets (probably not the best medium). And then we wonder why folks steer towards less abstract tools. For every person who visits which gains monad satori, how many have we turned away, never to return?

szany 13y ago

SET : Group MAN : Lie Group TOP : Topological Group GRP : Objects The last line should really be "GRP : Abelian Group" See http://en.wikipedia.org/wiki/Eckmann-Hilton_argument http://en.wikipedia.org/wiki/Eckmann-Hilton_argument