6 ms·

I dunno... the new async stuff is cool but I'm worried it's being oversold a bit... First of all, it is by nature a very "imperative" solution... it goes (to s

by drcode 13y ago

I dunno... the new async stuff is cool but I'm worried it's being oversold a bit... First of all, it is by nature a very "imperative" solution... it goes (to some degree at least) counter to the whole idea that state changes need to be limited as much as possible and isolated from the bulk of the "functional" code. Also, it seems people are using this idea to create little localized event handlers, whereas before you'd solve this in a functional approach by having a single global event handler. Sure, having a global event handler can be derided by saying "this global handler is spaghetti code because it doesn't isolate concerns." But in the same way, this type of channel-driven programming can be called spaghetti code because the many different goroutines can step on each other as they manipulate the DOM. For instance, if OP creates another channel-driven system for "editing todos" he would have to do some hard thinking to make sure the "add todos" system and the "edit todos" system don't interfere with each other and cause undefined behavior. I should point out I haven't built a system yet that is channel-based (I plan to do this soon) so my knowledge of this approach is as of yet limited and it's possible I will like channels better once I've used them more heavily.

swannodette 13y ago
... but coordinating "edit todos" processes and "add todos" processes is precisely what core.async is designed to do :) No hard thinking required.
- drcode 13y ago
  Haha, when you say that, David, I feel like Einstein just jumped into a physics forum and said "there's no hard thinking required to understand General Relativity."
brucehauman 13y ago
Thanks for the thoughtful response. It is interesting. In normal Js applications there is tremendous gravity towards having mutable application state because the callbacks need a handle of some sort (normally some instance of something). So I am wondering what you mean by saying that the callback pattern is more functional? In addition to mutable application state we have another global mutable state, one that's even harder to opt out of: The Dom. Regardless wether we use channels or callbacks this is going to be a problem whenever we have more than one actor changing it, whether that is done at the same time or sequentially. To me the place for core.async or the newish yield operator is that blocking will allow us to wire together complex event behavior in some fairly sophisticated ways. How long does it take to get a slideshow to really work well in callback land? Or responsive autocomplete with correct lower and upper bound timeout thresholds? So we can handle the wiring of events and when we get to the right state we do our functional application state transition. Then as long as we are driving the Dom off of our application state then we should be good right? * waiving my hands a bunch
- ricardobeat 13y ago
  > How long does it take to get a slideshow to really work well in callback land? Or responsive autocomplete with correct lower and upper bound timeout thresholds? Those are not hard problems, really. Doesn't core.async solve bigger issues?
  - swannodette 13y ago
    Do you not consider managing complexity a "big" problem? I'm certainly tired of writing code like this http://github.com/jquery/jquery-ui/blob/master/ui/jquery.ui.autocomplete.js http://github.com/jquery/jquery-ui/blob/master/ui/jquery.ui....
    - brucehauman 13y ago
      Wow, that looks a lot easier than I thought it would be.
  - brucehauman 13y ago
    Wether they are hard or not. They seem to confound developers as the edge cases of shared mutable state stack up. Core.async is offering another way to express solutions to complex behavior and is certainly worth investigating. I would say that is the bigger issue 'expression'. I have to say though I am not advocating the creation of huge systems this way but I am very interested in this as a different approach and I am going to see how far it takes me.
- drcode 13y ago
  > what you mean by saying that the callback pattern is more functional? I agree that the callback approach is not functional, and that the channel approach is certainly much better than this status quo approach. I'm comparing instead against an approach where you break down all relevant events into JSON, and then push those into a global fully-functional "event handler" function that translates events (along the "world state") into a set of DOM manipulation primitives. With that type of approach, no channels are necessary. I agree this approach has difficulties with time-sensitive operations (such as responsive autocomplete, etc) and that channels offer advantages for this. I'm not yet sure which approach leads to the least tradeoffs or whether there is a third approach that combines the best of both worlds that I don't quite comprehend yet. > another global mutable state, one that's even harder to opt out of: The Dom Well, I think the success of angular.js shows that it's possible (and probably desirable) to completely isolate DOM state changes from other program code... though the OP program doesn't do this, this is clearly just a simplified example, so I want to see what is possible once someone builds a client-side framework that is built on channels...
dschiptsov 13y ago
Nice to see that people sometimes asking "what for" question. I think it is what could be called "Haskell syndrome" when people tend to write abstract things in "very fancy way" without asking that simple question. There are tons of blog posts like "look, I could write this abstraction in Haskell this way using this kind of monads!". Well, you can, very clever, the question is - what are the chances to encounter this abstraction in real-world problems? Isn't there a straightforward but less fancy solution? Should I really have "all this fancy stuff" to process onClick events which can be done in 3 lines of plain ugly JS?)
- chongli 13y ago
  Should I really have "all this fancy stuff" to process onClick events which can be done in 3 lines of plain ugly JS?) "All this fancy stuff" is just an exploration of what's possible. The verbosity can (and will) be abstracted away via Clojure's excellent tools of abstraction (higher-order functions and macros). Your "3 lines of plain ugly JS" aren't going to scale because they rely on mutation. Mutation is deceptively quick and easy when you're just starting out. However, once your program grows large it turns into a sprawling mess of complexity.

by drcode 13y ago

swannodette 13y ago

... but coordinating "edit todos" processes and "add todos" processes is precisely what core.async is designed to do :) No hard thinking required.

drcode 13y ago
Haha, when you say that, David, I feel like Einstein just jumped into a physics forum and said "there's no hard thinking required to understand General Relativity."

brucehauman 13y ago

Thanks for the thoughtful response. It is interesting. In normal Js applications there is tremendous gravity towards having mutable application state because the callbacks need a handle of some sort (normally some instance of something). So I am wondering what you mean by saying that the callback pattern is more functional? In addition to mutable application state we have another global mutable state, one that's even harder to opt out of: The Dom. Regardless wether we use channels or callbacks this is going to be a problem whenever we have more than one actor changing it, whether that is done at the same time or sequentially. To me the place for core.async or the newish yield operator is that blocking will allow us to wire together complex event behavior in some fairly sophisticated ways. How long does it take to get a slideshow to really work well in callback land? Or responsive autocomplete with correct lower and upper bound timeout thresholds? So we can handle the wiring of events and when we get to the right state we do our functional application state transition. Then as long as we are driving the Dom off of our application state then we should be good right? * waiving my hands a bunch

ricardobeat 13y ago
> How long does it take to get a slideshow to really work well in callback land? Or responsive autocomplete with correct lower and upper bound timeout thresholds? Those are not hard problems, really. Doesn't core.async solve bigger issues?
- swannodette 13y ago
  Do you not consider managing complexity a "big" problem? I'm certainly tired of writing code like this http://github.com/jquery/jquery-ui/blob/master/ui/jquery.ui.autocomplete.js http://github.com/jquery/jquery-ui/blob/master/ui/jquery.ui....
  - brucehauman 13y ago
    Wow, that looks a lot easier than I thought it would be.
- brucehauman 13y ago
  Wether they are hard or not. They seem to confound developers as the edge cases of shared mutable state stack up. Core.async is offering another way to express solutions to complex behavior and is certainly worth investigating. I would say that is the bigger issue 'expression'. I have to say though I am not advocating the creation of huge systems this way but I am very interested in this as a different approach and I am going to see how far it takes me.
drcode 13y ago
> what you mean by saying that the callback pattern is more functional? I agree that the callback approach is not functional, and that the channel approach is certainly much better than this status quo approach. I'm comparing instead against an approach where you break down all relevant events into JSON, and then push those into a global fully-functional "event handler" function that translates events (along the "world state") into a set of DOM manipulation primitives. With that type of approach, no channels are necessary. I agree this approach has difficulties with time-sensitive operations (such as responsive autocomplete, etc) and that channels offer advantages for this. I'm not yet sure which approach leads to the least tradeoffs or whether there is a third approach that combines the best of both worlds that I don't quite comprehend yet. > another global mutable state, one that's even harder to opt out of: The Dom Well, I think the success of angular.js shows that it's possible (and probably desirable) to completely isolate DOM state changes from other program code... though the OP program doesn't do this, this is clearly just a simplified example, so I want to see what is possible once someone builds a client-side framework that is built on channels...

dschiptsov 13y ago

Nice to see that people sometimes asking "what for" question. I think it is what could be called "Haskell syndrome" when people tend to write abstract things in "very fancy way" without asking that simple question. There are tons of blog posts like "look, I could write this abstraction in Haskell this way using this kind of monads!". Well, you can, very clever, the question is - what are the chances to encounter this abstraction in real-world problems? Isn't there a straightforward but less fancy solution? Should I really have "all this fancy stuff" to process onClick events which can be done in 3 lines of plain ugly JS?)

chongli 13y ago
Should I really have "all this fancy stuff" to process onClick events which can be done in 3 lines of plain ugly JS?) "All this fancy stuff" is just an exploration of what's possible. The verbosity can (and will) be abstracted away via Clojure's excellent tools of abstraction (higher-order functions and macros). Your "3 lines of plain ugly JS" aren't going to scale because they rely on mutation. Mutation is deceptively quick and easy when you're just starting out. However, once your program grows large it turns into a sprawling mess of complexity.