#update-in

Welcome to another issue of Clojure Weekly! i collect here a few links, normally 4/5 urls, pointing at articles, docs, screencasts, podcasts and anything else that attracts my attention in the clojure-sphere. I add a small comment so you can decide if you want to look at the whole thing or not. That’s it, enjoy!

xach/linj Let's add LinJ to the series of the forgotten Lisp2Java experiments that thanks to Github have now found a place to live for the eternity. LinJ is what Clojure was at some very early point in life, a Java source generator. This approach has a lot of practical downsides, above all the double compilation step that kills any REPL-like interactivity. On the good side instead, the fact that what is generated can be easily inspected, something that in Clojure is possible but difficult (through decompilation). LinJ also tried to imitate CL as much as possible, something that Clojure did not, proving that what is important is the Lisp philosophy, not necessarily the list-everywhere syntax. Lot of lessons coming from the past, it's good to remember.

The Weird and Wonderful Characters of Clojure Ha! Indeed, I struggled to google for some of the un-googeable clojurisms found in this page. Mostly reader macros, but also unquote-quote, splicing, deref and many others are part of the Clojure Reader power tools that make our life easier, but when it comes to search for them it is sometimes a pain, especially if you don't know/remember their english name.

ClojureDocs - clojure.core/select-keys Just when you were considering rolling your own reduce, here's a quick helper when you need to consider just some keys of a bigger hash map. Always good to remember what's available.

clojure - Update the values of multiple keys - Stack Overflow On the other hand (see link above), there is no std lib function to achieve this. Reduce to the rescue! Reduce can be used in a non-reducing way every time a sequence-able collection needs multiple updates at once, for example a map. In this case multiple values need to be sent for update. Reduce allows the partial updates to be gradually accumulated and sent over to the next element in the sequence until the final result.

Why You Should Avoid the Jargon Tail Recursion Nice short summary of the meaning of tail recursion and the danger of using the term in a semi-religious way. First of all the mandatory SICP reference. Looping constructs are described there as a patch for "bogus" compilers unable to optimise iterative recursion (recursion with proper tail call). The article suggests that we should stop using a TCO because of its too many confusing meanings. There is no direct reference to Clojure in this post, but I've heard the argument many times that Clojure doesn't have TCO so it's not a Good Language (™). Of course having to loop-recur is tedious but as a trade-off is not too bad. There is some discussing about Java 9 to finally support TCO, let's hope that's the case.

Loper OS - Thumbs Down for Clojure This is quite a popular post, one that articulates well what are the main Clojure design flaws, although what is defined as design flaw here is a design goal in Clojure: pragmatisms. Unfortunately the argumentation is not accepting the trade-off, dismissing Clojure as "revolting". As of why this post is still popular these days is pretty clear: it is one of the few completely negative review of Clojure while the rest of the world, maybe with some reservations, is accepting it as innovative and useful. I think we should still read it in a constructive way: can we "patch" the Java compromise? Can we push more of the Lisp purity in Clojure and draw a clear demarcation line between its surface and its internal implementation details? Can we fix the nasty stack traces (that is, translate the Java nature of Clojure back into Lisp when things go wrong?)

Welcome to another issue of Clojure weekly, my small routine blog contribution to the Clojure sphere! These are just a few links, normally 4/5 urls, pointing at articles, documentation, screencasts, podcasts or anything else that attracts my attention. I add a small comment so you can decide if you want to look at the whole thing or not. That’s it, enjoy!

Clojure Futures | Object Commando I already introduced Clojure "delays" last week. One main difference between the two concurrent construct is that delay executes their body only when lazily evaluated while futures go executing their stuff as soon as you create them. Futures are basically the Clojure alternative to java native threads, which includes creation of the Runnable and invocation of the run() method but with much more syntactic sugar and features. Futures are a good fit to start some expensive computation while the main thread can detach and do something else. Futures supports a timeout on deref (deref (future...) 1000 :toolong) will print :toolong if the future takes more than 1 second. A difference between a future and a native thread is that futures come from a thread pool which is shared with other potentially blocking actions. You don't get the thread pool by default with native threading in Java.

How to use "Update-in" in Clojure? - Stack Overflow As many other Clojure standard library functions, update-in was specifically designed to update nested values in a map. Please note the important fact: sometimes by looking at Clojure doc documentation for a function is difficult to understand why it's there and how to use it. This is often because the function is missing the important information about which problem was trying to solve to begin with. The StackOverflow answers exactly the context of update-in usage. Without update-in you need to to read access the map, create the new value, store back into the map. Update-in is the more idiomatic way to do the same operation.

kotarak / ClojureCheck — Bitbucket QuickCheck is a form of generative test framework written in Haskell. QuickCheck works by identifying "properties" which are roughly equivalent to rules governing a feature. So if the feature is called "inverse" and given a list it returns the same list in the opposite order, one fact that is that the (inverse (inverse list)) gives the initial input list. QuickCheck let's you define this property as a function and then it generates random list to verify if the property always holds true. Properties nicely describes a feature illustrating few important facts (or specifications, or scenario). I'm using the term scenario to capture the affinity between QuickCheck properties and Cucumber scenarios. ClojureCheck is a small library implementing QuickCheck concepts for Clojure. The property is expressed in terms of a few variables and their domains and ClojureCheck runs the property several time randomly choosing values from the allowed ranges.