3 ms·

I might be missing something but from a quick skim did he just reinvent (a specific instance of) monads?

• nullspace 7y ago
  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.
• simiones 7y ago
  Well, Haskell's IO is "a specific instance of monads", but it was still an important discovery, even though monads were a well known concept. The idea would be to encapsulate your whole program in a very specific monad, one that: - runs all functions in parallel - implements sync points between functions - implements an event system with named events and attached values This does not at all reduce to "reinventing monads". Note: I think the idea is horrible, any moderately complex program written this way would be entirely unmaintainable in my opinion. The author touches on this towards the end, but I think they are completely minimizing the down-side.
  • clarry 7y ago
    > Note: I think the idea is horrible, any moderately complex program written this way would be entirely unmaintainable in my opinion. The author touches on this towards the end, but I think they are completely minimizing the down-side. I agree so much. I can't help but think that modifying code you don't understand by injecting more code via hooks is a recipe for disaster, and the next person maintaining the composite product has to chase down all (ab)users of these events like we once had to hunt down abusers of global variables to understand what the hell is going on. I don't even agree with the premise that this thing is less dependent on structure. Arguably, it is more dependent. It's just that instead of structure at the syntax level, we're now dealing with structure at a higher level, structure that is opaque to syntax but nevertheless present. Those named events and synchronization mechanisms make up their own structure.
• proc0 7y ago
  Pretty much, or at least reinventing functional interfaces which encode behavior at the type level.