5 ms·

So I haven’t quite grasped monads or their usefulness. Your “what-if” is completely meaningless to me, and I’m sure it’s my lack. Could you expound upon the i

So I haven’t quite grasped monads or their usefulness. Your “what-if” is completely meaningless to me, and I’m sure it’s my lack. Could you expound upon the implications? To me it is like saying: what if you could redefine the period at the end of a sentence....ok, but why?

white-flame 8y ago
To my limited non-Haskellian understanding, you can give a block of expressions to a monad. It then decides which expressions to evaluate, in which order, optionally depending on the value they might return to the monad. So you could have a monad which does "evaluate all these in order unless something goes null" (which is a nuisance to type in C-style languages), or one that expands on the if-then-else concept. None of these carry forward internal/hidden state like an IO monad does, but are there to expand user control for how to flow from 1 expression to another in your custom scopes. It's somewhat conceptually related to Command or Visitor Pattern programming, but Haskell has syntactic sugar to have them basically work similarly to normal statements. Alternatively, this is a runtime-only version of one specific thing that Lisp macros can do to &body scopes, in constructing custom control flow. This also is only 1 way to use monads, as they're a technically pretty simple tool (an interface with 2 functions) that can be used in a bunch of scenarios. [If I'm wrong, and I'm probably wrong, I'd love clarifications for myself, too!]
v_lisivka 8y ago
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...

white-flame 8y ago

To my limited non-Haskellian understanding, you can give a block of expressions to a monad. It then decides which expressions to evaluate, in which order, optionally depending on the value they might return to the monad. So you could have a monad which does "evaluate all these in order unless something goes null" (which is a nuisance to type in C-style languages), or one that expands on the if-then-else concept. None of these carry forward internal/hidden state like an IO monad does, but are there to expand user control for how to flow from 1 expression to another in your custom scopes. It's somewhat conceptually related to Command or Visitor Pattern programming, but Haskell has syntactic sugar to have them basically work similarly to normal statements. Alternatively, this is a runtime-only version of one specific thing that Lisp macros can do to &body scopes, in constructing custom control flow. This also is only 1 way to use monads, as they're a technically pretty simple tool (an interface with 2 functions) that can be used in a bunch of scenarios. [If I'm wrong, and I'm probably wrong, I'd love clarifications for myself, too!]

v_lisivka 8y ago

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