4 ms·

Monads are easy to understand for imperative programmers. Imagine, you have code "var a=new A(); a.foo(x); a.bar(y); print(a);". How you reimplement it when "a

Monads are easy to understand for imperative programmers. Imagine, you have code "var a=new A(); a.foo(x); a.bar(y); print(a);". How you reimplement it when "a" is readonly structure, not even a object? You will need to implement functions "foo(a, x) -> a" "bar(a, y) -> a", and so on. If you do so, you will have monad.

AnimalMuppet 8y ago
What's not so easy to understand for an imperative programmer is this: Why should I jump through those hoops just to have a readonly structure? Why not just, you know, program imperatively? I think this is a big part of the problem explaining monads. If you don't have the problem, you don't care about the solution. And if you're an imperative programmer, this looks like saddling yourself with a problem you don't need to have, and then jumping through bizarre hoops to deal with the complications caused by a set of restrictions that you didn't need in the first place. I think instead the right approach is to sell people on the benefits of immutability, and talk much less about monads. When they start to need them, they'll start to see why they want them. Once they see them solve some problems that they actually have, then they'll start to get it.
- v_lisivka 8y ago
  Benefits of immutability are same as benefits of forbidding of global variables: no side effects. If function foo(a,x) cannot have any side effects, then you can compose it freely. Monad shines with containers, because you can write tons of useful functions, even your own libraries, for a container, which will operate on generic type T, so you will have lot of functionality available out of box for any new type T, which can be wrapped into container, without any additional effort. It's as powerful as templates in C++, but WITHOUT SIDE EFFECTS, so you cannot shoot yourself in the foot.
- v_lisivka 8y ago
  Another example: UNIX text tools. You can open a text in a editor (e.g. vim or emacs) and modify it in imperative style, or you can use cat, cut, sed, paste, join, and many other tools, which can operate on text, in stream mode, when original text is not modified. Text stream is monad here. Or you can convert (lift) your data to JSON or XML, and use JSON or XML tools in stream mode (e.g. when every record is on it own line): JSON and XML streams will be monads in such case. It's up to you to modify text manually, or use existing tools for text stream monad.
- joel_ms 8y ago
  > What's not so easy to understand for an imperative programmer is this: Why should I jump through those hoops just to have a readonly structure? Why not just, you know, program imperatively? Beacuse imperative programs are rife with "statements". Opaque lines of code that may or may not do something, somewhere, which cannot be manipulated as first class objects. Why would you ever wanna program with that weird restriction?
  - AnimalMuppet 8y ago
    I can't tell if that's parody or not...

AnimalMuppet 8y ago

What's not so easy to understand for an imperative programmer is this: Why should I jump through those hoops just to have a readonly structure? Why not just, you know, program imperatively? I think this is a big part of the problem explaining monads. If you don't have the problem, you don't care about the solution. And if you're an imperative programmer, this looks like saddling yourself with a problem you don't need to have, and then jumping through bizarre hoops to deal with the complications caused by a set of restrictions that you didn't need in the first place. I think instead the right approach is to sell people on the benefits of immutability, and talk much less about monads. When they start to need them, they'll start to see why they want them. Once they see them solve some problems that they actually have, then they'll start to get it.

v_lisivka 8y ago
Benefits of immutability are same as benefits of forbidding of global variables: no side effects. If function foo(a,x) cannot have any side effects, then you can compose it freely. Monad shines with containers, because you can write tons of useful functions, even your own libraries, for a container, which will operate on generic type T, so you will have lot of functionality available out of box for any new type T, which can be wrapped into container, without any additional effort. It's as powerful as templates in C++, but WITHOUT SIDE EFFECTS, so you cannot shoot yourself in the foot.
v_lisivka 8y ago
Another example: UNIX text tools. You can open a text in a editor (e.g. vim or emacs) and modify it in imperative style, or you can use cat, cut, sed, paste, join, and many other tools, which can operate on text, in stream mode, when original text is not modified. Text stream is monad here. Or you can convert (lift) your data to JSON or XML, and use JSON or XML tools in stream mode (e.g. when every record is on it own line): JSON and XML streams will be monads in such case. It's up to you to modify text manually, or use existing tools for text stream monad.
joel_ms 8y ago
> What's not so easy to understand for an imperative programmer is this: Why should I jump through those hoops just to have a readonly structure? Why not just, you know, program imperatively? Beacuse imperative programs are rife with "statements". Opaque lines of code that may or may not do something, somewhere, which cannot be manipulated as first class objects. Why would you ever wanna program with that weird restriction?
- AnimalMuppet 8y ago
  I can't tell if that's parody or not...