Clojure weekly Aug 09-16 2012

Welcome to this issue of Clojure Weekly. Clojure Weekly are just a few links to clojure-related posts, blogs, screencasts, presentations or podcasts I found over the Internet. I added a summary to each one of them so you can decide if you want to spend the time to look at the original! That’s it. Enjoy.

065 RR Functional vs Object Oriented Programming with Michael Feathers This time the Rougues are confronting a delicate argument, OO vs FP. Unfortunately I’m not happy about the way they handled it, starting from the fact that didn’t invite someone from the FP community to join the talk. There are also the usual common places of OO guys talking about what FP is: use immutable data structures to avoid memory overload and list comprehensions are not the essence of functional programming. BUT, but, there is some good point to reason about. OO was not translated properly from the original Alan Key propositions of components sending messages between each other. Today we are talking about “Tell don’t ask” to remember our self that objects should be communicating asynchronously. The Actors model of computation is typically an OO pattern that implements message passing. It’s strange nowadays to see actors being used as a strong argument to adopt FP instead :) A lot of incidental complexity in OO was introduced over the years. OO gave up reusing in the small. OO ended up reusing architectures and frameworks instead. It’s so difficult to tell when FP or OO is more suitable to solve a problem that the best thing is trying to put evidence together. What evidence do we have these days? Michael Feathers’ blog post (http://michaelfeathers.typepad.com/michael_feathers_blog/2012/03/tell-above-and-ask-below-hybridizing-oo-and-functional-design.html) describes the situation where FP works at the bottom while it becomes OO rising the abstraction at the top. It seem that OO is great at modeling large systems because we’ve seen very large OO systems. What are the large FP systems instead? Can we demonstrate the same for FP in handling large systems? Maybe there are no large FP systems because ‘data’ is large in FP. You take all the data complexity out and put it in an hashmap of some sort. All the complexity in FP seems to move to functions. To summarise: both FP and OO are going to have their in programming but nobody at the moment knows where exactly.

Nathan Marz: “Cascalog: Making Data Processing Fun Again” | Clojure on Blip I’m impressed by this presentation of cascalog, although I was overwhelmed by the increasing complexity of the queries half way through. But I don’t think that’s important. Queries are going to be related to a business domain that requires a bit to grasp. What’s important is to see how much SQL you just avoided by comfortable stay inside your beloved Clojure. Declaraive programming allows you to work your query complexity over functional decomposition without the need to become a sql guru (because I suppose you can do most of that in sql as well). Also consider you can test drive cascalog and use your favourite debugging setup. I cannot imagine how to do that in some proprietary sql environment. Something I need to understand better is how everything in cascalog seem to map and reduce. How exactly a query gets map reduced? Is that always possible? Finally, a concern I have is that cascalog, the clojure implementation of datalog, datomic query language all seems to solve the same problem with a slightly different syntax. Is this the right time to think about an uniform standard?

Jay Fields’ Thoughts: Lessons Learned while Introducing a New Programming Language I enjoyed this reading, a very insightful guide to migrate your team to a new language (in this case Clojure over Java). The first step is parallel development of features off work and comparison during office hours. Non production code is a good place to start: tests, log parsers, simulations, migration scripts. You should be prepare to re-write the new part back to the old language if somebody is having a lot of difficulties. Something else I didn’t think about: it’s okay if part of the team is working on the old language and other people are working with the new if they don’t want to follow. I’d like to add: if your company has a teaching/learning department engage with them to offer Clojure courses, presentations, dojos and so on. Another comment: there is a fight on two fronts. From the above: management should recognise the business advantages of the new language. From the bottom: developers should scream their frustration with the old language and ask to move to the new. There are many other takeways. 1. the new language must be almost as fast as java 2. if the company is already JVM based, it must be on the JVM 3. Causing the least amount of pain possible to teammates, adapting to current development env (for example, run on IntelliJ, right click run tests, CI integration, profiling)

leiningen/sample.project.clj at master · technomancy/leiningen The other day I had the following question for Google: how can I tell leiningen that there are other sources which are not in the default src folder? I had a good 15 minutes search and then found the all-you-can-eat version of the project.clj from the leiningen repo itself. This is all you need to understand what you can do with leiningen, and the list of options is long and well documented in this sample project.clj. My question, for instance, is answered by the :source-paths option. At the bottom you’ll see that lein is going to obey a few of the usual Java environment variable suspects that will be passed to the JVM, like jvm_opts. Well done.