5 ms·

My own experiences with Haskell have been... unfortunate (either I am too stupid or my brain has been damaged by imperative programming languages). But this is

by krylon 12y ago

My own experiences with Haskell have been... unfortunate (either I am too stupid or my brain has been damaged by imperative programming languages). But this is easily the funniest introduction to any piece of software I have ever come across.

saidajigumi 12y ago
A key problem that I only realized after having recently returned to Haskell after a long absence is that our expectations about learning new programming languages and/or platforms set us up for failure. For example, I generally eat new programming languages for breakfast (or bedtime reading, really). But I've noticed that Haskell isn't like picking up the PL flavor-of-the-week. Instead, it feels much more like learning a new area of mathematics. It's common with a novel area of math to just have to bang your head on it for a while. If you hang on through that phase, the cognitive switch flips and then you wonder how it was ever difficult. So it goes with a language that feels much closer to math reified, and for which most of the patterns we're used to from our imperative platform experiences just don't apply. One good piece of advice I've seen a few places is to work through the U. Penn CIS 194 lectures and homeworks[1]. The lecture notes refer to other good resources for reading, including chapters of http://learnyouahaskell.com/ http://learnyouahaskell.com/ and more. But the real winner is just taking the time to just work through the homework problems. It's annoying at times. "Hey, (don't/shouldn't?) I know this stuff already?" But you'll probably get stuck at places, and those places pinpoint precisely the missing foundation blocks you'll need to reason successfully about your Haskell programs. Stick it out, but don't be afraid to search the web for help if you get too stuck. We self-taught types don't get office hours to keep us pointed in the right direction. [1] This term in particular gets referenced: http://www.seas.upenn.edu/~cis194/spring13/lectures.html http://www.seas.upenn.edu/~cis194/spring13/lectures.html
- rjblackman 12y ago
  further to this "bitemyapp" has a very good starting point for haskell newcomers https://github.com/bitemyapp/learnhaskell https://github.com/bitemyapp/learnhaskell
  - krylon 12y ago
    Hehe, I just took a look and found this very encouraging statement: "Slow learners are often the most thorough learners, this is something to celebrate!" That's it, I'm going to give Haskell another try!
- krylon 12y ago
  Thanks for the advice! I agree on the math part (which is the biggest problem for me, since I do not exactly have a strong math background). Haskell requires one to think in very different ways from C or similar languages (compared to the difference to Haskell, the structured (C) vs. OO (say, Python or Ruby) difference seems negligible. If one already knows C++, learning the basics of Java is trivial (the main problem becomes learning about the standard library plus third party libraries). If one knows C/C++ and a Unix shell, learning Perl is at least manageable (is that how you spell that word?). Lisp fans like to refer to their language of choice as something akin to Alien technology, but again, compared to Haskell, Lisp feels much more "terrestrial" (Common Lisp and Emacs Lisp, at least, my knowledge of Scheme is rather limited). Now that I think about it, the real problem for me seems to be monads. Without having /some/ kind of side effects, you cannot write an even remotely useful program, and I never really got them. I once had the feeling I was really close, but then the toy program I was working on blew up in my face, thereby telling me I had probably not been as close as I had thought. Another thing about Haskell (and - as far as I can tell, OCaml) that is /very/ different from the mainstream crowd of languages is the type system. I have a feeling that an idiomatic Haskell program would make far heavier use of the type system to model your problem than even extreme examples of object-oriented design (and without becoming as confusing as the more class-hierarchy-happy OO programs I have seen). (Let me stress that I really adore Haskell's type system. If there was a conventional structured programming language with a type system like Haskell's, I would probably be all over it, as would many other programmers, I guess. I have wondered on occasion if you could have one without the other (immutability and such).) Maybe I'll retcon learning Haskell on my list of New Year's resolutions. In all fairness, understanding Lisp took me about three to four years of looking at it once or twice a year, and understanding how pointers work in C also took me a lot longer than I am comfortable admitting. ;-) I can be very persistent if I really want to know something.
  - progman 12y ago
    > Now that I think about it, the real problem for me seems to be monads. A very good quick explanation of Monads is given in the first long answer (number 245) at http://stackoverflow.com/questions/28139259/why-do-we-need-monads http://stackoverflow.com/questions/28139259/why-do-we-need-m... Comprehensive introduction: https://wiki.haskell.org/All_About_Monads https://wiki.haskell.org/All_About_Monads
tjradcliffe 12y ago
Someone on HN suggested this guide to Haskell a few days ago: http://en.wikibooks.org/wiki/Haskell http://en.wikibooks.org/wiki/Haskell I'm finding it the first useful introduction to the language I've encountered. Like you, my experiences have been less than exemplary, and I'm way too arrogant to accept that I'm either stupid or brain damaged. Every year or so I take a run at Haskell, and this time I think I'm going to get it. I know a dozen-odd languages, including a fairly expert grasp of APL and Mathematica, both of which are a bit odd in their approach to life. Haskell is genuinely weirder than most, and the entire Haskell community's apparent total ignorance of the of the most rudimentary principles of pedagogy make the learning curve unreasonably steep. The fact that most Haskell tutorials start out with contradictions is an example of this. Pedagogy 101: don't make false claims about the subject in terms of the concepts you can reasonably expect the student to have. For example, electrical engineers should never introduce the concept of "negative resistance" by starting off talking about "negative resistance". They should first introduce the concept of generalized resistance (dV/dI rather than V/I) and then show how generalized resistance can be negative. To tell a student that there is such a thing as "negative resistance" when you know full well that "resistance" in the student's mind is not generalized but defined by a relation such that it cannot possibly be negative is simply incompetence on the part of the teacher. By the same token, it doesn't matter one whit that "the language" is side-effect free when "the runtime" implements side effects when the student can reasonably expected to understand "language" to mean "language plus runtime" as it is in every other case. Actually: it does matter, and it should be explained in those terms. Otherwise students will rightly reject the language as some kind of snake-oil gibberish promoted by arrogant hucksters. No Haskell tutorial should ever make the false claim that "the language" (as understood by any reasonable student) is "purely functional". Students aren't stupid and haven't been brain-damaged by imperative languages. They know that "the language" covers the whole package in ordinary parlance, including the runtime. When we talk about Perl or Python or C++ or FORTRAN that's what we mean. There is absolutely no basis for anyone to ever assume any other understanding on the part of the student. So tell people "Haskell is implemented in such a way that it can be treated as a purely functional language for the purpose of static analysis even though at runtime there are various clever tricks that still allow it to implement side-effects like IO". That is a truthful statement. "Haskell is a pure functional language and for every function call the return value depends only on its arguments" is false, outside of a tortured and bizarre interpretation of the terminology that has no apparent purpose but to misrepresent reality to outsiders. There are some pretty cool things about Haskell. The type inference system is powerful, useful and interesting. It's remarkable to see how far a nominally (but not actually) purely functional language can be pushed, and the way various hacks are used to overcome the limitations of purely functional languages is incredibly clever. The creators of Haskell should be celebrating those feats, not hiding behind false claims that the language+runtime is "truly" purely functional when it manifestly is not. Edit: Concrete example: to be a purely functional language function values must depend only on their arguments. Here is an example of a Haskell function whose value does not depend only on its arguments: notPurelyFunctional :: Double -> IO Double notPurelyFunctional x = do z <- putStrLn "Please enter a number: " name <- getLine let y = read name ::Double return (x+y) If we do something like: value1 <- notPurelyFunctional 5.0 value2 <- notPurelyFunctional 5.0 value1 == value2 we have no idea what "value1 == value2" will evaluate to, so either: a) The above code is not part of the Haskell language (which would be weird as it all runs just fine under GHC, and "stuff that runs under GHC" is what any ordinary person means by "Haskell") or b) Haskell is not a "pure functional language" the way that term is ordinarily understood, which is: "calling the same function multiple times with the same arguments will always produce the same results" (in which case "value1 == value2" must evaluate to "True", which it does not in general when running the above code).

by krylon 12y ago

saidajigumi 12y ago

A key problem that I only realized after having recently returned to Haskell after a long absence is that our expectations about learning new programming languages and/or platforms set us up for failure. For example, I generally eat new programming languages for breakfast (or bedtime reading, really). But I've noticed that Haskell isn't like picking up the PL flavor-of-the-week. Instead, it feels much more like learning a new area of mathematics. It's common with a novel area of math to just have to bang your head on it for a while. If you hang on through that phase, the cognitive switch flips and then you wonder how it was ever difficult. So it goes with a language that feels much closer to math reified, and for which most of the patterns we're used to from our imperative platform experiences just don't apply. One good piece of advice I've seen a few places is to work through the U. Penn CIS 194 lectures and homeworks[1]. The lecture notes refer to other good resources for reading, including chapters of http://learnyouahaskell.com/ http://learnyouahaskell.com/ and more. But the real winner is just taking the time to just work through the homework problems. It's annoying at times. "Hey, (don't/shouldn't?) I know this stuff already?" But you'll probably get stuck at places, and those places pinpoint precisely the missing foundation blocks you'll need to reason successfully about your Haskell programs. Stick it out, but don't be afraid to search the web for help if you get too stuck. We self-taught types don't get office hours to keep us pointed in the right direction. [1] This term in particular gets referenced: http://www.seas.upenn.edu/~cis194/spring13/lectures.html http://www.seas.upenn.edu/~cis194/spring13/lectures.html

rjblackman 12y ago
further to this "bitemyapp" has a very good starting point for haskell newcomers https://github.com/bitemyapp/learnhaskell https://github.com/bitemyapp/learnhaskell
- krylon 12y ago
  Hehe, I just took a look and found this very encouraging statement: "Slow learners are often the most thorough learners, this is something to celebrate!" That's it, I'm going to give Haskell another try!
krylon 12y ago
Thanks for the advice! I agree on the math part (which is the biggest problem for me, since I do not exactly have a strong math background). Haskell requires one to think in very different ways from C or similar languages (compared to the difference to Haskell, the structured (C) vs. OO (say, Python or Ruby) difference seems negligible. If one already knows C++, learning the basics of Java is trivial (the main problem becomes learning about the standard library plus third party libraries). If one knows C/C++ and a Unix shell, learning Perl is at least manageable (is that how you spell that word?). Lisp fans like to refer to their language of choice as something akin to Alien technology, but again, compared to Haskell, Lisp feels much more "terrestrial" (Common Lisp and Emacs Lisp, at least, my knowledge of Scheme is rather limited). Now that I think about it, the real problem for me seems to be monads. Without having /some/ kind of side effects, you cannot write an even remotely useful program, and I never really got them. I once had the feeling I was really close, but then the toy program I was working on blew up in my face, thereby telling me I had probably not been as close as I had thought. Another thing about Haskell (and - as far as I can tell, OCaml) that is /very/ different from the mainstream crowd of languages is the type system. I have a feeling that an idiomatic Haskell program would make far heavier use of the type system to model your problem than even extreme examples of object-oriented design (and without becoming as confusing as the more class-hierarchy-happy OO programs I have seen). (Let me stress that I really adore Haskell's type system. If there was a conventional structured programming language with a type system like Haskell's, I would probably be all over it, as would many other programmers, I guess. I have wondered on occasion if you could have one without the other (immutability and such).) Maybe I'll retcon learning Haskell on my list of New Year's resolutions. In all fairness, understanding Lisp took me about three to four years of looking at it once or twice a year, and understanding how pointers work in C also took me a lot longer than I am comfortable admitting. ;-) I can be very persistent if I really want to know something.
- progman 12y ago
  > Now that I think about it, the real problem for me seems to be monads. A very good quick explanation of Monads is given in the first long answer (number 245) at http://stackoverflow.com/questions/28139259/why-do-we-need-monads http://stackoverflow.com/questions/28139259/why-do-we-need-m... Comprehensive introduction: https://wiki.haskell.org/All_About_Monads https://wiki.haskell.org/All_About_Monads

tjradcliffe 12y ago

Someone on HN suggested this guide to Haskell a few days ago: http://en.wikibooks.org/wiki/Haskell http://en.wikibooks.org/wiki/Haskell I'm finding it the first useful introduction to the language I've encountered. Like you, my experiences have been less than exemplary, and I'm way too arrogant to accept that I'm either stupid or brain damaged. Every year or so I take a run at Haskell, and this time I think I'm going to get it. I know a dozen-odd languages, including a fairly expert grasp of APL and Mathematica, both of which are a bit odd in their approach to life. Haskell is genuinely weirder than most, and the entire Haskell community's apparent total ignorance of the of the most rudimentary principles of pedagogy make the learning curve unreasonably steep. The fact that most Haskell tutorials start out with contradictions is an example of this. Pedagogy 101: don't make false claims about the subject in terms of the concepts you can reasonably expect the student to have. For example, electrical engineers should never introduce the concept of "negative resistance" by starting off talking about "negative resistance". They should first introduce the concept of generalized resistance (dV/dI rather than V/I) and then show how generalized resistance can be negative. To tell a student that there is such a thing as "negative resistance" when you know full well that "resistance" in the student's mind is not generalized but defined by a relation such that it cannot possibly be negative is simply incompetence on the part of the teacher. By the same token, it doesn't matter one whit that "the language" is side-effect free when "the runtime" implements side effects when the student can reasonably expected to understand "language" to mean "language plus runtime" as it is in every other case. Actually: it does matter, and it should be explained in those terms. Otherwise students will rightly reject the language as some kind of snake-oil gibberish promoted by arrogant hucksters. No Haskell tutorial should ever make the false claim that "the language" (as understood by any reasonable student) is "purely functional". Students aren't stupid and haven't been brain-damaged by imperative languages. They know that "the language" covers the whole package in ordinary parlance, including the runtime. When we talk about Perl or Python or C++ or FORTRAN that's what we mean. There is absolutely no basis for anyone to ever assume any other understanding on the part of the student. So tell people "Haskell is implemented in such a way that it can be treated as a purely functional language for the purpose of static analysis even though at runtime there are various clever tricks that still allow it to implement side-effects like IO". That is a truthful statement. "Haskell is a pure functional language and for every function call the return value depends only on its arguments" is false, outside of a tortured and bizarre interpretation of the terminology that has no apparent purpose but to misrepresent reality to outsiders. There are some pretty cool things about Haskell. The type inference system is powerful, useful and interesting. It's remarkable to see how far a nominally (but not actually) purely functional language can be pushed, and the way various hacks are used to overcome the limitations of purely functional languages is incredibly clever. The creators of Haskell should be celebrating those feats, not hiding behind false claims that the language+runtime is "truly" purely functional when it manifestly is not. Edit: Concrete example: to be a purely functional language function values must depend only on their arguments. Here is an example of a Haskell function whose value does not depend only on its arguments: notPurelyFunctional :: Double -> IO Double notPurelyFunctional x = do z <- putStrLn "Please enter a number: " name <- getLine let y = read name ::Double return (x+y) If we do something like: value1 <- notPurelyFunctional 5.0 value2 <- notPurelyFunctional 5.0 value1 == value2 we have no idea what "value1 == value2" will evaluate to, so either: a) The above code is not part of the Haskell language (which would be weird as it all runs just fine under GHC, and "stuff that runs under GHC" is what any ordinary person means by "Haskell") or b) Haskell is not a "pure functional language" the way that term is ordinarily understood, which is: "calling the same function multiple times with the same arguments will always produce the same results" (in which case "value1 == value2" must evaluate to "True", which it does not in general when running the above code).