10 ms·

I thought people say learning Haskell as a first language is easy because 1) you don't have do a lot of unlearning. See, you still don't understand why you wan

I thought people say learning Haskell as a first language is easy because 1) you don't have do a lot of unlearning. See, you still don't understand why you want things to mutate. Experienced programmers (in other languages) mutate things in every single line of code they write. They have to unlearn mutating things to learn this. 2) It's closer to mathematics which many people know. I think the problems you faced are actually problems because you read a book that was meant for programmers. Hell, you'll face these problems even if you read a C book that is meant for programmers. I still think, Haskell (as a language) is a good first language.

coolsunglasses 12y ago
There's less fighting the student's ego involved, but it's overall more work because there's just so much they don't know if it's their first programming language. Experienced programmers repeating the trope that it's easier to teach/learn Haskell for a new programmer are: 1. Not speaking from experience 2. Taking a lot of knowledge for granted Example - explain what a "side effect" is. Why is it a "side" effect? What's ()? Why is that "nothing"? Why does putStrLn return IO ()? That said, it's been a pleasure learning how to teach Haskell and writing the book so far.
- tel 12y ago
  I suppose there are two ways to interpret that trope. First, that it's easier to teach someone carte blanche to program at some goalpost level of skill via Haskell than other languages. Second, that it's easier to teach someone who has no knowledge of programming otherwise to understand Haskell than it is to teach someone with "imperative experience" to understand it. I wonder what your thoughts are these days on each of these. My understanding is that you have the requisite experience to talk about it, like few others! It's finally interesting to me to state that I think the best version of that trope, though one that is impractical and untestable, is that it's easier to teach a newbie to program Haskell than an experienced Java programmer ignoring some set of standard, non-linguistic training points. This is the most interesting since it gets directly at there being some kind of "imperative mindset impedance" which is presumed to exist, but it's the least testable since I'm certain nobody will ever agree on what those "non-linguistic training points" are. It's probably folly to assume they exist, even. Anyway, I'd love to hear your thoughts.
kazinator 12y ago
Even newbie computer users understand mutation, because they have moved files (or other objects, like mail box items) from one place to another, deleted or renamed them or edited their contents. Mutation is also something exhibited by everyday objects. This is modeled much better by object-oriented programming with mutable state. More importantly, the rigid typing of Haskell isn't found in the real world in which backpacks can hold dissimilar items, and donkeys can mate with horses to produce sterile offspring. Haskell is close to mathematics, sure. Many people know mathematics. However, many people do not know that mathematics which Haskell is close to! So your (2) is a slight equivocation on the term "mathematics".
- coolsunglasses 12y ago
  Most people using Haskell are using it to write imperative programs, giving up mutation specifically is less of a big deal than you'd think.
  - joe_the_user 12y ago
    I'm pretty sure I can implement any imaginable algorithm without mutation. Implementing it with any efficiency seems like a different question. A common activity in many programs is scanning a list and changing a few items based on some criteria. So far I've heard in Haskel you either duplicate the list or create a complicated data-structure that somehow essentially makes this mutation OK. Either ways seems silly - especially do what you did before but with complex dance around it.
    - coolsunglasses 12y ago
      >Implementing it with any efficiency seems like a different question. Nah, same asymptotic limitations, just different constants and patterns in what's sensible. Example: https://www.youtube.com/watch?v=6nh6LpcXGsI https://www.youtube.com/watch?v=6nh6LpcXGsI Data.Map, Data.Sequence, Data.Vector all serve for most anything you'd want.
    - gizmo686 12y ago
nnq 12y ago
> 2) It's closer to mathematics which many people know. No. They don't. Most people have the "how to" knowledge of basic math in their heads. The imperative parts like the algorithm for dividing and multiplying numbers that they run on their wetware computer. The part concerned with reasoning about "what is", the proofs part, the part mathematicians call "math" is not what most people's knowledge of math consists of. Imperative languages really are closer to how our minds work everyday. Yeah, on occasion we do some "deep thinking" about "what is" but most of the time our brain goes about things like "ok, what are the steps to do X? [...] and now I'll always label the result of the last step y [...] and when condition z happens I'll goto step s etc.". ...this is how laws, regulations, institutional processes etc. are formulated. And this how you see nature work: that place on the tree branch where you saw a bird now holds nothing (... 'null bird pointer' ?) or maybe you look around a few hours later after the storm and you see that branch is actually broken (... 'segfault' ?).
- Peaker 12y ago
  > Imperative languages really are closer to how our minds work everyday Why do you believe this? I think it is a cognitive bias at play, where you've been trained to think this way until it comes natural, and now it's hard to see it any other way. With these lens, you see imperative instructions everywhere. I randomly opened a wiki page: http://en.wikipedia.org/wiki/Sine http://en.wikipedia.org/wiki/Sine In it, you'll find a sine is not described as a series of imperative steps to compute it, but is defined as what it is. Most descriptions and models you'll find of most things are this way.
  - nnq 12y ago
    Indeed, this is how things are described in a textbook. And how they should be. But, for example, after you've learned how to draw an ellipse using a string, a pen and two pins (like https://www.youtube.com/watch?v=7UD8hOs-vaI https://www.youtube.com/watch?v=7UD8hOs-vaI) your intuition and unconscious perception of what an ellipse is will be tied to the process of producing it and a visual representation of this process, not to the arid definition of it like "a curve on a plane surrounding two focal points such that the sum of the distances to the two focal points is constant for every point on the curve". This is why people find really learning mathematics so incredibly hard, because our intuitions are process oriented. And why you can take anyone who is not what I call a "mud-mind" (people that just can't do rigorous logical thought) and and teach him/her how to write code in an imperative language until they can get something working, while making the same person understand (not memorize!) a mathematical proof or envision such a proof is just 10x times harder. I love functional programming and being able to do "what is" reasoning about programs. But I think this is just inherently hard for the human mind to do, we're not optimized for it, we're optimized for generating sequences of instructions that we send to our muscles to execute (and our muscles and bodies and mind too are obviously stateful, btw) and we're much better at generalizing this "dirty" way of thinking even for abstract pursuits like software development...

coolsunglasses 12y ago

There's less fighting the student's ego involved, but it's overall more work because there's just so much they don't know if it's their first programming language. Experienced programmers repeating the trope that it's easier to teach/learn Haskell for a new programmer are: 1. Not speaking from experience 2. Taking a lot of knowledge for granted Example - explain what a "side effect" is. Why is it a "side" effect? What's ()? Why is that "nothing"? Why does putStrLn return IO ()? That said, it's been a pleasure learning how to teach Haskell and writing the book so far.

tel 12y ago
I suppose there are two ways to interpret that trope. First, that it's easier to teach someone carte blanche to program at some goalpost level of skill via Haskell than other languages. Second, that it's easier to teach someone who has no knowledge of programming otherwise to understand Haskell than it is to teach someone with "imperative experience" to understand it. I wonder what your thoughts are these days on each of these. My understanding is that you have the requisite experience to talk about it, like few others! It's finally interesting to me to state that I think the best version of that trope, though one that is impractical and untestable, is that it's easier to teach a newbie to program Haskell than an experienced Java programmer ignoring some set of standard, non-linguistic training points. This is the most interesting since it gets directly at there being some kind of "imperative mindset impedance" which is presumed to exist, but it's the least testable since I'm certain nobody will ever agree on what those "non-linguistic training points" are. It's probably folly to assume they exist, even. Anyway, I'd love to hear your thoughts.

kazinator 12y ago

Even newbie computer users understand mutation, because they have moved files (or other objects, like mail box items) from one place to another, deleted or renamed them or edited their contents. Mutation is also something exhibited by everyday objects. This is modeled much better by object-oriented programming with mutable state. More importantly, the rigid typing of Haskell isn't found in the real world in which backpacks can hold dissimilar items, and donkeys can mate with horses to produce sterile offspring. Haskell is close to mathematics, sure. Many people know mathematics. However, many people do not know that mathematics which Haskell is close to! So your (2) is a slight equivocation on the term "mathematics".

coolsunglasses 12y ago
Most people using Haskell are using it to write imperative programs, giving up mutation specifically is less of a big deal than you'd think.
- joe_the_user 12y ago
  I'm pretty sure I can implement any imaginable algorithm without mutation. Implementing it with any efficiency seems like a different question. A common activity in many programs is scanning a list and changing a few items based on some criteria. So far I've heard in Haskel you either duplicate the list or create a complicated data-structure that somehow essentially makes this mutation OK. Either ways seems silly - especially do what you did before but with complex dance around it.
  - coolsunglasses 12y ago
    >Implementing it with any efficiency seems like a different question. Nah, same asymptotic limitations, just different constants and patterns in what's sensible. Example: https://www.youtube.com/watch?v=6nh6LpcXGsI https://www.youtube.com/watch?v=6nh6LpcXGsI Data.Map, Data.Sequence, Data.Vector all serve for most anything you'd want.
  - gizmo686 12y ago

nnq 12y ago

> 2) It's closer to mathematics which many people know. No. They don't. Most people have the "how to" knowledge of basic math in their heads. The imperative parts like the algorithm for dividing and multiplying numbers that they run on their wetware computer. The part concerned with reasoning about "what is", the proofs part, the part mathematicians call "math" is not what most people's knowledge of math consists of. Imperative languages really are closer to how our minds work everyday. Yeah, on occasion we do some "deep thinking" about "what is" but most of the time our brain goes about things like "ok, what are the steps to do X? [...] and now I'll always label the result of the last step y [...] and when condition z happens I'll goto step s etc.". ...this is how laws, regulations, institutional processes etc. are formulated. And this how you see nature work: that place on the tree branch where you saw a bird now holds nothing (... 'null bird pointer' ?) or maybe you look around a few hours later after the storm and you see that branch is actually broken (... 'segfault' ?).

Peaker 12y ago
> Imperative languages really are closer to how our minds work everyday Why do you believe this? I think it is a cognitive bias at play, where you've been trained to think this way until it comes natural, and now it's hard to see it any other way. With these lens, you see imperative instructions everywhere. I randomly opened a wiki page: http://en.wikipedia.org/wiki/Sine http://en.wikipedia.org/wiki/Sine In it, you'll find a sine is not described as a series of imperative steps to compute it, but is defined as what it is. Most descriptions and models you'll find of most things are this way.
- nnq 12y ago
  Indeed, this is how things are described in a textbook. And how they should be. But, for example, after you've learned how to draw an ellipse using a string, a pen and two pins (like https://www.youtube.com/watch?v=7UD8hOs-vaI https://www.youtube.com/watch?v=7UD8hOs-vaI) your intuition and unconscious perception of what an ellipse is will be tied to the process of producing it and a visual representation of this process, not to the arid definition of it like "a curve on a plane surrounding two focal points such that the sum of the distances to the two focal points is constant for every point on the curve". This is why people find really learning mathematics so incredibly hard, because our intuitions are process oriented. And why you can take anyone who is not what I call a "mud-mind" (people that just can't do rigorous logical thought) and and teach him/her how to write code in an imperative language until they can get something working, while making the same person understand (not memorize!) a mathematical proof or envision such a proof is just 10x times harder. I love functional programming and being able to do "what is" reasoning about programs. But I think this is just inherently hard for the human mind to do, we're not optimized for it, we're optimized for generating sequences of instructions that we send to our muscles to execute (and our muscles and bodies and mind too are obviously stateful, btw) and we're much better at generalizing this "dirty" way of thinking even for abstract pursuits like software development...