[phzbOx]

What scare me the most about Clojure is collaborate with other devs. I.e. In 2 years, who will maintain the project.

[bkirkbri]

We're switching to Clojure specifically because of maintainability. In Clojure your functions tend to be concise, operate on immutable data structures (no side effects) and can be tested/mocked easily. The lack of boilerplate alone makes for a much better signal-to-noise ratio during review or refactoring.

I've been a Perl hacker for 15+ years and still spend too much time reviewing code from CPAN to understand what's going on. I've been using Clojure for about 6 months and find that I can read and understand many of the major Clojure projects on GitHub quickly. Some may claim that says more about Perl than Clojure, but I'm chalking it up to Clojure :)

[prakashk]

I'd be very much interested to know more about your experience and insights comparing Perl and Clojure. Would you mind writing them up?

[bkirkbri]

I'd love to do a detailed blog post on it, but unfortunately I'm too swamped right now.

The summary:

- Any serious codebase is going to exceed the complexity you can hold in your mind at one time

- Once that happens, it's crucial that you can reason about the part you are focusing on

- Interactions between components are MUCH harder to reason about if they share mutable data

- It's possible to design cleanly isolated components in any language

- But we found that Clojure makes it natural to write concise, testable and isolated code

- So much so that writing sloppy/badly designed systems _feels awkward_ in Clojure

- For us, that was more beneficial than a book full of patterns or best practices

- YMMV, but I'd try it out and be sure to get over any aversion to Lisp before passing judgement

edited for formatting

[edwinnathaniel]

Every single time I visited on a github repo of a Clojure based project, almost all of them are structured nicely (src and test) and have unit-tests.

This alone makes me think that Clojure developers are just regular people who care of the maintainability aspect of their code (and quite possibly the readability). Not just a "hacker" that writes code and jump into the next shiny stuff.

As a non-participating viewer from afar, Clojure community seems to have less hipster, less emotional, less roller-coaster, but more mature feeling when it comes to software development.

It also helps that they have a unified build+dependency tools, not a bunch of "upcoming great projects that will solve your build+dependency problem for the umpteenth time".

[adrianhoward]

As a non-participating viewer from afar, Clojure community seems to have less hipster, less emotional, less roller-coaster, but more mature feeling when it comes to software development.

I wonder if the average age of clojure hackers is higher? I'm not in the Clojure community but it appeals to me (in my forties) coz... well... Lisp! Brings back fond memories of when I shared an office with the dude who did the Common Lisp implementation for Poplog.

The folk I know who are into Clojure are all in their 30s-40s.... but it's probably just sampling bias.

[edwinnathaniel]

If the Clojure folks are in the 30s and 40s that'll be awesome: a community for older software programmers (with a few dads or even grandpas in between).

We are not going to get any younger so I very much welcomed the existence of such community.

[fogus]

The Clojure/core team helped tremendously by many brilliant people volunteering fixes, features, and docs -- just like now.

[asmala]

Indeed, the developer base around Clojure and core libraries seems to have reached a critical mass so the continuity in that front is no longer a real concern.

However, I think the question was about projects built with Clojure, i.e. how to ensure that future developers in the company I work for will be able to continue where I left off? The global Clojure talent pool, while growing, is still on the small side (e.g. compared to even Ruby).

[rbxbx]

I think this is a moot point, as we've seen time and time again using technologies such as Clojure/OCaml/Haskell/Etc is a boon for hiring great talent, not the other way around.

http://janestreet.com/minsky_weeks-jfp_18.pdf See part 4 "Personnel" for Jane Street's experience hiring OCaml devs.

[asmala]

An excellent point. Definitely something we should all keep in mind when promoting cutting edge tech choices.

That said, I don't think the matter is quite that straightforward where I come from; I would imagine Clojure dev head count in the whole of Finland is in the low double digits. If I were making business decisions involving future staffing, I would not feel confident I could replace the (hypothetical) only in-house Clojure dev in this job market.

[puredanger]

We have a team of Clojure devs and I think all but one of us has learned Clojure "on the job". Clojure is not hard to learn, imho.

[pron]

But what's the number of good developers? I think the point is that good developers can learn whatever language they need. You don't need to hire Clojure developers.

[greiskul]

Yes, thats something that some people don't seen to get. Good developers not only can learn new languages as needed, but they will learn new languages and idioms with time, else they will quickly become obsolete.

[rbxbx]

I'm also a pretty big proponent of distributed teams :)

That said, as others have noted, if you're hiring quality people, there's no reason they can't learn Clojure on the job. Plus if you make an investment in your people they're more likely to be invested in you ;)