Is it only me experiencing an issue with running the most recent build of Leiningen 2 with the recent OpenJDK 8 x64-lambda JDK with Lambda from jdk8 branch (b35) (OpenJDK-OSX-8-x64-lambda-jdk-b35-20120507) on Mac OS X?

With the version of OpenJDK selected in the Java Preferences, lein2 finishes with a stacktrace.

Here’s the full log of the steps to reproduce the issue. Is it Clojure 1.4 or lein2?

With the version of OpenJDK changed to 1.7.0-jdk7u4-b21, it works fine.

Reversi in Clojure w/ Three Alternative User Interfaces is the type of blog entries I enjoy the most – it inspired me to think about functional programming in Clojure and found it a great “platform” to work on my understanding of Clojure’s way to functional programming. I hope I didn’t mess it up and am on my way to functional programming nirvana.

The idea was to find all the places where mutation happens or may be incurred (due to a type/data structure used) and find their functional counterparts.

The very first finding was the if statement in the function opposite-piece. As I wrote in the blog entry Protocols more functional than if in Clojure?, I tend to believe that the if function resembles the imperative if statement so much that whenever I find it in a code, it encourages me to think about another approach.

What about this version of the opposite-piece function?

To me it looks more functional.

The other piece of the code I found intriguing was the function initialize-board which uses a less functional data structure – a vector – not an immutable list – the truly functional data structure (which was the foundation for Lisp and later Clojure). I think a list (or a sequence in general) invites to a thinking in a functional way, with no way to mutate its content since it’s immutable by design (so is a vector in Clojure, but it may easily mislead an untrained reader coming from Java or another OOP language).

I consider a vector an imperative data structure and a sort of mutable list or vice versa – a list as an immutable vector (even though the distinction doesn’t exist in Clojure). I’ve seen lists used instead and whenever it happened it was a mental challenge for me. I enjoyed it and was keen on introducing it in the game.

So, from that moment on, I was using a list not a vector in initialize-board. And the fun began!

As a starter, let’s consider the following 3×3 board with 0′s.

I wish I could have a picture of a board to accompany the snippets.

You may also use the function partition.

How could you change, say increase, the 0′s in the position you’d call (2,2) – the central 0? Let’s assume we start counting the rows and the columns from 1 onwards.

The pure function could look as follows:

Let’s see how it works.

It works! My very first take on refactoring of the game to a more functional version works well.

There’s a serious issue, though. We iterate over the sequence board three times – once when we calculate the elements for the left side of the output sequence, another to get at the value to increment and yet another for the right side. It’s certainly not very efficient.

The other solution was a recursion with a counter – a sort of functional for (not to be confused with the for function for list comprehension).

Let’s give it a shot!

It works fine again. Is it better? I’m still unconvinced, esp. the split-fn looks terribly. I need a version without any mutation, even with atoms, refs or agents. Would you mind lending me a helping hand? How would you change the function inc-at-v2 to be more effective and look prettier?

While reading Ring Handlers – Functional Decorator Pattern…

How often do you perform conditional branching with if? The answer may likely rely upon the available features offered by the language of choice – the if statement/expression (Java, Clojure), pattern matching (F#) and dynamic dispatch (Java, Clojure).

When I read Conditional (programming) in Wikipedia I stumbled upon the following sentence:

“Although dynamic dispatch is not usually classified as a conditional construct, it is another way to select between alternatives at runtime.”

It made me think about its implementation in Clojure. I could definitely tackle it with method overloading in Java (that was dumb easy to figure out), but what about Clojure?

At the moment I’d come up with a possible implementation in Java, Clojure’s Protocols sprung to my mind. I’ve been reading about them, mainly in books and very rarely in articles, and have never used the concept before. It looked like it’d change.

Protocols are like interfaces in Java and beg no special treatment of nil (counterpart of Java’s null which begs a casting to appropriate type).

Below you can find a simple Protocol implementation in Clojure and its use. Fire up lein2 repl and follow along.

It works, but I’m still uncertain about its applicability for a simple if-then expression, meaning as an alternative for a flat, single if-then expression as in the use case above. It appears to bring no value in simple cases and may result in more work for not much benefit. Does it?

You may also find OCaml: Pattern matching vs If/else statements or if-else branching in clojure useful to tackle the issue. The last reference made me thinking about nested if statements with their own else branches. Doh, I thought I was done with it.

There’s also Clojure’s multimethods concept which seem as much applicable to the use case as protocols. Doh doubled.

I’ve also added org.clojure/core.match to a S.I.L (= Seemingly Inevitable to Learn) bucket.

I made some changes in a Clojure project – librarian-clojure. The changes revolved around security in a Compojure web application. What I needed was to check whether they’re correct and hence I needed some tests with mocking involved because the functions the changes were introduced to used external sources – MongoDB and an encryption library. I didn’t mean to set up the environment, but just enough to get the task done. And it should be fast and quick.

The functions are used in a web application, but neither a web container nor a Request object was necessary since Ring turns HTTP requests into…maps. Moreover, I knew Clojure could replace function definition (a var) on the fly for a single thread with binding, but Clojure 1.3 comes with the with-redefs-fn function that “Temporarily redefines Vars during a call to func. (…) Useful for mocking out functions during testing.” I didn’t have to define a dependency and have a framework to work with. Life couldn’t have been easier!

I’ve been doing Java programming for years, but only recently have I been exposed to the aspects of Test-Driven Development (TDD). I think I know the benefits and the rules, but applying TDD was more a belief in its added value not a way to think. I simply didn’t care (perhaps because I wasn’t paid for programming and was only doing it in my spare time, often sidetracked by other activities).

I’ve also been leaning quite recently towards believing that despite repeated assurances of TDD applicability to and increased quality of applications developed in Java or any object-oriented languages, TDD was simply too laborious.

I think that TDD in Clojure (or any functional language) is so much easier and…fun!

Firstly, there’s a REPL where you can do it interactively. Secondly, Clojure’s dynamic. Thirdly, there’s no “overhead” with object-oriented hierarchy since “weakly” structures like maps suffice. All these seem to suggest that Clojure may easily be the language of choice for TDD.

Have a look at the following session in Clojure’s REPL to experience it yourself. Even thought it’s far from TDD, it led to using the fake functions with no pain (and eventually I found out that Midje might’ve done it better. Next time.)

After I published the blog entry Clojure’s REPL, lein, pomegranate and classpath, Sun Ning commented that lein2 uses pomegranate internally as the dependency resolution management tool. Well, it was a bit convoluted in a sense, but meant exactly this. It later turned out that a single sentence “Leiningen 2 has move its dependency management core to a new library, called pomegranate.” made my day as developing Clojure applications in Clojure’s REPL became even easier. I guess also that presenting Clojure development live should change, too.

From now on, I become a proponent of using lein2 as a mandatory management tool for people who start their journey into Clojure. Consult the Installation section in Leiningen’s README.

Give yourself a couple of minutes to have a better exposure for the changes.

1. Run lein2 repl.
2. Execute (use ‘[cemerick.pomegranate :only (add-dependencies)]).
3. Use (add-dependencies).

You may also want to read in which we coin a term which is the opposite of deprecate about the other reasons to switch to lein2. Don’t forget to read the comment for the blog entry:

“Somehow I forgot to mention that the repl task has been totally rewritten in Leiningen 2; it features readline-ish input without rlwrap and has great completion.”

I must admit I hadn’t noticed it before having read the comment, but had been using it already (!) I tend to get used to useful features very easily without noticing it.

Lots of great stuff in lein2. See Leiningen’s Upgrading for more.

Thanks Chas, Phil and Sun Ning! I’m deeply indebted to you for your help. Gonna use it during the upcoming conferences in Poland where I’m presenting Clojure: DevCrowd, 4Developers, GeeCON and hopefully Confitura.