In this post I want to emphasize another not less important aspect: Productivity. With Clojure we get a whole lot of stuff done. Seriously.
Admittedly, I was mildly shocked and a bit scared when stumbling over @ZackMaril's recent tweet claiming Clojure was a dying language. A huge discussion was sparked and a lot has been written since. A summary can be found in Arne Brasseur's post which also offers some good insight into the community behind Clojure. Eric Normand added another layer of abstraction today and collected some more links in this week's Drama edition of the purelyfunctional.tv newsletter.
I share Dan Lebrero's sentiment on Clojure. Clojure taught me lessons and introduced concepts to me that I do not want to miss any more. First and foremost I love the built-in immutable collections. Immutability as default is a milestone in my life as a developer. I compare it to git pair-programming, continuous integration and IntelliJ IDEA (with Cursive now, of course). There was a time when I did not even know about each of these. Now I cannot imagine to ever work without any of them.
My team is working with Clojure for almost three years now. We came from an all-Java world and decided to be a polyglot team We chose Clojure, Scala and Python to be our primary languages. None of the developers that joined us since has had any prior experience with neither Clojure nor Scala. With our pair programming routine and our microservice architecture we get newbies started up quickly, however.
From this experience I can testify that Clojure is more than easy to pick up. New team members - from student interns to seasoned hackers - are usually productive in days rather than weeks. Our 'non technical' team members - production leads, business designers and the like - started hacking Clojure, too and are now able to automate some of their tasks and also to help out the developers.
The fact that Clojure has hardly any syntax and its strive for a radical simplicity contribute to the ease of picking it up. This is much in contrast to e.g. the syntax-heavy Scala.
Imagine the following situation: You have some change to apply to your software. By gut feeling it might take the afternoon. You sit down with your pair/buddy and discuss the problem. You are TDD-folks, so you write a test that assumes the yet to be built functionality. It is red. You say"Ok. Before we start coding, let me quickly draft this in some simple pseudo-code."You do just that. Your pair runs the test. It is green. You look at each other "Are we done?"You look at the code again. You are. It's been 20 minutes.
This experience you could not have explained to my former java-developer-me no matter how hard you tried. Yet it happens every day. Clojure has that way of seemingly effortless materializing one's thoughts into working code that I do not know from any other language. (There is, of course, plenty of languages I don't know).
When analyzing a piece of Clojure code, the code itself quickly steps aside and opens the the view on the problem at hand. It is again the minimalistic syntax and the focus on simplicity that make it easy to reason about the code. The language imposes little mental overhead when investigating issues. This is even true when discussing the problem with someone that does not know Clojure at all. It's within minutes that the discussion moves from analyzing the code path to the business aspects of the problem.
This also extends to library code which oftentimes is astoundingly concise and gives you a fair chance to understand the inner workings of a library. Again this is not necessarily true when dealing with a language that is richer with syntax options.
In the recent discussion it was often said that Clojure does not per se make a team more productive. I think the opposite is true. Clojure's design decisions do result in an amazingly productive language.
It is efficient to develop new functionality. There are little barriers in analyzing problems and exploring unknown code. It has excellent tooling. It's fun. Is it dying? Heck, no! If you wanted to kill it, you'd have to wrestle it from my cold, dead hands first.
I can only guess that we are representative for a whole lot of teams in a whole lot of companies which happily and quietly enjoy the productivity of Clojure. No Drama
[…] With Clojure we get a whole lot of stuff done. Seriously. […]
Hi Peter, great question!
We as a team were in the fortunate position to build a new thing from scratch. We were used to developing rather large systems and and decided to go for a microservice architecture now. So there were two paradigm shifts to handle at the same time. Luckily they were of mutual benefit. Treating an HTTP-response as the function of the request is an excellent stepping stone to FP. Doing so in a small, simple service makes it easier to do so in a new programming paradigm.
Generally I see three ways in that teams are transitioning from Java to Clojure:
1) Build something new from scratch.
2) Factor out some functionality from a monolithic software into smaller services.
3) Adopt some tools (like lambdacd-pipelines, or oscillator) that are written and configured in Clojure.
For the first the transition seems to be the easiest. For the third least so. Still it is not a big problem.
Schöner Artikel - macht neugierig auf Clojure!
I’m desperately trying to get clojure into our company – it’s a tough sell, with no success so far:
People simply do not believe that it will be way better that their existing environment.
Thank you very much for your post – it’s very encouraging!
Just wrote first lines of clojure again today.
I love it
To Christian. How did you manage the paradigm shift? Its a huge shift from OO to Lisp. From object interaction to functional composition, from mutable to immutable data structures. How much re-learning was involved?
Hi, what are your Scala use cases - in contrast to Clojure? And because I'm getting used to Scala: 1/2 honk ;)