The attitude of the Clojure community

Interesting:

“enterprise” in general is extremely conservative about change. Those companies use Java because it’s “safe”: it’s pretty much ubiquitous, it’s been around for decades, it’s easy to hire low-to-mid-range developers, you can outsource it relatively easily. If you have a company that’s bought into the whole Java stack and uses Java for “everything”, you have a deeply entrenched company and it may be extremely difficult to bring Clojure in. You might have some success bringing Scala in – as a “better Java” – because Scala is less alien to Java developers and the marketing behind Scala is focused on serving the “enterprise” already.

Having talked to a number of Java developers who work in big “enterprise” shops, one of the biggest problems is simply that the average skill level in such shops is often pretty mediocre, especially if some of the work is outsourced (and considered acceptable quality). The processes tend to be old-fashioned, the tooling tends to be years behind the bleeding edge. Even bringing Scala in can be very disruptive and the worst part is you might just end up with Java-in-Scala, without a lot of the benefits of moving to a highly expressive, (partly) functional language.

Clojure is very alien to the average Java developer. If you have a shop full of “average” Java developers who have grown up only knowing “OOP in Java”, they will struggle really badly with the functional concepts in Clojure (and Scala – which is why you get Java-in-Scala instead of idiomatic Scala). Unlearning all those OOP habits to write effective functional code is really, really hard for a lot of people. Writing high performance idiomatic functional code can be even harder. Don’t underestimate that difficulty! Take away objects, mutable state, variables, loops… a lot of Java developers are immediately all at sea and have no idea how to solve even basic problems. They’ll try to bend Clojure to their OOP way of thinking and they’ll most likely fail.

Clojure is great for bleeding edge developers and it is also great for new developers who have not yet learned the bad habits of OOP (conflating state and identity, mutability, loss of data history / time concepts).

Everything that everyone said in the comment thread on LinkedIn is true: Clojure has many wonderful benefits, you can start with a small, eager team and a high profile but relatively low-risk project, and so on. But don’t underestimate the difficulty of getting a conservative organization to switch from the COBOL of the modern era (Java) to something as radical as Clojure currently is, nor the difficulty of retraining your army of low-to-med-range Java-only programmers.

At my company, we first took Clojure to production in mid-2011 and cross-training the team – a small group of developers eager to learn new things – has been a slow, steady process. We’re at 11KLOC in Clojure with almost 3KLOC in our test suite. That’s probably the equivalent of 40-100KLOC of Java. We’re a small company with a very supportive management team. At this point, almost all new development is in Clojure with maintenance still continuing on the “legacy” code base (another factor to consider, by the way: what about your existing Java code base?). We love Clojure. It’s made development a lot more fun. We’re able to solve harder problems, make changes faster, leverage multi-core concurrency more effectively, and we have a much smaller code base to maintain. But we are about as far from “enterprise” as you can imagine, while not actually being a start-up (World Singles has been around for over a decade).

The half dozen paragraphs above are a slightly edited version of what I posted on LinkedIn but there’s something else I want to cover in this post: the mindset of Clojure.

A common question amongst folks new to Clojure, especially those who want to do web development, is “Where are the ‘batteries included’ frameworks?”. If you come to Clojure from Ruby on Rails, you’ll probably be surprised to see no full-stack web framework. If you come to Clojure from Java, you might be looking for something like Spring. The Clojure community favors small, composable libraries over opinionated frameworks. If you want to do web development in Clojure, you can pick a library for routing, a library for basic HTTP request/response plumbing, a library for persistence, and so on, and you’ll compose those together with your application code to build the solution you like best. For almost every task, Clojure has several libraries, each focused on doing one thing well and an expectation to “play nicely with others”, mostly through the idiom of building on Clojure’s core data structures (mostly maps and vectors, but also sets and the ubiquitous sequence abstraction). For some, this is seen as a lack of structure or a lack of maturity but it’s a very deliberate decision by the core of the Clojure community. Instead of just falling into a particular way of doing something, Clojure encourages you to pick’n’mix, focusing on the problem at hand and solving it in the most elegant way, rather than trying to shoehorn your solution into someone else’s way of thinking.