What's your opinion on exposing the option of stale vs. consistent read in the API? I can see cases where I'd be ok with a stale read while for others I'd like the most up-to-date value.
That makes a lot of sense, there are definitely use cases where to read a past value is viable, especially considering the big difference in performances between the two kind of reads.
Hi, author here. I haven't tested it on ClojureScript yet, but since core.async is supported by CLJS I don't see the reason why it wouldn't work there as well.
If it doesn't, let me know on Github and I'll look into it! I don't have any experience with CLJS, but I'm interested in learning so it'd be a good excuse.
I submitted a pull request which sets up the project to use cljx to work in both Clojure and ClojureScript.
ETA: Just realized that <!! and >!! aren't available in ClojureScript, so it needs some more work to be complete, but the pull request should help you get set up to develop for both.
Hi, author here. That was exactly my motivation for writing it. There's all sort of middleware and plugins out there for throttling from the server side, but I found nothing that would let me control my own outbound API calls to a an external service in Clojure. I also wanted support for burstiness, and that was even harder to find.
I bet you could come up with other uses for it though. Someone told me over email they're planning on using it in traffic simulation for a game, for instance.
I shared your worries about the turnover time for unit tests. But if you use something like [Midje][1] with the 'autotest' feature on, your tests will run in the background after each save. It typically takes a fraction of a second to run the full suite, so by the time I'm done hitting save and switching over to the midje console, the test results are already there.
I'm positively sure that they did. The sad thing is that they still thought that it was worth doing. To me, that says a lot about where Google's priorities are today.
> The question you may want to ask is why? By sounds of this talk it appears that his p5-mop proposal/work (https://github.com/stevan/p5-mop), which was originally mooted for perl 5.16, as probably been blocked by the Perl core team (p5p). It's a shame if that is what's happened :(
That's what he hints at in one of the slides. I'd like to know what exactly happened though, I was interested in that project.
Same here.. I'd definitely like to buy Stevan a beer to find out whats happened.
In meantime I raise my glass (again [1]) for all his great work on Moose and hope that p5-mop does make it into Perl core and/or he manages to make Moe a success.
I remember thinking how atrociously bad the idea of limiting your expression to 140 characters (or any other short limit) seemed to me. And here I am, going on my third year of being an avid Twitter user.
Sometimes ideas play out in interesting, new ways. I very much doubt that the originators of Twitter thought of even half the ways their service is being used today.
Most of the CS courses I've taken from Coursera already do all those things. The Algorithms course from Prof. Sedgewick in particular had an excellent test suite for its programming assignments.
You were graded on complying to an interface, code style, correctness, performance and memory usage, with strict requirements on the latter two. You couldn't get away with, say, implementing a brute force solution and calling it a day, you had to solve the problem optimally.
