5 ms·

I have a good 30 years of C/C++ under my belt and have been learning Haskell for the last 4 years. You can write a buggy version of a program in C after spendin

I have a good 30 years of C/C++ under my belt and have been learning Haskell for the last 4 years. You can write a buggy version of a program in C after spending an afternoon learning it. You can write a bug-free version in haskell but you'll be spending a few weeks worrying about monads. I think C just looks easier because you can learn enough to be dangerous without much effort, getting to a level where you can write reasonably safe C will take a lot longer than getting to that same level in Haskell.

the_only_law 5y ago
After trying to join in on the monad jokes for forever, I opened up the the Wikipedia page on Monads (in the functional programming context, not the page in raw category theory) and it actually kinda made sense.
- exdsq 5y ago
  The problem that made monads make sense for me was when I had to chain (err, val) tuples for six or seven functions that only took val and handling the (err, _) bit was awkward. Someone showed how to rewrite it using monads to handle that without the boilerplate and voila.
  - javert 5y ago
    If someone would make a tutorial that replicates the process you just described, that might be a good way to teach monads.
    - ghayes 5y ago
      I strongly suggest starting with a language like Elm to get into FP, since you start to use `map` and `andThen` quite often, but you also get sick of writing `a |> Result.andThen fn1 |> Result.andThen fn2`. This can help a programmer realize why it might be better to have a concise syntax for this, like: myFun : String -> Result String Int myFun a = do b <- fn1 a c <- fn2 b return c That said, I think the other problem with Haskell is the definition of the bind operator: it is not obvious to a beginner which concrete function is actually being called for each monadic operation. Idris2, for instance, lets you specify the bind operator in its do notation[0]. [0] https://idris2.readthedocs.io/en/latest/tutorial/interfaces.html https://idris2.readthedocs.io/en/latest/tutorial/interfaces....
    - exdsq 5y ago
      I think it'd become Just Another Monad Tutorial. Its something that clicks after a bit of FP programming without monads. Simon Peyton-Jones wrote a good paper about how IO worked prior to Monads which is nice - context helps with these things. I remember struggling to understand OO until I got my first junior dev role so I do think it's just practice practice practice to get through these things.
    - hwayne 5y ago
      IMO it's probably better to teach the use of applicatives first and then monads.
    - akdor1154 5y ago
      The Railway Oriented Programming section in F# For Fun And Profit is basically this.
- ModernMech 5y ago
  I like the way that "Learn You a Haskell" puts it: "If we have a fancy value and a function that takes a normal value but returns a fancy value, how do we feed that fancy value into the function?" That's basically all a monad is. If you know what map() does (in Haskell terms, map is a "functor"), then you know what a monad is, as it's just a fancy map(). I'll put it in Rust terms: let x: Option<u8> = Some(5); fn foo(x: u8) -> Option<u8> {...} How do we apply the function foo to x? That's what monads are for.

the_only_law 5y ago

After trying to join in on the monad jokes for forever, I opened up the the Wikipedia page on Monads (in the functional programming context, not the page in raw category theory) and it actually kinda made sense.

exdsq 5y ago
The problem that made monads make sense for me was when I had to chain (err, val) tuples for six or seven functions that only took val and handling the (err, _) bit was awkward. Someone showed how to rewrite it using monads to handle that without the boilerplate and voila.
- javert 5y ago
  If someone would make a tutorial that replicates the process you just described, that might be a good way to teach monads.
  - ghayes 5y ago
    I strongly suggest starting with a language like Elm to get into FP, since you start to use `map` and `andThen` quite often, but you also get sick of writing `a |> Result.andThen fn1 |> Result.andThen fn2`. This can help a programmer realize why it might be better to have a concise syntax for this, like: myFun : String -> Result String Int myFun a = do b <- fn1 a c <- fn2 b return c That said, I think the other problem with Haskell is the definition of the bind operator: it is not obvious to a beginner which concrete function is actually being called for each monadic operation. Idris2, for instance, lets you specify the bind operator in its do notation[0]. [0] https://idris2.readthedocs.io/en/latest/tutorial/interfaces.html https://idris2.readthedocs.io/en/latest/tutorial/interfaces....
  - exdsq 5y ago
    I think it'd become Just Another Monad Tutorial. Its something that clicks after a bit of FP programming without monads. Simon Peyton-Jones wrote a good paper about how IO worked prior to Monads which is nice - context helps with these things. I remember struggling to understand OO until I got my first junior dev role so I do think it's just practice practice practice to get through these things.
  - hwayne 5y ago
    IMO it's probably better to teach the use of applicatives first and then monads.
  - akdor1154 5y ago
    The Railway Oriented Programming section in F# For Fun And Profit is basically this.
ModernMech 5y ago
I like the way that "Learn You a Haskell" puts it: "If we have a fancy value and a function that takes a normal value but returns a fancy value, how do we feed that fancy value into the function?" That's basically all a monad is. If you know what map() does (in Haskell terms, map is a "functor"), then you know what a monad is, as it's just a fancy map(). I'll put it in Rust terms: let x: Option<u8> = Some(5); fn foo(x: u8) -> Option<u8> {...} How do we apply the function foo to x? That's what monads are for.