Live data from Hacker News

The Day Python Embarassed Imperative Programming

the-27th-comrade.appspot.com

1–10 of 80 posts

Re: The Day Python Embarassed Imperative Programming

#2
Would it be possible that there are no blind spot on the Python side and a "semantic golden hammer" (for the lack of a better term) on the Haskell side?

I'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

#3
"The Python programmer said he had downloaded BASIC, and was experimenting with it. “But what is this GOTO stuff?” Never. Never ever ask that. One negative effect of asking that question is the horror of finding out that you use GOTO more than BASIC programmers; but because they are everywhere in your life, you have developed a blind spot to them. (Hint: do you use if?) In fact, as I showed him, every control structure in Python is an instance of GOTO."

Re: The Day Python Embarassed Imperative Programming

#7
I find the whole point of the article to be weak, to say the least. OK, I'm doing monads, or something equivalent to monads, all the time along my imperative code without even noticing because it's so intuitive concept. So when this common abstraction of "conditional function calls" is made explicit through monad syntax instead of intuitive-implicit, it is supposed to be easier to deal with?

Perhaps 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

#9
Perhaps the author is just glossing over the bigger picture for the sake of explanation, but it's a bit of a narrow view of monads to say that they are just "conditional function calls". That's true if the monad in question is Maybe, Either e, or (if you're squinting at it just right) []. But >>= in the State s and IO monads, for instance, has little to do with conditionally calling functions; there, it's more about sequencing.

Beyond 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.

Re: The Day Python Embarassed Imperative Programming

#10
I read the article and I still don't understand what monads are about. This happens every time. There must be something about the Haskell syntax (which has been ages since I used it in college--and I utterly failed to grasp monads then, too) it's very frustrating, I get the rest of functional programming. Apparently I forgot how to read Haskell.
Post reply on HN