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 wa

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.