…or shall I say “Leaving aside object-oriented programming (in Java) for functional programming (with Clojure)”?

I seem to be getting into functional programming with Clojure steadily. And I’m serious to have it under my belt. I seem to question all I learnt so far about object-oriented programming with Java and am quite often treading on people’s toes, esp. in the Java community in Poland (where I’m active the most).

I don’t question Java features or syntax, or the way Java programmers see things and moreover use Java for everything they design. I don’t even compare Java to Clojure (I wouldn’t be able to and could cause more damage than anyone could afford to accept). What I’m doing is to be asking questions about the purpose of using Java and its tools and frameworks in a given context – an IDE, design patterns, code-compile-debug-run cycle and such.

I think the main reason is that I began noticing things which I hadn’t been able to before Clojure.

It’s also part of my learning process where I think I should leave aside the emotional baggage to Java I’ve been carrying around with me for years. I must admit I learnt how to design applications with and in Java, and it took me years to grasp all the concepts which ultimately turned me into a seasoned Java specialist (a mixture of a programmer, a application designer and an architect).

I’m way too far from claiming I know how to effectively develop Java applications, but don’t think it would take me months to learn and accustomed to it (unless I’ve already).

I’ve already gone through a couple of books about Clojure (see my take on The Joy of Clojure, Practical Clojure and Programming Clojure and vote for them should they please you) and it turns out the reading list is not going shorter any time soon (see Clojure – Grundlagen, Concurrent Programming, Java, and Clojure in Action and, to be released soonish, Clojure Programming). It turns out that all the people who know Clojure well enough have already written a book about the language or are about to do so. It’s a hectic activity to follow along with their reading. Not an easy task after all, is it?

So, I’ve immersed myself in reading the books and in the meantime am trying to find a place for my new skill – programming functionally with Clojure. And, honestly, it’s not an easy task at all. Not after so many years with Java.

But I’m not giving up. Quite the contrary. I may have found a way out – I’ll be developing simple applications around Web development which I used to cover with various Java frameworks like Apache Wicket, Seam Framework, JavaServer Faces (JSF) or recently Grails and some others.

The idea is to follow the path many Java programmers do when they start developing their object-orientation with Java EE. It’s not only about Java Servlet, but a layer atop, be it the aforementioned JSF or Grails. I’m not going to build a yet another framework for Web development (which I don’t understand so well and don’t have time for), but am going to have a bunch of very simple examples of what I used to cover with Java that should ultimately help me to present the goodies offered by Clojure.

I wish I could also be working with someone interested in learning Scala or JRuby this way. I believe it could help me have another view on a problem with the other language’s solution which would eventually lead me to find the right one in Clojure. Ping me if you’re interested.

Should you have an idea for a very short demo with Clojure, I’d be happy to hear so. Even if it’s already managed by a library/framework in Clojure, I’m up for doing it again on my own hoping I learn Clojure better (when the sources of the solution are available and will be able to have a look at a solution).

I’m thinking aloud and therefore what I wrote may not be useable at all and won’t ever be. You’ve been warned.

I’ve been reading the book “The Joy of Clojure” by Michael Fogus and Chris Houser (Manning, March 2011) for a year or so. I’ve been given a review copy of the book and remember the very first day when I started its reading – I got overwhelmed with its complexity or rather the deep coverage of the “Why” of Clojure. I wasn’t prepared for the book back then.

After a couple of months and some experience with Clojure (rather in theory than practice) I gave it another go. It worked fine this time and so I could publish a review on Amazon.com – The “Why” of Clojure – mind-bending for enlightenment with idiomatic Clojure code.

If you think you need a book about Clojure, think twice before picking up The Joy Of Clojure since “This isn’t intended as a first book on programming, and it may not be an ideal first book on Clojure either” as says the Foreword. There’re quite a few books about Clojure out there and The Joy Of Clojure offers the “Why” only. You can find the other two for the “How” and “Where” in my review.

On to reading Clojure – Grundlagen, Concurrent Programming, Java. It’s gonna be tough as it’s been a while since I was reading German books (it was so long ago that I barely remember it).

I cannot stress how important it’s to read written and listen to spoken sources of information in order to improve your own skills and gain the advantage of having the best teachers available. As a matter of fact, it doesn’t have to imply technical skills, but any skills.

When you choose your sources well, they may tremendously expand your horizon of technical abilities to get the gist of concepts that otherwise would not be in your reach (well, they would, but might incur a longer time for the learning activity). And most importantly, it’s all for free. Almost inconceivable.

I’ve just come back from a walk with my youngest, 3-week-old son who sleeps while outside, so I’m taking the chance to listen to recordings I can’t find the time to do so otherwise. Today I had a pleasure to listen to Expert to Expert: Rich Hickey and Brian Beckman – Inside Clojure in which Rich explains the concepts of immutability, persistence and concurrency abstractions in Clojure (there’s way more, but to not spoil the presentation, I won’t put all the details here).

It’s not a presentation, and neither is it a discussion (not in the sense of exchanging views with almost a 50/50 time each). Brian took a role of a moderator, and while Rich didn’t seem to need one to feel invited to talk about Clojure’s principles, it helped to tune in.

I highly recommend this recording to anyone wishing tune himself into Clojure, not by reading but listening. Same subject, but different way to reach our brain cells does have its impact. Although I learn no new things whatsoever, I could put them in order. I certainly feel enlightened and encouraged to pursue my Clojure’s endeavour.

I’ve got an idea for an app. It’s going to be a GUI app and was wondering how to start off. I’ve lately been impressed by TDD in Java (thanks @krzysztofjelski!) and thought about giving it a go to build the app with Clojure. TDD is language-agnostic, so Clojure should work fine too, shouldn’t it? When I googled “tdd clojure” I came across Midje.

From Midje’s project.clj:

“A TDD library for Clojure that supports top-down (‘mockish’) TDD, encourages readable tests, provides a smooth migration path from clojure.test, balances abstraction and concreteness, and strives for graciousness.”

The official web site of Midje says: “Midje is a test framework for Clojure.”

That seemed the right tool for my needs.

Since I’m using lein, the other google search was for “midje lein” and ended up with Lein midje which turned out not useful for the warm-up of mine into TDD.

Anyway, the project is managed by lein so a small change in project.clj was needed – add [midje "1.3.1"] to :dependencies and you should be able to run lein repl with midje available to (use 'midje.sweet). I was on my way towards TDD happiness in Clojure. Or, again, so thought I.

user=> (use 'midje.sweet)
nil
user=> (fact)
true
user=> (fact (+ 1 1) => 2)
true

That was all I needed to get up and running with TDD. Or so thought I.

When I ran the following code, I realized REPL is about to change the way I consider programming constrained by the change-compile-test development cycle (not to mention red-green-refactor one). I’m now leaning towards thinking about REPL as a kind of a TDD environment and Midje doesn’t seem to help much. It’s a part of REPL already – no, not Midje, but the idea of TDD.

user=> (fact (parse-input "1") => 1)
CompilerException java.lang.RuntimeException: Unable to resolve symbol: parse-input in this context, compiling:(NO_SOURCE_PATH:7)
user=> (defn parse-input [s]
(Integer/parseInt s))
#'user/parse-input
user=> (fact (parse-input "1") => 1)
true

I now tend to believe TDD in Clojure may be a little bit tricky and with almost no prior experience in TDD it may get even tricker. I’ll have to study the matters a little bit further before drawing conclusions, but the short meetup with Midje led me to believe TDD might not be needed while in REPL. It looks like REPL may have taken a little of an area covered by TDD in Java.