What is the business value of Clojure?

Is there some reason a business would choose Clojure over other languages? Let's find out!

Transcript

Eric Normand: What is the business value of Clojure? Hello, my name is Eric Normand. These are my thoughts on functional programming.

I was watching a talk by David Nolen the other day. David Nolen is the maintainer of ClojureScript. He's done quite a lot in the Clojure community.

In the talk, it was to beginner programmers about starting their careers. At the end, he mentioned that he thinks that for a business, the choice of programming language is mostly a hiring decision. The programming language is not going to change the business's success. It's mostly about hiring.

I've been wrestling with that because I've been trying to figure out what the business value of Clojure is. I thought that maybe it has to do with the reduction of risk because Clojure lets you quickly experiment, quickly develop solutions so you can quickly evaluate whether a solution is going to work for you. You're mitigating the risk that way because you have such a small investment.

I've been taking to his idea more and more because I want to explore that more deeply. When you choose a programming language unless it is something super specialized that gives you a huge advantage in the area you're in. If you choose Ruby and Rails for your architecture because you're doing quick one-off Web apps, that might give you enough advantage to warrant you choosing that just for the business value.

What he was saying was in the long term what matters is the processes, thinking, the architecture of your system, and how well you program it. I have to agree with that.

Does that leave any room for Clojure?

Language choice is a hiring decision

If language choice is a hiring decision, why wouldn't you just go with Java, JavaScript, or Ruby? Some of the most popular languages out there. Then you'd have more hiring options.

https://twitter.com/ericnormand/status/1056984596414451713

When you choose a more obscure language like Clojure, you're choosing who you can hire, or who you will be hiring. You're choosing a hiring pool. The advantage of Clojure is that you will be hiring Clojurists and tapping into that community.

https://twitter.com/ericnormand/status/1023583994854735873

To me, it makes a lot of sense. Clojurists are different from Javaists on average. That's all you can do when you're looking at programmers as an aggregate. You have to average them out.

Here's the thing about hiring and getting hired. That ultimately, it's a numbers game, but you only need to hire one person for your position. You only need one job. Ultimately, at the end, it doesn't matter how many candidates there are or how many jobs there are that you could get because you only need the one.

https://twitter.com/ericnormand/status/1046052642361929728?ref_src=twsrc%5Etfw

If you want to play it as a numbers game like, "I'm going to use Java in my company because I can always find Java programmers," you'd have to imagine the programmer you're going to get. There are a lot of Java programmers. Just by the fact that Java is taught at a lot of universities, it might be that programmer's only real language, only language that they've worked in before.

You have to think that is going to affect the quality of the candidate. A candidate who knows several languages, has been part of different communities, and understands things from different angles is going to be a better programmer.

Typically, that's what you get with a more obscure language like Clojure. This used to be the case for a language like Python. People used to talk about how Python was a good language to hire for.

Knowing Python meant that you were a little bit more curious. You were more willing to learn a new language because you probably didn't have it at your job. You weren't paid to do it. You were the programmer who would go out of their way, probably, in their spare time to learn a new language. Probably, that's the case right now with Clojure.

The applicant should learn Clojure for developer happiness and the job pool

I do want to talk a little bit about what are the benefits of learning Clojure for the job applicant. David Nolen mentioned this, that on the programmer's side, the real reason to choose one language over another is developer happiness. There's also job pool. That's an important consideration.

https://twitter.com/ericnormand/status/1016698858527707136?ref_src=twsrc%5Etfw

Developer happiness is also a real factor. If you're happy in one language and not another, you should take that into serious consideration when choosing a language. It could make a real difference.

Developer happiness, as far as Clojure is concerned, I think that there are two main reasons that Clojure can increase developer happiness. One is that Clojure has very fast feedback. The other is that Clojure doesn't get in your way.

https://twitter.com/ericnormand/status/1048287630562131968?ref_src=twsrc%5Etfw

Fast feedback

I believe that Clojure is the language that has the best support for REPL driven development, for interactive programming, for live programming.

These are all different ways of saying the same thing. In Clojure, you will write code and you can see whether it works immediately. This is something that you get in most fields of making, of invention.

You are doing some woodworking, you pick up a tool, and you start carving your block of wood. You can see is this tool going to get me where I want to go. You can tell pretty quickly that you're on the right path.

You can then get into a nice flow because you are confident that you're moving in the right direction. You can get into a rhythm of working.

One thing that happens a lot in programming is we have to write a lot of code before we see anything work, before we see anything happen. Then we have to go back and figure out why it didn't work. If that cycle is too long, there's a lot of stress involved. It's distressing to work and not see the results of your actions.

https://twitter.com/ericnormand/status/1056199562900180994?ref_src=twsrc%5Etfw

That's fast feedback. I think that can help developer happiness.

Out of your way

The other thing is the amount of BS work that you have to do. What I mean by that is a lot of languages have you create abstractions just for abstractions sake.

The abstractions don't help you with what you're trying to achieve. I'm going to call out some languages like Java — where it might not be the language itself — but the community, certainly, is very much into abstractions that don't help so-called design patterns and things like that. It's not that the design patterns themselves are wrong. They're overused and over-valued for what they give you.

By going with Clojure, you're choosing a language that makes lean abstractions, just the right kinds of abstractions, and amount of abstractions easy. That's what you're buying into for developer happiness. Just getting rid of all the boilerplate and bureaucracy of the language.

That's the developer happiness side.

Community

Then there's also this other side of buying into a community. You're choosing your peers. Because companies should choose the language to pick who they hire, a programmer should pick a language based on who they want to work with, who they want to communicate with, what conferences they want to attend. That's the community aspect.

If you want to learn what Clojure people talk about, if you want to be involved in that community, and be around people who are thinking about the things that Clojure programmers think about — you can tell what that is by the conference talks, the blog posts, the podcast, what people are working on, what they're talking about. That's another reason to choose the language.

There you have it. You've got both sides. You've got the hiring side and you've got the being hired side. Why choose any particular language? I just happened to use Clojure as the example there.

All right. My name is Eric Normand. Please subscribe if you enjoyed this. Please tell your friends. Share it, like it. I appreciate you being here. Thank you so much.