Live data from Hacker News

Monads are a Class of Hard Drugs (2008)

lambda-diode.com

21–30 of 37 posts

Re: Monads are a Class of Hard Drugs (2008)

#21
post #13

For one thing, when you use a monad, you get hooked to it: the type constructors of the monad start to appear in the signatures of your function. Yup, that's the point![1] [1] Or rather, one of many points.

I used to feel this way too, so I'm not trying to be coy, but really that's a property of a (some) Functor(s), not a Monad (except in that all Monads are also Functors).

Monad is just the pattern where you combine Functors. Some Functors can be pattern matched upon to "escape" their values. Functors like IO cannot. IO would still be (academically) useful if not for its Monad instance... you'd just only be allowed a single effect in the entire program!

Re: Monads are a Class of Hard Drugs (2008)

#22
post #15
post #10

Earlier quoted context omitted.

>Anyone who understands monads is on a class of hard drugs. It's so frustrating to hear you say that. Monads are such a simple concept but they're difficult to explain because they're far more general and abstract than most programming topics. The best explanation I have is that monads are a way of storing some kind of computation with a value. When the user wants access to that value, he uses a monadic operator whic…

So basically monads are like a Java object that has a private field and a getter method that has some extra logic. Hey, that's really simple, you're right! duck & run l

Almost, it's more like an "applyer" method with some extra logic. You're never allowed to get "raw" values out, you can only pass functions inward to modify the value.

If you want to get the raw values out (and you almost always do) then you have to add some extra logic to the object above its "monadic" nature.

And yeah, it is really, really simple!

Re: Monads are a Class of Hard Drugs (2008)

#23
post #9

Earlier quoted context omitted.

What I wish someone had explained to me earlier was that Monads are an abstraction level up from most things you ever program with. Learn specific ones, and the general picture will start to make more sense. Avoid the IO monad until you understand, in order: + the List monad (probably the easiest for python people, since it's very similar to list comprehensions) + the Maybe monad (kind of a degenerate case) + the Sta…

>+ the Maybe monad (kind of a degenerate case) Hey. Hey. heyyyyy. I've used bind + maybe monad 'ish stuff in Python to clean up code previously littered with redundant if checks.

Haha, yeah, I meant "degenerate" in the mathematical sense. Totally useful, but in explaining it you're going to get a lot of "well, it's trivial in this case because...", which isn't that helpful if you don't yet understand the underlying concepts :)

Re: Monads are a Class of Hard Drugs (2008)

#24
post #17
post #9

Earlier quoted context omitted.

What I wish someone had explained to me earlier was that Monads are an abstraction level up from most things you ever program with. Learn specific ones, and the general picture will start to make more sense. Avoid the IO monad until you understand, in order: + the List monad (probably the easiest for python people, since it's very similar to list comprehensions) + the Maybe monad (kind of a degenerate case) + the Sta…

Most information on Monads start out with IO, which I agree isn't helpful. I found one that explained it with Maybe and Either, and that was where I began to understand it. I think Maybe is the easiest to grasp for people who work in procedural languages, since there's a very common idiom of returning a nil object if some operation doesn't succeed. You can look at Maybe and see immediately; "oh this is like a type-sa…

This is the part where I admit that I don't quite get Arrows. Anyone else?

Re: Monads are a Class of Hard Drugs (2008)

#25
post #9

Earlier quoted context omitted.

What I wish someone had explained to me earlier was that Monads are an abstraction level up from most things you ever program with. Learn specific ones, and the general picture will start to make more sense. Avoid the IO monad until you understand, in order: + the List monad (probably the easiest for python people, since it's very similar to list comprehensions) + the Maybe monad (kind of a degenerate case) + the Sta…

>+ the Maybe monad (kind of a degenerate case) Hey. Hey. heyyyyy. I've used bind + maybe monad 'ish stuff in Python to clean up code previously littered with redundant if checks.

Yes, the point is that it's just about the simplest Monad implementation that actually does something useful.

I'd observe in my code that I rarely have an enormous do block using Maybe; instead what I see a lot is use of the monadic interface to tie things together that would normally be a lot of if blocks, all on one line into one expression. You start missing that in other languages real fast. Also the Applicative instance is often quite useful, allowing you to easily tie together several things that return Maybes into a call of some sort that does the right thing if one of them is a Nothing, almost "free" from a syntax point of view.

Re: Monads are a Class of Hard Drugs (2008)

#26
post #20
post #8

Anyone who understands monads is on a class of hard drugs. I'm still looking for someone who can present a cogent explanation of monads using only Python. (I'm willing to replace "Python" in the above challenge with "any language I know well," which would include Python, C, C++, Java, JavaScript, and quite a few others which I won't bother to list here. Notably lacking from this list are Lisp, Scheme, Caml, Haskell,…

They're not smart to do in python. Monads are an expressive, simple pattern of coding that can be type-checked. In dynamic languages it'll just look like a lot of unnecessary line noise. In HM type systems it's a great way to help you pass contexts around in a way lets you focus on your values. But if you just want to speak Python, let me try to translate. --- As a motivation for monads in Python, we're going to try…

Thanks for the lengthy reply!

So Monads are a complicated error-propagation framework that has a harder-to-understand conceptual model and results in longer code compared to Python's exceptions.

Look at any serious program in the C language -- there are enormous amounts of code devoted to error handling.

Look at the problem with Java's checked exceptions. The other day I needed to call a static method reflectively. This is what I ended up with:

  // java code to invoke a named method on a named class
  String the_class_name;
  String the_method_name;

  try
  {
     c = Class.forName(the_class_name);
     result = (Value) c.getDeclaredMethod(the_method_name).invoke(null);
  }
  catch (ClassNotFoundException e)
  {
     throw(new RuntimeException(e));
  }
  catch (IllegalAccessException e)
  {
     throw(new RuntimeException(e));
  }
  catch (IllegalArgumentException e)
  {
     throw(new RuntimeException(e));
  }
  catch (InvocationTargetException e)
  {
     throw(new RuntimeException(e));
  }
  catch (NoSuchMethodException e)
  {
     throw(new RuntimeException(e));
  }
  catch (SecurityException e)
  {
     throw(new RuntimeException(e));
  }
The point that Python's Exception model gets right, that so many other languages get wrong, is that by default, you want to pass errors to the caller.

You don't want to pass errors through the same pipeline that results flow through, since then every joint in the plumbing needs error checking. The very name "exception" is chosen to denote an "extraordinary control flow" specifically for error handling.

Re: Monads are a Class of Hard Drugs (2008)

#27
post #10
post #8

Anyone who understands monads is on a class of hard drugs. I'm still looking for someone who can present a cogent explanation of monads using only Python. (I'm willing to replace "Python" in the above challenge with "any language I know well," which would include Python, C, C++, Java, JavaScript, and quite a few others which I won't bother to list here. Notably lacking from this list are Lisp, Scheme, Caml, Haskell,…

>Anyone who understands monads is on a class of hard drugs. It's so frustrating to hear you say that. Monads are such a simple concept but they're difficult to explain because they're far more general and abstract than most programming topics. The best explanation I have is that monads are a way of storing some kind of computation with a value. When the user wants access to that value, he uses a monadic operator whic…

I'm trying to parse this explanation. What's the difference between a monad and overriding __getattr__ in Python?

Re: Monads are a Class of Hard Drugs (2008)

#28
post #26
post #20

Earlier quoted context omitted.

They're not smart to do in python. Monads are an expressive, simple pattern of coding that can be type-checked. In dynamic languages it'll just look like a lot of unnecessary line noise. In HM type systems it's a great way to help you pass contexts around in a way lets you focus on your values. But if you just want to speak Python, let me try to translate. --- As a motivation for monads in Python, we're going to try…

Thanks for the lengthy reply! So Monads are a complicated error-propagation framework that has a harder-to-understand conceptual model and results in longer code compared to Python's exceptions. Look at any serious program in the C language -- there are enormous amounts of code devoted to error handling. Look at the problem with Java's checked exceptions. The other day I needed to call a static method reflectively. T…

No, of course not. Error handling is just one example. The monad interface makes handling that problem you mention---wiring errors through the value pipeline---much easier.

And the monad part is only just the "just" and "bind" functions. Everything else is about trying to make Python more explicit with its errors: "explicit it better than implicit", right?

Monads allow for easier composition of "values in context". That context might be error, or nondeterminism, or continuation, or state, or logging, or parsing, or parallelism, or simulation, or probability, or graphs, or prolog-like logic, or streaming, or many combinations over the previous.

And in every case, you have the same interface.

Re: Monads are a Class of Hard Drugs (2008)

#29
post #24
post #17

Earlier quoted context omitted.

Most information on Monads start out with IO, which I agree isn't helpful. I found one that explained it with Maybe and Either, and that was where I began to understand it. I think Maybe is the easiest to grasp for people who work in procedural languages, since there's a very common idiom of returning a nil object if some operation doesn't succeed. You can look at Maybe and see immediately; "oh this is like a type-sa…

This is the part where I admit that I don't quite get Arrows. Anyone else?

Anyone else who doesn't get arrows? Count me in! I wish i understood this comic's joke: http://ro-che.info/ccc/12.html :(

Re: Monads are a Class of Hard Drugs (2008)

#30
post #26
post #20

Earlier quoted context omitted.

They're not smart to do in python. Monads are an expressive, simple pattern of coding that can be type-checked. In dynamic languages it'll just look like a lot of unnecessary line noise. In HM type systems it's a great way to help you pass contexts around in a way lets you focus on your values. But if you just want to speak Python, let me try to translate. --- As a motivation for monads in Python, we're going to try…

Thanks for the lengthy reply! So Monads are a complicated error-propagation framework that has a harder-to-understand conceptual model and results in longer code compared to Python's exceptions. Look at any serious program in the C language -- there are enormous amounts of code devoted to error handling. Look at the problem with Java's checked exceptions. The other day I needed to call a static method reflectively. T…

If your only standard for utility is applicability to Python there's no point discussing monads or anything else that comes up in conversations about languages besides Python. Maybe the reason you haven't seen a cogent explanation of monads using only Python is the same as the reason you haven't seen a cogent explanation of how to use the clutch in an automatic car, or how to desalinate fresh water, or how to make lemonade with nothing but a jug and ice water. Maybe the problem isn't the explanation or the one producing it.
Post reply on HN