3 ms·
"mitchty" on Lobste.rs told me I should just read the source material from Wadler instead of the various metaphors and tutorials. Since jxub posted it here, I f
by nickpsecurity 9y ago
"mitchty" on Lobste.rs told me I should just read the source material from Wadler instead of the various metaphors and tutorials. Since jxub posted it here, I figured I'd go ahead and try. I'll admit Wadler did a terrific job trying to explain it. I don't get it after one read from imperative background. It does seem a lot more clear, though, than many attempts to dumb the material down. He gives useful examples in both functional and imperative styles. We see why imperative makes some things easier, exactly why they're harder in functional style, and then how monad form solves that problem.
The monad itself is still weird. That we have different examples, application, and definitions are a good combo that might help it click if I think on it more just going through the steps of his examples or similar programs. Might help to learn functional programming first esp to get used to things like let/binding which he draws on. Although he avoids reliance on category theory and Haskell, he still might expect people to know basics of functional programming given how he describes it. So, a good paper like this may reduce the problem down to (a) learn functional programming or, if time-constrained folks are lucky, (b) find a few tutorials on just the concepts he uses here done in ways that imperative programmers can approach. Lambda's, binding, and typing seem to be the core operators on top of functions and expressions that we're familiar with. I say typing since types work differently in various languages. Gotta understand how he's using types along with their interactions with those examples and monads.
- mitchty 9y agoThats me here too! >.< Yeah the hidden subtext here was my presumption in that suggestion was someone was learning monads in Haskell and has at least a basic understanding of Haskell. Sorry if those papers threw you into the deep end. Monads really were thrown into play due to trying to make a pure functional programming language useful. I found the more mathematical explanation a lot easier than any analogies involving say burritos or pipes etc... At first glance to imperative programmers I will admit all of this just looks like a bunch of navel gazing. I thought the same thing, but once you let go of thinking of computation as a series of steps and at a bit of a higher abstraction this makes a lot more sense. For a more soft introduction to the concepts this channel 9 video is probably a bit better: https://www.youtube.com/watch?v=ZhuHCtR3xq8 https://www.youtube.com/watch?v=ZhuHCtR3xq8 Another option might be to just get the haskell programming from first principles book: http://haskellbook.com http://haskellbook.com Does a good job grounding you up to monads and gives copious amounts of reference material. Even though I already knew haskell when I read the book it helped clear up some gaps I didn't know I had. But monads are going to be really weird no matter if all you've ever seen is imperative programming. Despite the fact that you already use them and have probably discovered them without knowing you did. Much like learning stack based programming languages, sometimes the only way up is to climb off the computational hill you're familiar with to learn another way to the other hill side to see things from their perspective.