Re: Do this or that

I agree - I always use the second form. Generally I find that I often need a let-block for each branch of the if, so I nearly always avoid the need for an explicit 'do'. On 7 October 2014 14:54, wrote: > I agree with James. The first can be tempting when you're doing side > effect heavy code (wh

Re: Do this or that

I agree with James. The first can be tempting when you're doing side effect heavy code (which should probably cause you to take a double take on how you got to this point anyhow) but the most glaring issue that is all too easy to overlook is that they aren't actually equivalent expressions. Even

Re: Do this or that

The latter is what I'd consider to be the correct approach. If the do blocks become unwieldy, you can factor them out into functions. - James On 7 October 2014 02:16, Mike Fikes wrote: > Here's a style question: If you have to conditionally do one set of side > effects or another set, is your

Re: [ANN] async-sockets - work with sockets using core.async channels

Could you please expand on this, Zach? > Please note that if you use core.async with java.nio, you need to make > sure backpressure is properly propagated (this happens automatically with > java.io, assuming you have a thread per connection) > Thanks! -- You received this message because y

Do this or that

Here's a style question: If you have to conditionally do one set of side effects or another set, is your preference to use when and when-not, or an if containing do blocks? Or perhaps some other construct? In terms of a concrete example: (let [boolean-value (some-predicate?)] (when boolean-va

Re: Advice for building backend REST services from scratch using clojure

Hey Colin - thanks for the kind words! And I must apologise for my last previous comment too - I actually meant to come back and do so but didn't for whatever reason. It was one of those comments that sounded better in my head than when I saw it written down later - I'm sorry about that. I'm sure y

New Functional Programming Job Opportunities

Here are some functional programming job opportunities that were posted recently: Senior Developer at Lyminal, Inc. http://functionaljobs.com/jobs/8748-senior-developer-at-lyminal-inc Full Stack Functional Web Engineer at Front Row Education http://functionaljobs.com/jobs/8745-full-stack-f

Re: core.async: peek the next value from a channel without consuming it

Add one more chan, "external ready". Put :ok there to let producer generate new value. producer: - read from "external ready" - generate value - put into "outgoing" chan client: - contact external server, put in "external ready" if ok - read from "outgoing" chan - send to external Handle excepti

Re: [ANN] Monroe 0.1.0 - nrepl client for Emacs

Bozhidar Batsov writes: > Yeah, they should definitely remove nrepl.el support from > ob-clojure.el. Done in the master branch of org-mode, thanks. -- Bastien -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to c

Re: Advice for building backend REST services from scratch using clojure

Just FYI - I got a new laptop and thought I would give it another look-see. Consider me impressed. I maybe didn't spend enough time with it, but a lot of the rough edges have been smoothed out, the performance seems to have increased, it is just a really nice place to be. To be clear, emacs roc

Re: [ANN] rmap - define lazy, recursive maps

Thank you for your kind responses! I will look into writing a post that shows what the motivation was (i.e. how I use it), how it works, and how it compares to Prismatic's Graph. Cheers, Arnout -- You received this message because you are subscribed to the Google Groups "Clojure" group. To po