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

21–30 of 80 posts

Re: The Day Python Embarassed Imperative Programming

#21

Post by klodolph »

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

Well, that's the idea of monads -- you can see them everywhere because their original purpose is to express imperative programming mathematically. It's like thinking that all numbers can be represented with digits; of course -- digits were invented to represent all numbers.

But the thing that makes Haskell unique is not that you have explicit monads. It's that you can (1) use monads other than the IO monad (like Maybe, [], STM, ST), and (2) that you can choose to use no monads at all in a given function.

To put it another way, Haskell is unique because it allows you write functions without using monads, but in other languages you can't turn them off. Like nullable types, which can't be turned off in Java (ever debug NullPointerExceptions?) or Python, but which have to be enabled on a case-by-case basis in Haskell.

Re: The Day Python Embarassed Imperative Programming

#22

Post by Figs »

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

Actually, I'm pretty sure the reason most people have trouble understanding monads in Haskell is because they haven't learned what typeclasses are yet. Once you know what a typeclass is, the rest is pretty straightforward.

I tried to explain it here ( http://www.reddit.com/r/programming/comments/erzh1/monads_ar... ) a while ago, which might be helpful for some people. Although, the version of List's >>= function is much easier to understand here ( http://en.wikibooks.org/wiki/Haskell/Advanced_monads#The_Lis... ) than the one I pulled out of GHC's library code.

Re: The Day Python Embarassed Imperative Programming

#23

Post by klodolph »

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

Why pull a quote out of context to nitpick it? The article goes on to explain how common it is to check if an object is None and act differently, which is what gives us the same monadic structure as the Maybe monad in Haskell.

Re: The Day Python Embarassed Imperative Programming

#24

Post by microtonal »

tripzilch wrote: post #13
tmhedberg wrote: post #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…

m a -> (a -> m b) -> m b Okay, so what does this mean? I thought it was `f x -> x * x` is a function definition, right? Or am I completely mistaken here? Because in the above code, what is the function name, the parameter and the return value? I know "everything is a function" in Haskell but I really can't see through the multiple arrows here. Any help?

It's actually more insightful to see the full type signature:

  (>>=) :: Monad m => m a -> (a -> m b) -> m b
So, >>= is a function that takes:

- A value a in a monadic type m

- A function (a -> m b): a function that takes a value a and returns a value b wrapped in the monadic type m.

And it returns:

- A value b wrapped in the monadic type m.

It helps to look at the definition of (>>=) for a particular monad. The article mostly discusses computations that can fail (None vs an object in Python). The corresponding Haskell monads are Maybe and Either. The signature for (>>=) in the Maybe monad is:

    (>>=) :: Maybe a -> (a -> Maybe b) -> Maybe b
What the grandparent points out is that a monad defines a structure (how to combine expressions that result in wrapped values), but not semantics. The semantics are defined in the definition of a particular monad. E.g. the Maybe monad models failure in computation, while a monad such as MonadRandom does something different altogether (providing random numbers, while threading the state of the random number generator).

Re: The Day Python Embarassed Imperative Programming

#25

Post by microtonal »

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

Except that 'Hello, I am a sexy bear' is generally not used to indicate failure in Python, while None often is.

Edit: strange downvoting here :/. The parent has a point in the sense that None is just another object in Python. However, it's a singleton with a special meaning (by convention). Consequently, the parent used a false analogy.

Re: The Day Python Embarassed Imperative Programming

#26

Post by willvarfar »

lubutu wrote: post #15
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 does come with an overhead for a beginner, to be sure. But because it is a consistent abstraction we can build idioms on top of the concept of a monad, and in doing so it actually becomes easier to reason about. The best things in life have a learning curve. Edit: Wow, I was downvoted for this?

(not downvoter)

I come to completely the opposite conclusion:

http://williamedwardscoder.tumblr.com/post/18319031919/progr...

There's nothing stopping someone writing a haskell-alike with readable syntax as long as they stay away from trying to create terms like monads to explain things that don't need explaining ;)

Re: The Day Python Embarassed Imperative Programming

#27

Post by microtonal »

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 Nothing is never evaluated.

Failure monads do not only add cleanliness, but also safety.

Re: The Day Python Embarassed Imperative Programming

#28

Post by masklinn »

tripzilch wrote: post #13
tmhedberg wrote: post #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…

m a -> (a -> m b) -> m b Okay, so what does this mean? I thought it was `f x -> x * x` is a function definition, right? Or am I completely mistaken here? Because in the above code, what is the function name, the parameter and the return value? I know "everything is a function" in Haskell but I really can't see through the multiple arrows here. Any help?

> Okay, so what does this mean? I thought it was `f x -> x * x` is a function definition, right? Or am I completely mistaken here?

In this case, it's a type signature for a curried function. So

    a -> m b
is a function taking a value of type `a` and returning a value of type `m b`. In C# you would write:

    Function>
so `m a -> (a -> m b) -> m b` is a function taking a value of type `m a` and a function with signature `a -> m b` and returning a function of type `m b`. Translating to C# again,

    Function, Function>, M >
> Or am I completely mistaken here?

Pretty much yeah. In haskell, a function is either a top-level binding:

    someFunction arg = doSomething arg
or an anonymous function which is introduced by the character `\` (because `\` looks like `λ`, kind-of):

    \arg -> doSomething arg
In the expression you quoted, there is no function name, these are all types. The function name in this case is `(>>=)`

Re: The Day Python Embarassed Imperative Programming

#29

Post by StavrosK »

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.

Same here. I must have read every article explaining Monads that I saw, but I still have no idea what they are.

Re: The Day Python Embarassed Imperative Programming

#30

Post by NathanRice »

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

I'm just getting it now. Google for something called Typeclassopedia and read about Functors, and then Applicative functors. Those are much easier to understand right away, and they set the stage for monads. Applicative functors relate to functors in an obvious way (you could probably implement one in terms of the other). Monads relate to applicative functors in a less obvious way, to me anyway, but at least it's ana…

"Learn you a Haskell for great good" is probably the most approachable book on the subject you can read it online for free.

People who are confused should definitely check it out.

Post reply on HN