3 ms·

The purity is not an illusion though. Writing those sequences as a monad gives you the ability to compose actions, creating a new sequence from code you've alre

The purity is not an illusion though. Writing those sequences as a monad gives you the ability to compose actions, creating a new sequence from code you've already written for one.

AnimalMuppet 12y ago
But that's not a net win for me, compared to just having the action in a function that is called from several places. Worse, composing the actions means I have to think through how the composing is going to affect the sequencing of events. Just having a function doesn't give me that problem - the sequencing is explicit, not hidden, and therefore is easier to reason about.
- codygman 12y ago
  Can you give me some example code? I think our discussion would be a lot more productive and mutually beneficial with some code examples/output.
  - AnimalMuppet 12y ago
    I can't give actual example code (proprietary, company confidential, blah blah blah). So I'm going to have to come up with some fake example. [Thinking...] How about a robotic hand that's supposed to pick up a ball. The (C/C++) code might look like : void pickUpBall() { openHand(); moveHandToBall(); closeHand(); } You have to have that sequence. If the hand isn't open, moving it to the ball just bumps the ball away. If you close the hand before you move to the ball, you don't pick up the ball, you just close on air. So, in Haskell (if I had the hardware control libraries), I could put that in a monad to guarantee the sequence, and in an IO monad so that I could do things that had side effects like affecting the external world. But in fact I get both of those for free, just by not writing it in Haskell. (The pure functional nature of Haskell also doesn't do much for me in this situation. Yes, for the functions that can in fact be purely functional, it can make them easier to reason about and prove correct. But that isn't the difficult part of the code.) Composability: It's unclear to me how you're going to compose something like this in any way that's a) useful in this environment and b) dramatically different from simply making a higher-level function that calls pickUpBall() and some other functions.
    - codygman 12y ago
      Cool, now we have something to work with. However at such a high level no paradigm's differences (much less pros/cons) would be apparent. Would you mind implementing those individual functions? Actually it might be easier to use some open source embedded code. For completeness sake, I'd write the snippet above almost identically: pickUpBall = do openHand moveHandToBall closeHand
      - AnimalMuppet 12y ago
        OK, now you've got me really confused. Is that Haskell code? I thought that Haskell couldn't do sequence except inside a monad. (Or is "do" a monad?) But if that isn't a monad, then why did you write it that way? My original claim was that a monad wouldn't do much for me in my world, and if you wrote this without a monad, that kind of seems like you're agreeing with me. You said that you'd gain composability from writing this as a monad. In this example, how would that work? What would it buy me that I couldn't write (as easily) using what to me is the normal way?
        codygman 12y ago
        It would most likely be in the IO monad since IO would be happening. As for whether monads would help your code (and I still think they would) I'll need a larger example. In a small example abstraction and reuse aren't really apparent. If you can provide a larger example, we can find out who's right ;) Alternatively I'll try to find a larger example if you can't or don't want to.
        AnimalMuppet 12y ago
        Well, I just made up this example, so feel free to embellish it... But as you do, remember the question. We're in an embedded system, with lots of situations where sequence matters, and lots of stored state. The question is, what do monads buy me in that environment?

The purity is not an illusion though. Writing those sequences as a monad gives you the ability to compose actions, creating a new sequence from code you've already written for one.

AnimalMuppet 12y ago

But that's not a net win for me, compared to just having the action in a function that is called from several places. Worse, composing the actions means I have to think through how the composing is going to affect the sequencing of events. Just having a function doesn't give me that problem - the sequencing is explicit, not hidden, and therefore is easier to reason about.

codygman 12y ago
Can you give me some example code? I think our discussion would be a lot more productive and mutually beneficial with some code examples/output.
- AnimalMuppet 12y ago
  I can't give actual example code (proprietary, company confidential, blah blah blah). So I'm going to have to come up with some fake example. [Thinking...] How about a robotic hand that's supposed to pick up a ball. The (C/C++) code might look like : void pickUpBall() { openHand(); moveHandToBall(); closeHand(); } You have to have that sequence. If the hand isn't open, moving it to the ball just bumps the ball away. If you close the hand before you move to the ball, you don't pick up the ball, you just close on air. So, in Haskell (if I had the hardware control libraries), I could put that in a monad to guarantee the sequence, and in an IO monad so that I could do things that had side effects like affecting the external world. But in fact I get both of those for free, just by not writing it in Haskell. (The pure functional nature of Haskell also doesn't do much for me in this situation. Yes, for the functions that can in fact be purely functional, it can make them easier to reason about and prove correct. But that isn't the difficult part of the code.) Composability: It's unclear to me how you're going to compose something like this in any way that's a) useful in this environment and b) dramatically different from simply making a higher-level function that calls pickUpBall() and some other functions.
  - codygman 12y ago
    Cool, now we have something to work with. However at such a high level no paradigm's differences (much less pros/cons) would be apparent. Would you mind implementing those individual functions? Actually it might be easier to use some open source embedded code. For completeness sake, I'd write the snippet above almost identically: pickUpBall = do openHand moveHandToBall closeHand
    - AnimalMuppet 12y ago
      OK, now you've got me really confused. Is that Haskell code? I thought that Haskell couldn't do sequence except inside a monad. (Or is "do" a monad?) But if that isn't a monad, then why did you write it that way? My original claim was that a monad wouldn't do much for me in my world, and if you wrote this without a monad, that kind of seems like you're agreeing with me. You said that you'd gain composability from writing this as a monad. In this example, how would that work? What would it buy me that I couldn't write (as easily) using what to me is the normal way?
      - codygman 12y ago
        It would most likely be in the IO monad since IO would be happening. As for whether monads would help your code (and I still think they would) I'll need a larger example. In a small example abstraction and reuse aren't really apparent. If you can provide a larger example, we can find out who's right ;) Alternatively I'll try to find a larger example if you can't or don't want to.
        AnimalMuppet 12y ago
        Well, I just made up this example, so feel free to embellish it... But as you do, remember the question. We're in an embedded system, with lots of situations where sequence matters, and lots of stored state. The question is, what do monads buy me in that environment?