#linj

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?)