7 ms·

ClojureScript Core.async Todos

115 points by brucehauman 13y ago

jrobn 13y ago
I've been slowly migrating my JavaScript code to clojurescript and I haven't wanted to touch JS since. Apart from requiring a build step to generate JS, clijurescript is the browser language I always wanted. JS seems like such a hack.
- jahewson 13y ago
  > JS seems like such a hack. That's not a good reason for advocating ClojureScript. Why not Dart? TypeScript? CoffeeScript? Tell me something good about core.async... Edit: Really, downvotes?
  - danneu 13y ago
    You're responding to: > Clojurescript is the browser language I always > wanted. JS seems like such a hack. You're getting downvoted for reading into someone's enthusiastic personal endorsement and then ending it with the tiring "Tell me something good about <thing I refuse to read or understand on my own time but I'll partake in discussion anyways>...". Start with Rob Pike's "Go Concurrency Patterns" (https://www.youtube.com/watch?v=f6kdp27TYZs https://www.youtube.com/watch?v=f6kdp27TYZs)
- mrbrowning 13y ago
  Have you settled on a good workflow for ClojureScript projects? cljsbuild at least lets you amortize JVM startup time with the auto mode, but the Write-Compile-Test loop (as Joel Spolsky calls it) still feels a little more sluggish than what I'm used to in other contexts.
  - swannodette 13y ago
    They need more work but I use browser REPL or Bodil Stokke's Node REPL http://github.com/bodil/cljs-noderepl http://github.com/bodil/cljs-noderepl if I need to do an intensive session of interactive coding without refreshing or waiting for recompiles. I contribute a bit to core.async now and it's definitely a goal to make sure that core.async works transparently whether you're coding against the browser or Node.
  - ibdknox 13y ago
    You get CLJS eval in Light Table :) Open a cljs file, open a browser, point it to a page that has the initial output of a leincljsbuild run, and press cmd+enter (or ctrl+enter) in your file.
  - jrobn 13y ago
    I've been doing all my coding in LightTable and it has a decent CLJS repl.
krosaen 13y ago
Two first impressions: - whoa, this is cool! - this is harder to read than the callback approach right now Makes me want to dig deeper, fully grok and reevaluate whether or not I'd really prefer this approach to callbacks. I have similar mixed feelings to using twisted vs tornado in python. There's no doubt channel support in clojure is awesome, just a personal matter of whether I'll end up preferring this paradigm for UI development.
- swannodette 13y ago
  I would liken it to the Game of Go (pun intended). You have a very small number of elements: chan, go, >!, <!, alts!. The learning curve is a bit steep because you have invest some time unlearning patterns you've picked up from traditional UI programming. But once you cross over the hump and you realize what is possible with just these few tools a whole vista of possibilities opens up. I'm sure the fans of go-lang would agree. Another analogy - Alan Kay compares software engineering to architecture and how so much engineering is brute force (think pyramids). core.async (really CSP) is like an arch (think gothic cathedral). Common UI patterns no longer seem arduous - and UI patterns which once seemed far out reach can be accomplished with a reasonable amount of engineering effort.
  - krosaen 13y ago
    Thanks - I like those analogies. I want to invest some time to see if the unlearning works for me. Most times when converting to a higher level way of doing something it eventually does. Also - thanks for all the awesome core.async gists - I feel like I want to take a geek sabbatical just so I can study them :)
- treerex 13y ago
  > this is harder to read than the callback approach right now Why do you think this is (I'm asking honestly, not trying to be snarky). Is it because you are not familiar with reading Lisp? The notation used to access channels is confusing? Unfamiliarity with the go-block concept? It took me a while to fully internalize the combination of syntax and power of go blocks, but now that I have reading core.async code (I have not yet had a need to actually use them, and no time to port an existing codebase) is much easier. I question whether the statement that callbacks are easier to read and understand is merely due to being accustomed to them. Core.async represents a radical departure from existing designs, and that can be jarring. Does this mean better syntactic sugar won't be created as developers gain experience? Or course not.
SeanDav 13y ago
Can this be used for node.js development? If so, any example projects out there?
- swannodette 13y ago
  That's the plan - as you can see here https://github.com/clojure/core.async/blob/master/src/main/clojure/cljs/core/async/impl/dispatch.cljs https://github.com/clojure/core.async/blob/master/src/main/c... we pick the fastest mechanism available for scheduling tasks depending on the environment. So that's MessageChannel for modern browsers, setImmediate for Node & IE 10, and setTimeout for everyone else.
- pjmlp 13y ago
  In regards to Clojure, why bother with node.js when one has the full power of the JVM and CLR at disposal?!
  - emidln 13y ago
    Because you want to use a library that was written for Node and not speed time finding (or writing) something similar for the JVM? If you know Node better than the JVM, Clojurescript on Node is very likely more valuable to you when starting out than Clojure on the JVM.
    - leishulang 13y ago
      not to mention that node-webkit will enable clojurescript to be a major player in large desktop production tools (light-table).
      - pjmlp 13y ago
        JavaFX, Swing, AWT, SWT, Windows Forms, WPF, XAML,.... Webkit, blah.
        leishulang 13y ago
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
ghempton 13y ago
When it comes to UI programming, I tend towards declarative solutions to problems over imperative ones. That said, this feels like an imperative solution to something that a state machine could handle equally well.
- swannodette 13y ago
  ... core.async compiles down to efficient state machines that I have absolutely no desire to write by hand.

115 points by brucehauman 13y ago

jrobn 13y ago

I've been slowly migrating my JavaScript code to clojurescript and I haven't wanted to touch JS since. Apart from requiring a build step to generate JS, clijurescript is the browser language I always wanted. JS seems like such a hack.

jahewson 13y ago
> JS seems like such a hack. That's not a good reason for advocating ClojureScript. Why not Dart? TypeScript? CoffeeScript? Tell me something good about core.async... Edit: Really, downvotes?
- danneu 13y ago
  You're responding to: > Clojurescript is the browser language I always > wanted. JS seems like such a hack. You're getting downvoted for reading into someone's enthusiastic personal endorsement and then ending it with the tiring "Tell me something good about <thing I refuse to read or understand on my own time but I'll partake in discussion anyways>...". Start with Rob Pike's "Go Concurrency Patterns" (https://www.youtube.com/watch?v=f6kdp27TYZs https://www.youtube.com/watch?v=f6kdp27TYZs)
mrbrowning 13y ago
Have you settled on a good workflow for ClojureScript projects? cljsbuild at least lets you amortize JVM startup time with the auto mode, but the Write-Compile-Test loop (as Joel Spolsky calls it) still feels a little more sluggish than what I'm used to in other contexts.
- swannodette 13y ago
  They need more work but I use browser REPL or Bodil Stokke's Node REPL http://github.com/bodil/cljs-noderepl http://github.com/bodil/cljs-noderepl if I need to do an intensive session of interactive coding without refreshing or waiting for recompiles. I contribute a bit to core.async now and it's definitely a goal to make sure that core.async works transparently whether you're coding against the browser or Node.
- ibdknox 13y ago
  You get CLJS eval in Light Table :) Open a cljs file, open a browser, point it to a page that has the initial output of a leincljsbuild run, and press cmd+enter (or ctrl+enter) in your file.
- jrobn 13y ago
  I've been doing all my coding in LightTable and it has a decent CLJS repl.

krosaen 13y ago

Two first impressions: - whoa, this is cool! - this is harder to read than the callback approach right now Makes me want to dig deeper, fully grok and reevaluate whether or not I'd really prefer this approach to callbacks. I have similar mixed feelings to using twisted vs tornado in python. There's no doubt channel support in clojure is awesome, just a personal matter of whether I'll end up preferring this paradigm for UI development.

swannodette 13y ago
I would liken it to the Game of Go (pun intended). You have a very small number of elements: chan, go, >!, <!, alts!. The learning curve is a bit steep because you have invest some time unlearning patterns you've picked up from traditional UI programming. But once you cross over the hump and you realize what is possible with just these few tools a whole vista of possibilities opens up. I'm sure the fans of go-lang would agree. Another analogy - Alan Kay compares software engineering to architecture and how so much engineering is brute force (think pyramids). core.async (really CSP) is like an arch (think gothic cathedral). Common UI patterns no longer seem arduous - and UI patterns which once seemed far out reach can be accomplished with a reasonable amount of engineering effort.
- krosaen 13y ago
  Thanks - I like those analogies. I want to invest some time to see if the unlearning works for me. Most times when converting to a higher level way of doing something it eventually does. Also - thanks for all the awesome core.async gists - I feel like I want to take a geek sabbatical just so I can study them :)
treerex 13y ago
> this is harder to read than the callback approach right now Why do you think this is (I'm asking honestly, not trying to be snarky). Is it because you are not familiar with reading Lisp? The notation used to access channels is confusing? Unfamiliarity with the go-block concept? It took me a while to fully internalize the combination of syntax and power of go blocks, but now that I have reading core.async code (I have not yet had a need to actually use them, and no time to port an existing codebase) is much easier. I question whether the statement that callbacks are easier to read and understand is merely due to being accustomed to them. Core.async represents a radical departure from existing designs, and that can be jarring. Does this mean better syntactic sugar won't be created as developers gain experience? Or course not.

SeanDav 13y ago

Can this be used for node.js development? If so, any example projects out there?

swannodette 13y ago
That's the plan - as you can see here https://github.com/clojure/core.async/blob/master/src/main/clojure/cljs/core/async/impl/dispatch.cljs https://github.com/clojure/core.async/blob/master/src/main/c... we pick the fastest mechanism available for scheduling tasks depending on the environment. So that's MessageChannel for modern browsers, setImmediate for Node & IE 10, and setTimeout for everyone else.
pjmlp 13y ago
In regards to Clojure, why bother with node.js when one has the full power of the JVM and CLR at disposal?!
- emidln 13y ago
  Because you want to use a library that was written for Node and not speed time finding (or writing) something similar for the JVM? If you know Node better than the JVM, Clojurescript on Node is very likely more valuable to you when starting out than Clojure on the JVM.
  - leishulang 13y ago
    not to mention that node-webkit will enable clojurescript to be a major player in large desktop production tools (light-table).
    - pjmlp 13y ago
      JavaFX, Swing, AWT, SWT, Windows Forms, WPF, XAML,.... Webkit, blah.
      - leishulang 13y ago

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

ghempton 13y ago

When it comes to UI programming, I tend towards declarative solutions to problems over imperative ones. That said, this feels like an imperative solution to something that a state machine could handle equally well.

swannodette 13y ago
... core.async compiles down to efficient state machines that I have absolutely no desire to write by hand.