Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Day Python Embarassed Imperative Programming

the-27th-comrade.appspot.com

Post reply on HN
Print view View original

41–50 of 80 posts

Re: The Day Python Embarassed Imperative Programming

#41

Post by nandemo »

tripzilch wrote: post #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.

IMO the best intro to monads is You Could Have Invented Monads:

http://blog.sigfpe.com/2006/08/you-could-have-invented-monad...

It starts from concrete examples, lets you write a few exercises, then it shows you the common pattern behind those examples.

Re: The Day Python Embarassed Imperative Programming

#42

Post by obtu »

tcard wrote: post #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…

It's a stumbling block the beginner must learn once, not really an overhead that comes up at every use.

Re: The Day Python Embarassed Imperative Programming

#43

Post by tmhedberg »

ehutch79 wrote: post #37
lubutu wrote: post #11

Earlier quoted context omitted.

You wouldn't want to call f directly if it doesn't accept None . pymon is a function meaning f(v) if v else None .

wouldn't it be better to a) code f defensively in the first place, and b) not call f with invalid parameters?

> wouldn't it be better to a) code f defensively in the first place,

In Haskell, you don't have to. If your function takes a String as an argument, for instance, the compiler will ensure that it never receives a null instead. It will always receive an actual String, because normal types are non-nullable in Haskell. You have to explicitly wrap a type in a Maybe if you want to add nullability, and `Maybe String` is a completely different type from `String`, so the type checker can and will enforce that they don't improperly intermingle.

> and b) not call f with invalid parameters?

Same story here. If f takes a String argument, you can't (deliberately or by accident) pass it a Maybe String instead, or your code simply won't compile. The strong static type system in Haskell eliminates the mental burden of having to always watch out for nulls and handle them as a special case.

That may not seem like much of a burden if you're accustomed to languages like Python, Java, etc. where nullability is the default. But think about how much time you've spent dealing with NullPointerExceptions (or the equivalent in your language of choice) and imagine how much nicer it would be if the language itself could simply eliminate the possibility of them ever occurring in the first place. Well, thanks to its type system, Haskell can do that.

Re: The Day Python Embarassed Imperative Programming

#44

Post by mikeash »

whateverer wrote: post #31
kingkilr wrote: post #12

In Python, every object is an example of a monad. It has two possible values: None and anything_else. Is no more true then, "It has two possible values: 'Hello, I am a sexy bear' and anything_else."

Poorly worded, but the point is that every reference in Python, like in Java, ALGOL 60 and countless other languages, may be of a certain type, or point to None. In Haskell, save for a caveat[1], this doesn't happen, and you represent nullability (failure, usually) with types like Maybe or Either, when you want to . Those happen to be monads, too, but you can use them without the monadic operators. [1] The caveat is…

Null is an interesting exception in languages with static typing such as Java. But there is no static typing in Python. Literally any variable can hold any value of any type. None is not nearly so special there, since you can also assign 3 to any variable, or the identity function, or a string containing the answer to the question of life, the universe, and everything.

In languages like Java, null has special semantics that no other value has. In Python, there's nothing particularly special about None, it's simply used as a convenient sentinel by convention. I could easily write Python code that returns the literal string "This value is empty" as the sentinel instead, something that doesn't apply to languages like Java.

Re: The Day Python Embarassed Imperative Programming

#45

Post by Drbble »

ehutch79 wrote: post #37
lubutu wrote: post #11

Earlier quoted context omitted.

You wouldn't want to call f directly if it doesn't accept None . pymon is a function meaning f(v) if v else None .

wouldn't it be better to a) code f defensively in the first place, and b) not call f with invalid parameters?

No? The point is to factor out the repeated check-for-None code into one place to reduce redundancy and unclutter the algorithmic code in f. Separation of Concerns.

Re: The Day Python Embarassed Imperative Programming

#46

Post by icebraining »

whateverer wrote: post #31
kingkilr wrote: post #12

In Python, every object is an example of a monad. It has two possible values: None and anything_else. Is no more true then, "It has two possible values: 'Hello, I am a sexy bear' and anything_else."

Poorly worded, but the point is that every reference in Python, like in Java, ALGOL 60 and countless other languages, may be of a certain type, or point to None. In Haskell, save for a caveat[1], this doesn't happen, and you represent nullability (failure, usually) with types like Maybe or Either, when you want to . Those happen to be monads, too, but you can use them without the monadic operators. [1] The caveat is…

every reference in Python, like in Java, ALGOL 60 and countless other languages, may be of a certain type, or point to None.

Well, in Python every reference may be of any type. None is just another object, there's nothing particularly special about it.

Re: The Day Python Embarassed Imperative Programming

#48

Post by SoftwareMaven »

mikeash wrote: post #44
whateverer wrote: post #31

Earlier quoted context omitted.

Poorly worded, but the point is that every reference in Python, like in Java, ALGOL 60 and countless other languages, may be of a certain type, or point to None. In Haskell, save for a caveat[1], this doesn't happen, and you represent nullability (failure, usually) with types like Maybe or Either, when you want to . Those happen to be monads, too, but you can use them without the monadic operators. [1] The caveat is…

Null is an interesting exception in languages with static typing such as Java. But there is no static typing in Python. Literally any variable can hold any value of any type. None is not nearly so special there, since you can also assign 3 to any variable, or the identity function, or a string containing the answer to the question of life, the universe, and everything. In languages like Java, null has special semanti…

That's not completely accurate. None is still special in Python because it's the value chosen by the interpreter to represent an expression that doesn't explicitly return a value.

It is true that None is implemented like any other object (whther the value of 5 or an instance of my own class), but it still maintains special semantics.

Re: The Day Python Embarassed Imperative Programming

#50

Post by icebraining »

microtonal wrote: post #27
tcard wrote: post #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…

It is not only cleaner, it is also safer. In Python you have to add checks explicitly, or your program may try to execute a method on None . When using the Maybe or Either monad in Haskell, failure is always handled. Say that you have a sequence of three functions that return a Maybe value: do b Now, suppose that in a particular case f a returns Nothing , then the whole do-expression will evaluate to Nothing and g No…

One could say the problem is using None for indicating errors. Python does have exceptions, which also prevent further statements from being executed.

    try:
      b = f(a)
      c = g(b)
      return h(c)
If f(a) raises an exception, g and h don't get executed.

None should be returned when it's a valid value (say, in search() if it doesn't find anything), and in those cases it makes sense to have explicit handling.

Post reply on HN