3 ms·

I do believe that Haskell is the wrong language to learn functional programming principles. Right off of the bat Haskell forces learners to use monads for IO. M

I do believe that Haskell is the wrong language to learn functional programming principles. Right off of the bat Haskell forces learners to use monads for IO. Monads are an advanced concept; too advanced for beginners. If learners end up do kind of getting the IO monad, a big number of them actually end up not being able to understand why it's good or even understanding what a monad is completely... and see it as a pointless overcomplicated abstraction. I knew a person who learned Haskell then moved on to javascript due to the wall he hit while trying to understand monads. I've looked at his javascript code and his idea of functional programming is just littering his imperative javascript code with maps, reduces and filters. Thanks to redux, a lot of people are getting a broken view of what functional programming really is via javascript. If you think you've learned functional programming via react/redux and javascript... chances are you haven't really understood it yet. Ask yourself, why is functional programming called functional programming and not called immutable programming? If you don't know the answer... you haven't really grokked functional programming yet. The right language? Racket maybe?

arca_vorago 9y ago
I'm very interested in FP but I'm a sysadmin, not a dev, so I had to do a lot of reading. My conclusion is racket would be good for teaching indeed, but I think its ecosystem is a bit too academic though it is getting better. Instead, I think I would offer guile scheme as a language with some good, active projects to help on, such as the new cron replacement mcron. I would probably also offer elixir and some lisp variant. It was actually lisp that got me so interested in FP because I saw how much it was being used in AI research. That said, I think its worth noting Haskell is the only one I've seen listed here that is pure FP. So if one wanted to really use FP, it might be worth wading through the maze like Haskell ecosystem, but I don't think for teaching.
yawaramin 9y ago
I disagree that you have to learn monads for IO. I know some tutorials mention monads right off the bat while teaching IO but that is not a recommended teaching approach. For IO what you would need to learn is that all IO actions are values of the `IO` type and they can be sequenced together for guaranteed ordering using the `do` notation. That's it. No monads. We can introduce monads after we show using the same `do` notation for lists, `Maybe`s, and `IO`.
- crimsonalucard 9y ago
  >For IO what you would need to learn is that all IO actions are values of the `IO` type and they can be sequenced together for guaranteed ordering using the `do` notation. That's it. No monads. We can introduce monads after we show using the same `do` notation for lists, `Maybe`s, and `IO`. This is an awkward teaching approach. Forcing learners to use advanced concepts without fully understanding them. Why can't haskell just have a print function that returns a void? How come when I use haskell with input it starts polluting the input with this IO thing? This all seems stupid initially and it takes a lot of learning to understand why things are done this way.... I mean that person I know thinks javascript is better than haskell because console.log("hello") is ten times more straightforward.
  - yawaramin 9y ago
    I disagree that it's forcing learners to use advanced concepts. It's giving them syntax sugar and a fairly clear introductory explanation (IO is done only with the `IO` type for safety reasons) and giving them all the capabilities of IO in other languages straight from day one. Forgetting about types for a second, can you really say that `putStrLn "hello"` is harder to understand than `console.log("hello")`? Trust me when I say this, plenty of people have taught Haskell to kids and the result has always been that they pick it up easily. Programmers from other backgrounds worry away too much of their mental capacity thinking about monads. Stop worrying about it and just hack away.
    - crimsonalucard 9y ago
      Understanding a pattern is different from copying a pattern. Our disagreement lies not with kids copying a pattern but with people fully comprehending the philosophy and true nature of the monad abstraction. This is not easy for a beginner. Allow me to elucidate: Here is a an example of a trivial operation in imperative programming that becomes a bit more complicated in Haskell: Create a function that prints everything in an array: naive implementation in haskell (won't work): printElements arrayOfStrings= map putStrLn arrayOfStrings main = printElements ["Hello", "World"] True implementation: printElements [] = return () printElements x:xs = (putStrLn x) >> (printElements xs) main = printElements ["Hello", "World"] The second implementation requires understanding of types and the IO monad while the first implementation is a naive and broken implementation that most people turn to when learning Haskell. It is not trivial to explain to a person why it must be done the second way... All of this and all we were doing was printing something to the console! It's too much! Monads aren't even a required part of functional programming. Haskell is not a great language to learn about functional programming.

arca_vorago 9y ago

I'm very interested in FP but I'm a sysadmin, not a dev, so I had to do a lot of reading. My conclusion is racket would be good for teaching indeed, but I think its ecosystem is a bit too academic though it is getting better. Instead, I think I would offer guile scheme as a language with some good, active projects to help on, such as the new cron replacement mcron. I would probably also offer elixir and some lisp variant. It was actually lisp that got me so interested in FP because I saw how much it was being used in AI research. That said, I think its worth noting Haskell is the only one I've seen listed here that is pure FP. So if one wanted to really use FP, it might be worth wading through the maze like Haskell ecosystem, but I don't think for teaching.

yawaramin 9y ago

I disagree that you have to learn monads for IO. I know some tutorials mention monads right off the bat while teaching IO but that is not a recommended teaching approach. For IO what you would need to learn is that all IO actions are values of the `IO` type and they can be sequenced together for guaranteed ordering using the `do` notation. That's it. No monads. We can introduce monads after we show using the same `do` notation for lists, `Maybe`s, and `IO`.

crimsonalucard 9y ago
>For IO what you would need to learn is that all IO actions are values of the `IO` type and they can be sequenced together for guaranteed ordering using the `do` notation. That's it. No monads. We can introduce monads after we show using the same `do` notation for lists, `Maybe`s, and `IO`. This is an awkward teaching approach. Forcing learners to use advanced concepts without fully understanding them. Why can't haskell just have a print function that returns a void? How come when I use haskell with input it starts polluting the input with this IO thing? This all seems stupid initially and it takes a lot of learning to understand why things are done this way.... I mean that person I know thinks javascript is better than haskell because console.log("hello") is ten times more straightforward.
- yawaramin 9y ago
  I disagree that it's forcing learners to use advanced concepts. It's giving them syntax sugar and a fairly clear introductory explanation (IO is done only with the `IO` type for safety reasons) and giving them all the capabilities of IO in other languages straight from day one. Forgetting about types for a second, can you really say that `putStrLn "hello"` is harder to understand than `console.log("hello")`? Trust me when I say this, plenty of people have taught Haskell to kids and the result has always been that they pick it up easily. Programmers from other backgrounds worry away too much of their mental capacity thinking about monads. Stop worrying about it and just hack away.
  - crimsonalucard 9y ago
    Understanding a pattern is different from copying a pattern. Our disagreement lies not with kids copying a pattern but with people fully comprehending the philosophy and true nature of the monad abstraction. This is not easy for a beginner. Allow me to elucidate: Here is a an example of a trivial operation in imperative programming that becomes a bit more complicated in Haskell: Create a function that prints everything in an array: naive implementation in haskell (won't work): printElements arrayOfStrings= map putStrLn arrayOfStrings main = printElements ["Hello", "World"] True implementation: printElements [] = return () printElements x:xs = (putStrLn x) >> (printElements xs) main = printElements ["Hello", "World"] The second implementation requires understanding of types and the IO monad while the first implementation is a naive and broken implementation that most people turn to when learning Haskell. It is not trivial to explain to a person why it must be done the second way... All of this and all we were doing was printing something to the console! It's too much! Monads aren't even a required part of functional programming. Haskell is not a great language to learn about functional programming.