TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

The Day Python Embarassed Imperative Programming

88 pointsby nicolastabout 13 years ago

14 comments

tmhedbergabout 13 years ago
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 &#62;&#62;= in the State s and IO monads, for instance, has little to do with conditionally calling functions; there, it's more about sequencing.<p>Beyond obeying some simple laws, there are strikingly few restrictions on the semantics of &#62;&#62;=. It can mean completely different things to different Monad instances. To me, that's at the heart of why newbies struggle to understand monads: &#62;&#62;= operates at a higher level of abstraction than many programmers are accustomed to. Outside of specific Monad instances, &#62;&#62;='s meaning is less significant than the structure that it imposes via the type system.<p>But that flexibility is also what makes Monad such a useful class in Haskell. Once your brain begins to recognize the `m a -&#62; (a -&#62; m b) -&#62; 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.
评论 #3638859 未加载
评论 #3641012 未加载
评论 #3638921 未加载
gosubabout 13 years ago
"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."
评论 #3638869 未加载
slurgfestabout 13 years ago
I don't see anything here showing Python to be embarrassing. Python IS dynamically typed, which puts the burden on you to do type checking when it is necessary. But everybody already knew that.<p>None is just a singleton value. A particular object may be None, or may be 4, or may be whatever. However, you cannot assign a new value to 4, or None, so it isn't accurate to say that any object could have a value of None. It isn't that an object might have something in it, or not. It's that the object might be None, or something other than None, JUST as it might be 4, or something other than 4. That is just how it works in Python's type system. There really is no notion of "has no value". None IS a value. If (for some reason, hopefully a good one) you mean to exclude it and raise an error, you must deal with that in exactly the same way as you would exclude and raise an error on any other particular value you found important.<p>In Python, it is not true that anything might not have a value. Python itself doesn't even have predicates for "has something in it" or "doesn't have something in it." That might be a common idiom using None by convention, but it's by no means inherent to Python, or necessary. It's really not the same as NULL.<p>What's true is that any argument (or namespace binding) could have a value of None. OR 4, or a certain dict, or whatever. That's just because Python isn't doing automatic type checking. None does not take any special role which you do not give to it. Its semantics are up for grabs. NOTHING in Python actually forces you to use None to denote "no value." And it is BY DESIGN that Python does not automatically type check everything. YOU must decide whether and how to type check arguments - not at all, by using your own decorators or asserts or some library, or by not using Python. Python isn't a bondage and discipline language. If you don't like that, don't use it, it's just that simple. There's no need to call it embarrassing, or gloat about how you schooled somebody who showed interest in your favorite language.<p>So. If you use the return value of a function without a return statement, you are asking for a value which may be None, the same as if you had written 'return None'. You bear responsibility for that decision - the same as you bear responsibility for feeding int(4) or a module object to your functions. If you don't like that, then don't do it.<p>Under normal circumstances, without doing anything special, you will get something like a TypeError if someone (e.g. you) feeds a None to a function not anticipating it.<p>You only have to handle that in the case where it is vitally important to have a different exception or other behavior. You don't need "six hundred and forty nine thousand two hundred and eighty-eight if statements" unless you are being needlessly compulsive to begin with, in a vain effort to emulate a bondage-and-discipline language. Python isn't even supposed to be a bondage-and-discipline language, so it's no revelation that it isn't good at that. Trying to use it that way is just doing it wrong.<p>(n.b. Instead of using imperative if-statements, you might prefer: f(v) if v else None, for those instances where it's even necessary).<p>Dear Author:<p>It's cool that you are proud of yourself, but in this case I think your advocacy is being hurt by your ego. I have never gotten the impression that Haskell programmers in general are smug and boastful. If YOU don't want to be thought of as smug and boastful, then don't publish articles like this where you are smugly bragging about who you schooled.
p4bl0about 13 years ago
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?<p>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?<p>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…
评论 #3638915 未加载
tcardabout 13 years ago
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?<p>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.
评论 #3638963 未加载
评论 #3638888 未加载
评论 #3639238 未加载
Kilimanjaroabout 13 years ago
It is embarrassing for google app engine to allow unusual spikes like that to bring a site down. What better PR strategy to let the sites up and running to show that no google property can ever be slashdotted/dugg/hackernewsed?<p>Google please fix this mess, elegantly.
评论 #3639105 未加载
评论 #3639217 未加载
superxorabout 13 years ago
Any other working link? App engine says the server is over quota.
评论 #3638741 未加载
kingkilrabout 13 years ago
<p><pre><code> In Python, every object is an example of a monad. It has two possible values: None and anything_else. </code></pre> Is no more true then, "It has two possible values: 'Hello, I am a sexy bear' and anything_else."
评论 #3638923 未加载
评论 #3639052 未加载
评论 #3638936 未加载
评论 #3638901 未加载
tripzilchabout 13 years ago
I read the article and I <i>still</i> don't understand what monads are about. This happens every time. There must be something about the Haskell syntax (which has been <i>ages</i> since I used it in college--and I utterly failed to grasp monads then, too) it's <i>very</i> frustrating, I get the rest of functional programming. Apparently I forgot how to read Haskell.
评论 #3639067 未加载
评论 #3638905 未加载
评论 #3639234 未加载
评论 #3638979 未加载
ehutch79about 13 years ago
I don't get it. I see this;<p>def pymon(f, v = None): if v: return f(v)<p>and I just can't keep reading. Why would you do that? What reason would you have for not just calling f directly?
评论 #3638849 未加载
varelseabout 13 years ago
There may be a point here somewhere, and monads probably have a bigger use than this, but what's presented here looked more like my syntactic sugaring beats yours to me.
JadeNBabout 13 years ago
Shouldn't `hamon2` be<p><pre><code> hamon2 f (Just x) = f x hamon2 f Nothing = Nothing </code></pre> ? The author's definition doesn't seem to typecheck if `f :: a -&#62; Maybe b` (as in `(&#62;&#62;=)`).<p>EDIT: Ah, I see; looking at the blackboard picture suggests that the author has confused `(&#62;&#62;=) :: Monad m =&#62; m a -&#62; (a -&#62; m b) -&#62; m b` with `fmap :: Functor m =&#62; (a -&#62; b) -&#62; m a -&#62; m b`.
OkkeFFabout 13 years ago
Can someone create a mirror?
评论 #3639272 未加载
funkahabout 13 years ago
Well, that was certainly saying something. Only problem is, I have absolutely no idea what.