3 ms·

Well, good point. I think what the author is talking about can he implemented as a Monad, and he / she is describing a flatmap operation. However, I’d hardly d

Well, good point. I think what the author is talking about can he implemented as a Monad, and he / she is describing a flatmap operation. However, I’d hardly describe it as “just”, it’s a fairly interesting idea.

pwm 7y ago
> However, I’d hardly describe it as “just”, it’s a fairly interesting idea. I'd argue that it's an absolutely amazing idea however this idea has been brought into CS 31 years ago and utilised heavily ever since, so an article like this should imho at least mention it so that people can go away and learn about these concepts. PS: My GP comment got heavily downvoted, which means that I'm missing something here.
- DarkWiiPlayer 7y ago
  > PS: My GP comment got heavily downvoted, which means that I'm missing something here. I'm also wondering why this is; is there some obvious innovation described in the article that I missed?
  - simiones 7y ago
    The initial comment (and the follow-up) are completely dismissive. The article is absolutely not a reinvention of the concept of monads, or of any commonly used monad (though what they are describing could probably be implemented as a monad). If I'm missing something, could you point to some monad that can be used to `wait until an event named "good" is generated, and abort if an event named "bad" is generated`?
    - DarkWiiPlayer 7y ago
      I'm not much of a functional programmer, so I don't deal much with monads. What I can tell you, is that for simple use-cases this looks an awful lot like map-reduce, except you're not necessarily mapping a list of inputs, but evaluating a series of checks on one input. Let's call it eval-reduce. But even from a non-functional perspective, I think the article is reinventing the wheel. We have a name for that sort of behavior: Object Orientation. Not in the UML/Java/C++ sense, but the original idea that centered around message-passing. Think erlang or elixir, those work in a very similar way already, and it's why people love them so much. There is certainly some inovative thinking in the article, but that's mostly relating to the syntax and the specific semantics, not the overall idea of evaluating conditions concurrently and joining them in the end.
      - simiones 7y ago
        > What I can tell you, is that for simple use-cases this looks an awful lot like map-reduce I really don't think this is like map-reduce, map-reduce usually focuses on pure functions applied in a series and/or in parallel, with the entire pipeline acting essentially like one large pure function that can easily be distributed. In contrast, this idea seems to focus on persistent side-effectful procedures that react to a string of events, with constant global syncing between an unbounded number of modules, which makes it impossible to distribute and highly non-pure. Also, this seems like a much more specific idea than Objects or even than Erlang. It specifically focuses on extremely small "objects"/"processes", it specifies rigid semantics for their communication, and a frankly insane composition model for the whole program. I'm pretty sure you could implement this in Erlang, but also pretty sure that this is not how most Erlang programs are written. Similarly, this is within the paradigm of Object Orientation, but it is a very specific example and that there are other (saner, imho) ways of composing Object Oriented programs that conform to the original Alan Kay ideas.

pwm 7y ago

> However, I’d hardly describe it as “just”, it’s a fairly interesting idea. I'd argue that it's an absolutely amazing idea however this idea has been brought into CS 31 years ago and utilised heavily ever since, so an article like this should imho at least mention it so that people can go away and learn about these concepts. PS: My GP comment got heavily downvoted, which means that I'm missing something here.

DarkWiiPlayer 7y ago
> PS: My GP comment got heavily downvoted, which means that I'm missing something here. I'm also wondering why this is; is there some obvious innovation described in the article that I missed?
- simiones 7y ago
  The initial comment (and the follow-up) are completely dismissive. The article is absolutely not a reinvention of the concept of monads, or of any commonly used monad (though what they are describing could probably be implemented as a monad). If I'm missing something, could you point to some monad that can be used to `wait until an event named "good" is generated, and abort if an event named "bad" is generated`?
  - DarkWiiPlayer 7y ago
    I'm not much of a functional programmer, so I don't deal much with monads. What I can tell you, is that for simple use-cases this looks an awful lot like map-reduce, except you're not necessarily mapping a list of inputs, but evaluating a series of checks on one input. Let's call it eval-reduce. But even from a non-functional perspective, I think the article is reinventing the wheel. We have a name for that sort of behavior: Object Orientation. Not in the UML/Java/C++ sense, but the original idea that centered around message-passing. Think erlang or elixir, those work in a very similar way already, and it's why people love them so much. There is certainly some inovative thinking in the article, but that's mostly relating to the syntax and the specific semantics, not the overall idea of evaluating conditions concurrently and joining them in the end.
    - simiones 7y ago
      > What I can tell you, is that for simple use-cases this looks an awful lot like map-reduce I really don't think this is like map-reduce, map-reduce usually focuses on pure functions applied in a series and/or in parallel, with the entire pipeline acting essentially like one large pure function that can easily be distributed. In contrast, this idea seems to focus on persistent side-effectful procedures that react to a string of events, with constant global syncing between an unbounded number of modules, which makes it impossible to distribute and highly non-pure. Also, this seems like a much more specific idea than Objects or even than Erlang. It specifically focuses on extremely small "objects"/"processes", it specifies rigid semantics for their communication, and a frankly insane composition model for the whole program. I'm pretty sure you could implement this in Erlang, but also pretty sure that this is not how most Erlang programs are written. Similarly, this is within the paradigm of Object Orientation, but it is a very specific example and that there are other (saner, imho) ways of composing Object Oriented programs that conform to the original Alan Kay ideas.