Clojure Weekly, Oct 17th, 2013
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. This time there is some focus on EuroClojure 2013 coverage but for the rest, that’s it, enjoy!
EuroClojure 2013: Narcissistic Design Here's a summary of Stuart Halloway's Nariccistic Design talk. Hopefully there will be a video available at some point (couldn't find one) but the overall sense seems to be that of a parody of what Clojure doesn't do compared against many other corporate languages. As a side effect of not using Clojure you can achieve job security by obfuscation. That implies that if you embrace FP in general and Clojure you'll end up with a decreased complexity that will be easier to evolve and maintain by anyone. At least, I hope this is the sense of it! :) Anti-patterns discussed here: cryptic names, mutable state and setters, pushing language semantic down the wire, create unnecessary abstraction over simple information types, write many unit tests (hum, supposed too much testing or bad testing is bad, disciplined and pragmatic testing is good? Well don't get me started again on this).
Clojure on Hadoop: A New Hope - Factual Blog Maybe a little too old, but a good straight to the point Cascalog introduction with sample project and how to be productive right away on CSV or JSON sources. Also some interesting comparison regarding why not using Pig kind of arguments. Worth a quick spike.
A bitter taste Holy cow, did this happened for real? I was following the usual tweets over the conference and noticed the usual pro Emacs tweets, which is fun and expected. This could be just a rant, but knowing Kotarak I think his post deserve attention. So do I need to think that Euroclojure was about mocking diversity in a non-constructive manner? I suppose that's not true, but still concerned about somebody leaving the stage with a bitter taste. Is the Clojure community becoming more and more intolerant? (I'm thinking about the other rumor discussions about the supposed uselessness of TDD). Discuss.
On Testing and the REPL in Clojure Sorry for my persisting on the TDD subject, but it really makes me sad whenever the "clojure community" thinks they've found a language that fixes the problem with TDD. This post reports about some informal chatting at Euroclojure 2013, so it is possibly one point of view. At the same time, I also experienced the same talking with fellow Clojurians. The problem with TDD as described here is not a problem with TDD, because the definition of TDD given here is as a tool for problem space exploration, something you use to acquire enough knowledge about a tool, library, API or framework to actually implement the solution you need. Never heard of that as TDD and of course those "tests" get in your way and you'd better use the REPL for that. All totally fine if you want to create a few tests after the fact to cover for regressions. But please, don't call that a fix for TDD, call it a fix for the need of exploratory code that doesn't fit very well in unit tests.
Towards core.matrix for Clojure? | Creative Clojure I'm looking into the Clojure matrix world for the first time and this post by Mike Anderson aka Mikera illustrates what is the current standardization status. Or maybe I should say what used to be the standardization status because despite core.matrix is not yet accepted contrib, a lot of effort has been put in the right direction. As explained here, there are many robust matrix manipulation libraries with specific focus on one aspect or another. Core.matrix is attempting to unify those under a standard API. It's already using NDArray as the default implementation and optional implementations are available for Clatrix and vector-clj.
How to access static inner Java class via Clojure interop? - Stack Overflow This is about the dark side of Java interop, when things go crazy. Clojure is already preventing you (by design) to have wildcard import of an entire package of Java classes. Okay, then you list them all. A side effect of this approach is that you'll have to list static inner classes as explicit imports as well. I agree, this is something that doesn't happen that often but just in case this is what you need to do to import it. Then you need the dollar sign, for example: OuterClass$InnerClass/staticMethod.
