The Day Python Embarassed Imperative Programming
the-27th-comrade.appspot.com
The Day Python Embarassed Imperative Programming
1–10 of 80 posts
Re: The Day Python Embarassed Imperative Programming
#2I'm not being sarcastic or anything, I'm really wondering: are Python programmers using monads without knowing it? Or is it that monads are a good tool at giving a semantic (or "mathematical meaning") to what they are coding?
I think the distinction between the two points of view isn't relevant, but my point is that when you know something and like it, you easily see it everywhere: if you want it, all your code is just lambda-calculus, all your control structure are some kinds of monads, all for loops are just tail-recursive functions, all objects are just closures…
Re: The Day Python Embarassed Imperative Programming
#3Re: The Day Python Embarassed Imperative Programming
#4Re: The Day Python Embarassed Imperative Programming
#5Any other working link? App engine says the server is over quota.
Re: The Day Python Embarassed Imperative Programming
#6This application is temporarily over its serving quota. Please try again later.
Re: The Day Python Embarassed Imperative Programming
#7Perhaps it's cleaner, and you can get accustomed to it, but it surely comes with an overhead over imperative thinking, at least for a beginner.
Re: The Day Python Embarassed Imperative Programming
#8def pymon(f, v = None): if v: return f(v)
and I just can't keep reading. Why would you do that? What reason would you have for not just calling f directly?
Re: The Day Python Embarassed Imperative Programming
#9Beyond obeying some simple laws, there are strikingly few restrictions on the semantics of >>=. It can mean completely different things to different Monad instances. To me, that's at the heart of why newbies struggle to understand monads: >>= operates at a higher level of abstraction than many programmers are accustomed to. Outside of specific Monad instances, >>='s meaning is less significant than the structure that it imposes via the type system.
But that flexibility is also what makes Monad such a useful class in Haskell. Once your brain begins to recognize the `m a -> (a -> m b) -> m b` pattern in code, you see it everywhere. Monads are just a way of acknowledging that that particular structure exists in your code and abstracting it away to be replaced by a single operator. A chain of function calls with possible failure, like the author points out, is one case in which such a pattern emerges, but it's far from the only one. I think the article sort of misses that larger point.