Clojure Gazette 191: Where does Clojure shine?

Free Beginner Workshop

From OO to Clojure Workshop!

Watch my free workshop to help you learn Clojure faster and shift your paradigm to functional.


Where does Clojure shine?
Clojure Gazette
Issue 191 - September 19, 2016

Hello, friends!

Thanks so much for reading my essays every week. This is a place where I explore ideas and try to stimulate some discussion. It's an ongoing experiment, and sometimes good experiments blow up in your face! Sometimes I say things that are not true. Those stimulate the best discussion :) I won't apologize for opinions supported by argument, but I do feel like I should correct myself if I get something factually wrong.

Last week I wrote about Object Oriented programming and how it tried to help code reuse. I said that Java (the language) recommended getters and setters. Well, that's actually untrue. Java did not recommend it. Getters and setters come from the Enterprise Java Bean spec, but they were never recommended per se. They were supposed to be an easy way to tell GUI builders what fields could be inspected on your objects. They were never meant to be called directly by your code. Unfortunately, they've become extremely common practice. In many IDEs you can generate them automatically with a couple of clicks. As far as I can tell, nobody recommends getters and setters, yet they are all over the place.

With that aside, I'd like to talk about a question I get asked all the time when I talk about Clojure: "What kinds of programs is Clojure used for?". I've been stumped by this question many times, mostly because I just couldn't figure out what the person really wanted to know.

For instance, if I said "Oh, anything, really. It's general purpose," they didn't really seem satisfied with the answer. Or if I talked about parallel programming: "It lets you take advantage of all of your CPU cores." Is it a language for software efficiency? Or if I listed the places where Clojure is commonly used: "Web, big data, realtime data processing, machine learning, etc." it just seemed like they lost interest instantly.

After many attempts at answering the question, I recently tried a new approach: what if they're just prompting me to brag about the language's awesomeness? This may seem like an obvious interpretation of the question, but I'm one of those literal-minded programmers with a Garbage-In, Garbage-Out brain module that doesn't shut off when I leave the computer. It takes a while without programming (from days to weeks) to really stop me from hearing the obvious if it's not phrased properly.

So with that new interpretation, I really have been enjoying the discussions that it brings up. For me, Clojure is all about simplicity. Real-world problems are inherently complex, so you don't want to add to that complexity with a complicated programming language. Your language should let you untangle the concepts and put them together in an orderly way.

It's still a new approach for me, but so far the reaction from the questioners is fascinating. Some people claim that they've never thought about programming like that. Others start talking about how many hoops they have to jump through to get anything done in their language. And the discussions are great.

So, I have some homework for you:

  1. Try out this interpretation of the question for whatever language you're asked about. Report on the results.

  2. Tell me what you think Clojure is good at. Do you agree with me? Is there something more important? Hit reply and let's talk.

Rock on! Eric Normand <eric@lispcast.com>


PurelyFunctional.tv is the best place to learn functional programming. At least that's what I'm trying to make it. And I need your help! I need other teachers who want to share the great ideas of the past 50 years of programming and get paid to do it. If you're interested, please watch the invitation video.