Why Clojure, by uncle Bob

I really enjoyed reading this article.

I find it to be a really compact an precise way to explain 90% of Clojure to other fellow programmers:



TBH, the article is ok, but I can’t shake my impression of this guy being a snake oil salesman… Soon we might see Uncle Bob’s “one true way to do Clojure” (which will probably resemble nothing of what the community currently does), and he has a lot of reach in other communities…


Uncle Bob has been mentioning Clojure for a while now, good to see him make a bigger push

1 Like

Sure Bob Martin pushes TDD hard, but to be fair it was the closest thing you could get to an anemic version of Clojure’s Repl driven development in java. It allows you
to iterate and get feedback faster, prevent regressions and document code. Nowadays I don’t always write tests first because I have the repl, but I still write tests (mostly generative). If I was still writing java I’d still be doing TDD just for the increase interactivity it brings to development. As with most things context is important, and in the context of java I always found TDD to be a big boon. But that’s just my experience.

He’s been using Clojure for a while and it’s good to see advocates with more reach encouraging its use and pushing back on the massive drive for static typing all the things. Even if sometimes he can come across dogmatic. :sweat_smile:


Agree on TDD. I think it is less needed when you have a REPL like Clojure’s. However, I use it to some extent together with the REPL. A bit like so:

  1. Hack in a comment form until I have an idea what function(s) to write/how to write it.
  2. Write a little of the function.
  3. Write some code in a comment form testing the new version of the function.
  4. Possibly repeat 2 and 3 until it works.
  5. When it works, consider adding some of the testing code in :test of the function meta data.
  6. Run tests for current function. This probably just works, but if not, go to 1 or 2 (depends).
  7. Go to 1 until done.

(I do not use the REPL prompt very much.)

Step 5 and 6 helps me improve my testbed and is why I think about it as TDD. REPL improved TDD, maybe? :smile:


I feel the same about clojure as Uncle Bob does when he describes it as

the easiest, most elegant, least imposing language

I don’t believe, though, that any property of a programming language transfers directly to the code written in this language. Languages are just tools that help us solve problems (by producing code). Producing code is the easiest part of programming but it’s by no means the sole part. A beautiful programming language is neither sufficient nor necessary condition for a beautiful solution.

It seems to me that majority of language advocates focus on how to produce code far too much. TDD is also an approach with a focus on producing code - you have to write code first to be able to write code next - bureaucracy at its finest. I prefer the focus to be on how to write elegant / maintainable / quality code, like Rafal Dittwald does in this excellent talk and on what to do when not producing code, better known as hammock time.

Programming is hard, producing code is easy.


Liked your comment. It reflects my experience, coming from Haskell.

Clojure is unceremonious. For HTML, just use data. To represent your program, just use data.

It doesn’t attempt to be telling you how you should do programming, that’s up to you, to do a good job. And that means it doesn’t get in the way. The language is at a lower level of control than the application itself.

1 Like

Comments on Hackers News also worth reading https://news.ycombinator.com/item?id=20773158

1 Like

It’s a masterpiece of its genre. Uncle Bob distilled it to 1 point using only the words people already know!

Is it the right 1 point? Yes, if you take a long view, Uncle Bob’s 1 point hits the mark pretty well. Because, in the long view, economy of expression embraces your entire system. It is a measure of the “Simplicity” Dividend: the “safe copies” you don’t code, the bean-to-bean transfers you don’t code, the unnecessary data-wrapping APIs you don’t code, the “thread safety” you don’t code, the serialization you don’t code, the data-filling static initializers you don’t code, the Spring you don’t code, the “unavoidably” repetitive stuff you don’t code, and so on: it adds up, and it contributes mightily to Clojure’s “economy of expression”.

As for Clojure’s more abstruse powers: Uncle Bob was audacious to reckon them as mere enablers of the 1 Big Point. But Uncle Bob knows his audience.


This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.