#norvig

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!

zcaudate/lein-repack · GitHub Interesting idea. The goal: avoid copy paste for functional re-use. The background: we all seem to have an clj-util library, where we store functional bits across projects that are generic enough to be reused elsewhere. At the same time this clj-utils is "personal" and when I find someone else snippet I'd like to use I don't want to have a dependency just for that. So, copy paste into my clj-utils! (with attribution). What if instead there was a "function" repository? What if the granularity of re-use was the require of a single function from another library? While we are thinking about it, lein-repack takes that a step further by treating namespaces in a project as separate deployable entities (that is, producing a separated set of libraries). With a little bit of namespace design, lein-repack makes it possible to require just a namespace of what used to be an entire project require. Still a project.clj line in dependencies, but a step further into a better re-use.

Tutorial on Good Lisp Programming Style - Peter Norvig Very lispy indeed. But tips on functional abstraction applies to Clojure as well. It is also a must read in terms of principles of good style in programming, expressing intention and good functional engineering in general. The format is also very readable, a mix between a slide-based presentation and a full paper. The bit I enjoyed the most is the rule of english translation for functional decomposition: 1. start with a sudo-code english description of the algorithm 2. translate to working code 3. translate code back into english 4. compare 3 to 1. If 3 is much more articulated than 1, you're missing functional abstractions (i.e. extract function). 1 should read as 3 with all complexity extracted into helper functions.

The Clojure REPL; a blessing and a curse This article by Martin Trojer really resonates with me. I'm very happy to have a component-based lifecycle for my Clojure projects. At the same time, when I first heard about Stuart Sierra Clojure reloaded workflow, I thought that the effort wasn't entirely justified. The component workflow to keep the REPL alive at all costs doesn't seem to be scaling over a certain level and maybe it is time to re-design the Clojure static initialisation context in a different, more lazy, way. Keep in mind that the problem is not Clojure at all, it's a fairly fast and close to Java performance env. The main problem seems to be the development lifecycle.

Why is Clojure bootstrapping so slow? This article is a fairly detailed analysis of the Clojure bootstrap time. Clojure projects are reaching a "critical" size in live environments, where bootstrapping with all the dependencies can take up to a minute or more (I'm not talking about the hello world used as an example in this article). Clojure component-based workflows are helping mitigate the problem, but restarting the REPL for development is still a frequent operation. So what is the problem exactly? Clojure bootstrap is basically a giant Java static initialisation context. All Symbols to hold values or functions are first defined (metadata included) and then Vars are initialised so they point to the specific symbol (function or value). This happens for each var declaration in clojure.core plus a few helper namespaces that are loaded on a side. Each namespace results in a Java class byte code (loaded at runtime or AOT compiled), its long static initialiser and one inner class for each fn. The main take away of this analysis is that what is not used should be loaded lazily.

Chomsky attacked AI recently for relying on statistical methods (such as machine learning) to approximate sets of data (think of Google translate and how it figures out how to translate some new sentence). There's a lot of sources available, for instance this.

These methods, incidentally, have proved to be very efficient--which is, according to Chomsky, exactly why they've led AI on a wayward path. His point is that these methods are good if what you're after is to approximate large portions of data. But science isn't about that, he says, it's about getting insight and explanations of what you're looking at, and that is typically achieved with an overarching theory and general principles. Statistical methods don't provide that.

Well Peter Norvig, who wrote the textbook of AI (literally), offered a reply to Chomsky, defending the use of statistical methods.