3 ms·

> 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

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

brucehauman 13y ago
Well a really interesting thing is that the channels approach helped me "discover" the queue approach that you are mentioning. As I worked on the channel examples I kept seeing the equivalent Js patterns that would make a more functional approach possible. The decoupled queue approach seems to be rare in practice and obviously superior. Wish I had thought about it long ago. I just followed the examples available to me. I really believe the channel approach lifts this notion (values on queues) to the forefront with the addition of blocking sequential semantics. Yeah my examples were a bit simplified, but I did try to make the DOM state a function of the application state. There will be more examples coming in the near future :)
gruseom 13y ago
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 How common is this approach? I'd be very interested to hear people's experiences with it. It's what we do, except we run the global event processor on a JS timer so that it works like a game loop picking items off a queue. Our DOM event handlers (the things you call addEventListener with) are all trivial stubs that simply create JSON descriptions of events as they happen and append them to that queue. We tried many different approaches before we hit on this, and it works surprisingly well in the two hardest areas: managing complexity and keeping the UI snappy. You can also create perceived concurrency this way: you do a little work on an item in the queue and then, if it's not done, put it back at the back of the line. That's how we do the "time-sensitive operations" you mention. I'm not sure what to call this design. I think of it as a state machine, but that's a metaphor rather than a precise description.
- abecedarius 13y ago
  Are you familiar with E? It basically works like this, plus built-in, transparent promises. http://www.erights.org/elib/concurrency/event-loop.html http://www.erights.org/elib/concurrency/event-loop.html outlines why you might settle on this model. The messages about coroutines linked at the bottom argue against things like core.async. (This all long precedes core.async, but Concurrent ML had that kind of design.) I've only done simple things in JS and don't understand what advantage you're getting by queueing events yourself, since JS already runs an event loop. Is it that you can inspect the queue and drop/modify events superseded by subsequent ones? I tried to do that once and it didn't help, but I've gotta admit I'm the opposite of an expert on JS UIs.
  - swannodette 13y ago
    As far as I understand CSP is not a coroutine model - though you can express it. Hoare covers this in his '78 paper. As far as delving into its utility for UI, it's worth looking at Pike's work and the Concurrent ML eXene work.
    - abecedarius 13y ago
      Yes, I've read the Pike and CML, they're good work. Haven't got around to Hoare 1978, and I don't see it online, but as I understand it, threads = coroutines + interleaving; adding interleaving won't reduce the problems in reasoning about code. If the distinction is that processes don't share state, I don't think that works, since you can implement mutable cells using channels and processes. (Obviously it's less of a problem than, say, pthreads, if that's the only mutable shared state.)
      - gruseom 13y ago
        This Hoare 1978? http://www.cs.ucf.edu/courses/cop4020/sum2009/CSP-hoare.pdf http://www.cs.ucf.edu/courses/cop4020/sum2009/CSP-hoare.pdf On my list to read too.
        13y ago

by drcode 13y ago

brucehauman 13y ago

Well a really interesting thing is that the channels approach helped me "discover" the queue approach that you are mentioning. As I worked on the channel examples I kept seeing the equivalent Js patterns that would make a more functional approach possible. The decoupled queue approach seems to be rare in practice and obviously superior. Wish I had thought about it long ago. I just followed the examples available to me. I really believe the channel approach lifts this notion (values on queues) to the forefront with the addition of blocking sequential semantics. Yeah my examples were a bit simplified, but I did try to make the DOM state a function of the application state. There will be more examples coming in the near future :)

gruseom 13y ago

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 How common is this approach? I'd be very interested to hear people's experiences with it. It's what we do, except we run the global event processor on a JS timer so that it works like a game loop picking items off a queue. Our DOM event handlers (the things you call addEventListener with) are all trivial stubs that simply create JSON descriptions of events as they happen and append them to that queue. We tried many different approaches before we hit on this, and it works surprisingly well in the two hardest areas: managing complexity and keeping the UI snappy. You can also create perceived concurrency this way: you do a little work on an item in the queue and then, if it's not done, put it back at the back of the line. That's how we do the "time-sensitive operations" you mention. I'm not sure what to call this design. I think of it as a state machine, but that's a metaphor rather than a precise description.

abecedarius 13y ago
Are you familiar with E? It basically works like this, plus built-in, transparent promises. http://www.erights.org/elib/concurrency/event-loop.html http://www.erights.org/elib/concurrency/event-loop.html outlines why you might settle on this model. The messages about coroutines linked at the bottom argue against things like core.async. (This all long precedes core.async, but Concurrent ML had that kind of design.) I've only done simple things in JS and don't understand what advantage you're getting by queueing events yourself, since JS already runs an event loop. Is it that you can inspect the queue and drop/modify events superseded by subsequent ones? I tried to do that once and it didn't help, but I've gotta admit I'm the opposite of an expert on JS UIs.
- swannodette 13y ago
  As far as I understand CSP is not a coroutine model - though you can express it. Hoare covers this in his '78 paper. As far as delving into its utility for UI, it's worth looking at Pike's work and the Concurrent ML eXene work.
  - abecedarius 13y ago
    Yes, I've read the Pike and CML, they're good work. Haven't got around to Hoare 1978, and I don't see it online, but as I understand it, threads = coroutines + interleaving; adding interleaving won't reduce the problems in reasoning about code. If the distinction is that processes don't share state, I don't think that works, since you can implement mutable cells using channels and processes. (Obviously it's less of a problem than, say, pthreads, if that's the only mutable shared state.)
    - gruseom 13y ago
      This Hoare 1978? http://www.cs.ucf.edu/courses/cop4020/sum2009/CSP-hoare.pdf http://www.cs.ucf.edu/courses/cop4020/sum2009/CSP-hoare.pdf On my list to read too.
      - 13y ago