4 ms·

Sure it's a metaphor and as I state, there's nothing wrong with using the railway analogy, but renaming 'monads' as 'Railway Oriented Programming' is having the

by louthy 3y ago

Sure it's a metaphor and as I state, there's nothing wrong with using the railway analogy, but renaming 'monads' as 'Railway Oriented Programming' is having the effect that newbies to FP-land think that's what _programming-with-monads_ is _called_. Then they try to have discussions with others in FP-land and realise they don't have the lexicon to talk about FP because they've been taught some spurious terminology. This is a monad tutorial, it is over 150 slides worth of explanation (probably the largest 'Yet Another Monad Tutorial' I've seen yet), there's no reason to leave the reader thinking they've learned some new concept called 'Railway Oriented Programming'.

xupybd 3y ago
Specifically this is the error/result monad. This was the first description that made sense to me as a newbie to all of this. Monad was a scary word. This helped me understand.
FrustratedMonky 3y ago
I was being bit harsh. Upon reflection I think you have a good point. When learning about functional programming, the metaphors did help. But then later it was hard to recognize them in other languages that used different metaphors for same thing. (maybe all language is metaphor?). So if F# Computation Expression, was little more expressly outlined as a 'Monad', and how, maybe that would help. It just can't be all at once when learning. Same for <Option> and error handling. There is the baby-step phase, then growing into details. So this railway presentation might have been helped by a little cross-connecting the 'simple helpful metaphors', with the 'technically correct words you'd find in a math book or something'. Like a few slides at beginning or end, with further reading or examples showing 'simple metaphor' = 'over complicated word'. This does happen in objects. How many 'typical introduction' books spend a lot of time talking about Ducks and Dogs, and Quacking and Barking, Is-A, Has-A, before it gets into technical terminology? People still talk about 'Duck Typing'. Not the technical word. Maybe that is bad also.
- louthy 3y ago
  Thank you for that. One series that I thought did this really well was the Eric Meijer (father of LINQ in C#) lectures on FP fundamentals [1]. It was very much for OO programmers to get up to speed with FP and it was taught using Haskell. He goes through the series, building up a parser in Haskell, and then at the end (or a reasonable way through) he says "and that's a monad". Never once mentioning it until the watcher had grokked all the concepts up until that point. That 'big reveal' idea I think is probably the best way to do a monad tutorial, because it forces the tutor to stick to the motivations and the fundamentals. [1] https://www.youtube.com/watch?v=UIUlFQH4Cvo&list=PLoJC20gNfC2gpI7Dl6fg8uj1a-wfnWTH8 https://www.youtube.com/watch?v=UIUlFQH4Cvo&list=PLoJC20gNfC...

by louthy 3y ago

xupybd 3y ago

Specifically this is the error/result monad. This was the first description that made sense to me as a newbie to all of this. Monad was a scary word. This helped me understand.

FrustratedMonky 3y ago

I was being bit harsh. Upon reflection I think you have a good point. When learning about functional programming, the metaphors did help. But then later it was hard to recognize them in other languages that used different metaphors for same thing. (maybe all language is metaphor?). So if F# Computation Expression, was little more expressly outlined as a 'Monad', and how, maybe that would help. It just can't be all at once when learning. Same for <Option> and error handling. There is the baby-step phase, then growing into details. So this railway presentation might have been helped by a little cross-connecting the 'simple helpful metaphors', with the 'technically correct words you'd find in a math book or something'. Like a few slides at beginning or end, with further reading or examples showing 'simple metaphor' = 'over complicated word'. This does happen in objects. How many 'typical introduction' books spend a lot of time talking about Ducks and Dogs, and Quacking and Barking, Is-A, Has-A, before it gets into technical terminology? People still talk about 'Duck Typing'. Not the technical word. Maybe that is bad also.

louthy 3y ago
Thank you for that. One series that I thought did this really well was the Eric Meijer (father of LINQ in C#) lectures on FP fundamentals [1]. It was very much for OO programmers to get up to speed with FP and it was taught using Haskell. He goes through the series, building up a parser in Haskell, and then at the end (or a reasonable way through) he says "and that's a monad". Never once mentioning it until the watcher had grokked all the concepts up until that point. That 'big reveal' idea I think is probably the best way to do a monad tutorial, because it forces the tutor to stick to the motivations and the fundamentals. [1] https://www.youtube.com/watch?v=UIUlFQH4Cvo&list=PLoJC20gNfC2gpI7Dl6fg8uj1a-wfnWTH8 https://www.youtube.com/watch?v=UIUlFQH4Cvo&list=PLoJC20gNfC...