Welcome to another issue of the Clojure Weekly! The Weekly is a collection of bookmarks, normally 4/5, pointing at articles, docs, screencasts, podcasts and anything else that attracts my attention in the clojure-sphere for the last 7 (or so) days. I add a small comment so you can decide if you want to look at the whole thing or not. That’s it, enjoy!
cgrand/confluent-map: A persistent confluent map for Clojure cgrand recently did some work to improve performances of merge operations for Clojure main persistent data structures. The promise of ConfluentHashMap is not to be less performant than the core PersistentHashMap implementation for all other operations. Performance improvements are linked in this gist https://gist.github.com/cgrand/ecab0e13d1e7ff64a2d2 and are interesting, although dependent on the size. Basically use it if you know what you’re doing! Apart from that, understanding the concepts and the code behind this little library is a nice exercise to also understand the implementation of persistent data structures in Clojure.
Getting Started with Self-Hosted ClojureScript Nice series of 3 articles about self-hosting ClojureScript. Self-hosting ClojureScript means that after the first bootstrapping in the browser you’ll be able to evaluate ClojureScript in the running process without the need to use again the bootstrapping compiler. This possibility with cljs was announced not too long ago and enables many interesting things, like for example writing ClojureScript application targeting mobile devices. The 3 posts series shows which steps are required and what are the challenges.
After the Honeymoon – Keeping the theory alive I like this post from Jon Pither where he formalises what I’ve been experiencing basically in every single software project I’ve been. I also happen to work on one of those projects that Jon left “after the honeymoon” but I don’t think that changes a lot my perspective on this. I call them “design streams” you can clearly see them stratifying in code, developer after developer. It’s difficult to pay active attention to them and they accumulate like refactoring debt (the most visible manifestation of them being code duplication, but there are much more subtle symptoms). So what to do? Jon suggests a few tips to, at least, raise awarness. I’ve also used to keep a list of all open design streams (for example: refactoring of module A into separate service, or use new language feature X for this kind of problems and so on) with satisfying results. Reality is the won’t ever be 100% under control, despite all efforts. So Jon’s suggestion to keep them well isolated and easily re-writable seems to be the way to go. Go micro-services!
trampoline – clojure.core | ClojureDocs trampoline seems innocuous at first: it just keeps invoking a function until it returns functions. The implementation is also quite simple. But it enables mutual recursion without consuming the stack, something a bit theoretical that still has some important applications. Recursive parsers are one of those, as well as state machines implementations. Use every time you have a function f calling g and then calling f again (even with other functions in between). They just need to be in tail position (but recur will warn you).
Curry On Rome! 2016 CurryOn was one of those conferences I wanted to go last year. This year it will be in Rome and it will be hot! Literally, July. The line-up is already impressive: books and languages authors with a functional twist. David Nolen is bringing the Clojure[Script] view of the world with a keynote, same as Larry Wall of Perl fame. Other speakers are an interesting mix of academia and industry. I also like the idea that some talks will be using a ping/pong format with a max allotted time of 20 mins for speaking and the same for questions.