Don't let the title fool you - 90% of the advice given in this book isn't specific to Clojure, and boy is it good advice.
This book contains some of the deepest programming insights I've encountered, to be put on the same level as SICP or the Pragmatic Programmer.
The discussions on naming and abstraction are particularly illuminating, exposing some fundamental tradeoffs like synthetic vs natural names, or principled vs adaptable systems of abstractions. Were these notions more widespread, a lot of the pointless rants and debates we hear in programming circles would disappear.
I would not recommend this book to beginners - this book is most useful when you are experienced enough that your struggle is to make choices, not to get things to work.
Contrarian opinion here: I've instead found the constant philosophizing tiring. But I still commend his effort because as he explained, he's trying to articulate the inarticulate and the visceral. Most programmers would probably benefit from reading a book in the style of Effective C++ (Scott Meyers) or Effective Java (Joshua Bloch), where recommendations are more concrete and more unequivocal. Once you've done that, the matter of software design only really comes with experience—experience designing software and having an almost tactile reaction to the future maintainability and readability of the code; it doesn't really come from reading a book like this.
I can't recommend Effective Java enough. Even if one hates Java with passion. I haven't managed to find a better book on how to design an API in any language. It learned me to think about the consumers of my code all the time (even if I'm the only author on a given project) The chapters on exceptions, defensive coding, generics are brilliant. The whole book is written in an effective manner. Dense with information, short and still readable. The second best: Eloquent Ruby. Brilliantly written and mature. Instead of hyping everything up, the author elaborates the downsides of each described technique and power tool.
As someone who is currently picking up Clojure, that chapter just sold me on the book. I really liked the sign/referent/sense distinction and discussion. I knew it from philosophy/semiotics, but every other place I come across it instantly goes down another rabbit trail. I'm sure the balance you strike will vary language to language, but it really was useful seeing it discussed in terms of naming in software.
I thought I wouldn't live to see the day for Clojure related link to be the top link on HN. I had to reload 5 times.
Clojure's cool, I am glad I got to work with it professionally. I did go back to Javascript, but it made me a better developer. It strikes a nice balance between being a pure functional language and being practical.
It hasn't fallen. The Clojure community has been growing steadily and continues to grow (it's a great community, I'll add). Things have just settled down since, that's why there are fewer announcement.
As an aside, the 2019 SO survey shows Clojure programmers are the best paid [1].
Most Clojure programmers I know (myself included) would not choose to go back to Java.
John deGoes said "Clojure developers ... consciously stay inside the Clojure community because they love the language and ecosystem" and I think that's pretty interesting – Clojure has like this event horizon where if you cross it, you become so attached to it that you never leave. It's like a little black hole that is already self-sustaining – it can only grow, it will never die, and it can happily wait for opportunity.
We think of hockey stick tech adoption curves as smooth exponentials, but that's not actually true. Hockey sticks demonstrate COMPLIMENT EFFECTS, which is where the latent potential for growth is suddenly activated by an external trigger. An example is broadband/youtube, described by VC Chris Dixon here: http://cdixon.org/2009/09/10/non-linearity-of-technology-ado... Another is smartphones and smartphone apps. Ruby/Rails. Scala/bigdata.
Our goal at http://www.hyperfiddle.net is to use the low-code movement to trigger complement effects in Clojure.
For me, I found Clojure after googling around for various of permutations of "CSP in function language" back in 2016 or so. I fooled around with core.async, thought it was pretty neat, but promptly forgot about it.
About a year later, I was doing a project where I felt a dynamic language would be useful, still wanted it to be pure-functional-ish, and tried Clojure, and this time started with the fundamentals, and once I got to macros, I was completely hooked on Lisp for forever.
I thought it was the coolest thing ever that I could add language features without having to understand compiler theory or anything like that.
=====
Nowadays, my work involves around 50% Java (yuck) and 50% Clojure, but a lot of my personal projects are done with Scheme, since I have to admit that I do kind of like the `define-syntax` macro system better than Clojure's.
I definitely see the "event horizon" analogy. Once you see just how much more productive you are with the language than most others, it's hard to leave.
> As an aside, the 2019 SO survey shows Clojure programmers are the best paid [1].
I am freelancing for Clojure projects for already 6 years and have to say it is true you can expect better compensation in general, but this is only given
1) You are an experienced coder overall, e.g. I am 18 years in dev, and Clojure is seen as a logical high level experience conclusion
2) You can find good existing Clojure project, which is damn hard, and the line of Clojure coders for openings is usually pretty long. And many businesses are expecting to find young coders who can be.. not so well paid. The latter is a very bad approach for Clojure projects (Sorry, young guys, I have seen tons of Clojure code by many people, and it only looks good when the coder is at least 30+)
3) You can find good greenfield tech agnostic project, where your sell point is, again, your overall experience first, Clojure second
But at the end, that all keeps you very fit in many dimensions, and I am not going to give up Clojure, instead investing more
It is indirectly; if a company has trouble hiring, they might switch up the stack a bit to try and attract new talent.
For example, my previous employer (Jet.com) used F# partly because one of the most senior engineers liked it, but also partly because they thought it might attract some tech talent out of the shadows.
When was the last time you've tried? I know a great deal of developers (including myself) working exclusively with Clojure and have never struggled finding a new gig.
I think the Clojure job market is pretty good for senior developers but bad for junior developers. Anecdotal evidence, but I saw someone a few months ago who had an active Clojure blog, gave talks on Clojure, contributed to multiple interesting projects on GitHub, but was unable to find a job before literally running out of money and going homeless. That could just be a weird situation, but I almost never see any job listings looking for junior developers, and when I do, they tend to be in Europe/Canada rather than the U.S.
> Anecdotal evidence, but I saw someone a few months ago who had an active Clojure blog, gave talks on Clojure, contributed to multiple interesting projects on GitHub, but was unable to find a job before literally running out of money and going homeless
That's a bit hard to believe.
Surely someone in this situation would settle with taking a job programming in a different language instead of going homeless?
It's also possible they placed unreasonable demands (I notice a lot of people looking for jobs in niche languages often ask to work 100% remotely too).
If you work in a niche language, you need to be ready to compromise in certain areas, such as having to relocate.
I agree, if this person was acting entirely rationally they probably would have switched to learning JS and found a job by now. My only point is that there aren't many opportunities for junior-level Clojure developers who don't stand out as exceptional in some way.
I am not overly familiar with Clojure, but is it possible to be expert at Clojure, and not be able to parlay that into some other JVM language job? It might be a bit depressing, but I would think that one could take a Java job in a pinch if one had one's back against the wall.
I think anyone who's an expert in any general-purpose programming language can find a way to parlay that into a job, since it's much easier for them to learn another language, but knowing Clojure doesn't help much for learning other JVM languages. My guess is an expert C++ programmer could pick up Java faster than a Clojure programmer.
Is it growing? It is a difficult metric to quantify, but looking at thing like Github, or Reddit, it seems flat or declining. Clojure initially benefited as the preferred Java escape path, but it seems like that has been supplanted by Kotlin.
At least the first link has a pretty crazy cutoff though, 2018. Once a lib is mature it can easily go years without updates, doesn't mean development has been abandoned, much less usage.
But trying to compare across languages by package manager traffic or something would obviously be a lot harder.
In any case apparent zero velocity, whatever it's actually tracking, definitely shows that general interest (which constantly seems high) isn't really translating to really wide adoption.
I agree with your first point, and stability of Clojure the language, and libraries is a strength. But it does suggest fewer people are starting new projects with Clojure, which matches how it feels to me, and matches my experience in the Clojure community, where discussions are a little less active.
I really don't understand why people obsesses over popularity so much. The only question worth asking is whether the language has a big enough community to be sustainable, especially when dealing with a hosted language that leverages the underlying ecosystem.
In case of Clojure the answer is unequivocally yes. It's got a large active community around it, and there are many companies of all kinds using it in production. Whether it's growing rapidly or slowly doesn't really affect its effectiveness compared to the other options available.
It has a small active community with many abandoned libraries, no killer app, and painful tooling. I like the language in spite of that, but size of community matters. To your point, as a hosted language you can make up Clojure's deficiencies by using Java libraries, but if you aren't a Java developer (or are a disgruntled Java developer) that isn't a great answer.
The only question worth asking is whether the language has a big enough community to be sustainable
Exactly, and I'd argue Clojure was on a path to yes, but has lost momentum and is leaning toward no.
Wrong. Clojure community is only smaller in comparison to mainstream languages: Java, JS/TS, Python, Ruby, Go. Today it has more conferences than Haskell, F#, OCaml, Elm, Elixir, Erlang. More meetups and more podcasts. Just this year alone there were announcements for Clojure confs in India, Brazil, Canada, Russia and Belgium (and these are just for new ones)
> many abandoned libraries
Wrong. Clojure emphasizes modularity and composability, library that supposed to be doing one thing and well is usually just that. Besides, Clojure is also legendary for stability and backward-compatibility. I don't know any other language where you can pick a project of a few years old, update a few dependencies and still expect it to work. You don't have to re-write things every time TC39 gets browsers to support yet another Javascript feature.
Read this passage from one of the Clojure libs https://github.com/candera/causatum#liveness-advisory to understand why Clojure libs don't get updated very often.
There are hundreds of Emacs packages that people still download and use but they haven't seen any updates for decades. Does that make them "abandoned"?
> no killer app
Wrong. Clojure often offers multiple choices for any domain. Being hosted makes it even broader. Yes, some knowledge of the language you're trying to interop with is required, but you don't have to be an expert to successfully build and maintain things.
If someone doesn't qualify Figwheel, Re-frame, Fulcro, Lacinia, etc. as "killer apps" I don't know, maybe they are just pathologically ever unhappy.
> painful tooling
Wrong. Again. It used to be difficult, because only Emacs used to have nice support for Clojure. Today you can write Clojure in Emacs, IntelliJ, Atom, VSCode, Vim, Eclipse. And tooling is a lot nicer in comparison with other tech stacks.
So no, Clojure has never "lost the momentum". It is still growing, but less rapidly. The ecosystem has reached levels of hedonic adaptation, where people are just happily using it without too much excitement and/or frustration. Clojure has become a "boring" language. It just works. And arguably it is probably the best tool for what it is made for.
In the web domain these are killer apps for me, the kinds of thing you can't find in any? c or ml languages: Datomic cloud, Fulcro, Pathom, Datascript, EQL, hiccup, garden, honeySQL, Spec 2, CodeQ, hyperfiddle
I think it's because Clojure in general focuses on the value of things rather than the identity of things
Maybe conferences isn't a great metric there have been a bunch of cancellations like SYNC and Clojure West. People have already mentioned Incanter in this thread, one of many abandoned and out of date libraries. Lacinia is nice, but a killer app? What language doesn't have a GraphQL library? Have many partially supported editors doesn't make better tooling. Clojure still has potential, but by every other metric, besides conferences (
The recent Clojure/north conference [1] focused specifically on commercial usage of Clojure with plenty of companies presenting why and how they're using Clojure to solve their business needs.
There are tons of new libraries and tools being built with Clojure every year. Some recent examples are Spectre, Crux, Metabase, Braid, Neanderthal, and many others.
Meanwhile, the tooling around Clojure is far better than vast majority of languages out there. Leiningen is a one stop shop for managing dependencies, testing, building, and packaging the application. Uberjars are effectively containers that you can drop on any system that has a JVM on it and run them. Compare this to the nightmarish tooling of Node, Python, or Ruby.
Furthermore, if you're doing web development then you get a single consistent setup with Clojure/Script, and once again benefit from superior tooling where you can reliably hot load code in the browser, something that simply doesn't work in Js, do code pruning down to function level, and minification including libraries.
There's a good reason that you rarely see companies switch from Clojure to other languages once they start using it.
I'm not sure what you are arguing. Clojure is a cool language, with a small community, and declining interest. Why do you think searches trend down if interest isn't trending down.
You can still be adding a few new libraries, and some new users while interest declines. Clojure had the potential to be the default Lisp, the default functional language, and perhaps the default alternative to the c family of languages. Unfortunately, it is heading towards being just another niche language. Tooling is a big problem, not because the once you learn emacs and cider it is insufficient, but because it is a pain to setup and learn emacs and cider. Not because Atom and proto-repl are bad tools, but because to get it set up you need 10 plugins and 20 config setting and it ends up being fragile - complected in a major way. Another part of the problem is that Clojure advocates vastly overvalue the what unique benefits Clojure adds things like hot reloading and the REPL. Clojure and ClojureScript might have better or more pure implementations, but everyone has some form of these features now. It isn't a compelling argument to say switch to Clojure, change programming paradigms, learn Lisp, learn emacs, learn java, so you can get a hot reload that is 15% better than what you have now.
BTW, when I started getting interested in Clojure, one of the videos I learned from was your Philly ETE presentation. So I have a lot of respect for where you are coming from, but I wish the Clojure community was less defensive, and more unified around a strategy to promote and grow the language.
The claim that there's declining interest is absurd, and that's what I'm arguing. Google trends are simply not a measure of anything interesting in practice. It's about as useful as throwing around TIOBE rankings.
>Tooling is a big problem, not because the once you learn emacs and cider it is insufficient, but because it is a pain to setup and learn emacs and cider. Not because Atom and proto-repl are bad tools, but because to get it set up you need 10 plugins and 20 config setting and it ends up being fragile - complected in a major way.
It's quite clear you haven't used Clojure tooling if that's your impression of it. Again, Clojure has some of the best tooling I've used in any language and I've been doing development for around 2 decades now. Intellij and Cursive are a fantastic combination that takes minutes to install. Calva is another great option for VS Code and it's also a one click install. Both these projects are actually being funded. Cursive is a commercial product and Calva is funded via Clojurists Together. Both Cursive and Calva show just how much the community has grown, since people and companies are willing to pay for tooling nowadays. That's a real measure of growth.
>Another part of the problem is that Clojure advocates vastly overvalue the what unique benefits Clojure adds things like hot reloading and the REPL. Clojure and ClojureScript might have better or more pure implementations, but everyone has some form of these features now.
>It isn't a compelling argument to say switch to Clojure, change programming paradigms, learn Lisp, learn emacs, learn java, so you can get a hot reload that is 15% better than what you have now.
Switching to Clojure provides far more benefits than just having hot reloading, and these benefits are very convincing for plenty of companies using Clojure today. These benefits also tend to appeal predominantly to experienced developers: https://insights.stackoverflow.com/survey/2019#work-_-salary...
>It has a small active community with many abandoned libraries, no killer app, and painful tooling. I like the language in spite of that, but size of community matters. To your point, as a hosted language you can make up Clojure's deficiencies by using Java libraries, but if you aren't a Java developer (or are a disgruntled Java developer) that isn't a great answer.
All of this is demonstrably false as has already been discussed in the other reply.
>Exactly, and I'd argue Clojure was on a path to yes, but has lost momentum and is leaning toward no.
I don't know how you can argue that seeing how Clojure is used commercially by plenty of companies large and small nowadays. It's already been viable years ago, and its only been getting better every year. My team has been using it for nearly a decade now, and we can't think of a better option on the market today. Clojure is way past the point where it needs to show long term sustainability.
Yes, it is growing. Today Clojure hosts more conferences than Rust, Swift, Elm, Erlang, F#, Haskell, Elixir, OCaml, ReasonML and soon the number may exceed number of Scala specific conferences. It will probably never become as popular as Javascript/Typescript or Python and Ruby but it is slowly and steadily growing.
I've noticed the reddit is less active, but I think that's just because everything needing saying was said already. At least it is for me, just busy coding.
The Clojure annual survey gets more and more participants every year, so from that angle it seems to be growing.
Oh you're right, I got mixed up with the announcement:
> In the first Clojure survey in 2010, 27% of respondents reported using Clojure for work and 33% for serious hobby projects. This number has steadily grown over the years and we now see 66% using it at work and 54% using it for serious hobby projects.
It's the number of Clojure devs using Clojure for work that has consistently grown. Interesting that this has happened without the community growing in numbers.
No, it's not because of that. The reason I think - F# and Clojure are two main FP languages being used in Finance. Fintech companies are known for paying above average salary. Both F# and Clojure are the most paid languages (according to SO surveys of the last few years)
"Fall" of Clojure? Clojure is still growing and not showing any signs of stopping anytime soon. Conferences popping up all around the world. Almost every European country has its own Clojure conference, some have multiple.
Clojure today has more conferences, meetups, podcasts, jobs and books than any of those "non-mainstream" PLs like OCaml/ReasonML, Haskell, Elm, Elixir, Erlang, Julia, F#, Swift. Soon number of Clojure conferences will exceed number of Scala-related confs.
Clojure community is still innovating. Mind that the steward company has probably less than 100 engineers in total and the community has less active members than the number of engineers working for Google, yet they are constantly doing pretty cool things. They are figuring out interop with Python and R from Clojure, they are constantly improving Clojurescript performance, they're experimenting with type systems, improving Editor/IDE support, doing machine learning stuff, serverless, graphql, smart-contracts, distributed systems, etc. etc.
People don't see it, because they are too busy shoveling shit from one corner of the ecosystem to another in Python, Typescript, Java, Ruby, Golang etc. stacks. But Clojurists are quietly building things and solving real problems.
What are you talking about? The long term Clojure users are probably still using Clojure, based on the activity observed on Github repos. I think Java people who do not like Clojure much more inclined to use Scala and more recently Kotlin.
External factors. Clojure didn't offer a great variety of jobs, especially remote. There was a decent number of jobs for onsite positions, but that's the trade I wasn't willing to make.
The language itself is great. The ecosystem is fine, you can find most libraries and if you can't you can at time use the JAVA versions. This was at times a pain because Java client libraries for certain services were out of date.
Solving real-life business problems was tricky but ultimately fun and satisfying. As the resulting code is usually very elegant and succinct.
I really loved the interactive programming aspect of it. It was really easy to go from a repl experiment to the actual implementation.
This would be great, if I weren't starting a new contract on Monday. :)
I mean this is still great for someone else. I am not surprised you are Berlin-based, I was at EuroClojure in 2017 in Berlin and was pleasantly surprised by how many Clojure companies existed there, most didn't offer remote work though.
Another Pitcher here. We're betting big on Clojure(Script) and are hiring! If you're curious, feel free to reach out (my email address is in my profile).
I'm mystified that not more people are offering remote possibilities when hiring for Clojure. There are some really great people out there, but the likelihood that they live in your neighborhood is low.
Geography seems like an arbitrary constraint to me. Nothing about it increases the probability of getting a better candidate.
I beg to differ - Clojure is like specifically made for distributed teams. I have never had such nice experience in other tech stacks when working remotely. There are many more remote Clojure jobs today than non-remote.
>Clojure didn't offer a great variety of jobs, especially remote
Things have changed. Today there are more Clojure jobs than of
Haskell, OCaml, F#, Elixir, Elm.
Especially remote jobs. There are few channels in Clojurians Slack where people post jobs and resumes and discuss them. There's a new posting almost every day.
This is great! I really enjoy the author’s use of philosophy as a guiding context/point of analogy—I feel like the majority of software engineers aren’t necessarily aware that nearly that many of the principles of software development date back to developments in logic and mathematics in the 19th century (we are doing little more than using formal langauges, after all) (actually the use of the term “indirection” is a great example of this—in the software industry, people have invented terms for things that have had long standing names and terminology around them already in logic and philosophy).
Hope this book also introduces some engineers to analytic philosophy too, a discipline that I feel is crucial for understanding any formal pursuits, and that is given far too little attention (thanks to the hyper-specialization of domains and knowledge).
Definitely! Chapter two deals directly with Clojure idioms, but other than that the content is quite general. Zach has said in multiple interviews that one of his future projects could be something like an "Elements of Software". Fingers crossed!
I really enjoyed this book, especially the chapter on naming.
As a programmer I named dozens of things a day, yet I never really got much advice on what makes a good name other than the standard "make it clear". I wish there were more books out there that went as deep as this book on that topic.
Thank you for the link, I brought the book to add to my collection of Clojure books, Programming Clojure by Alex Miller, Stuart Halloway and Aaron Bedra has been my favourite so far
Would be good to get a Datomic Cloud book but I don't know of any yet
This book contains some of the deepest programming insights I've encountered, to be put on the same level as SICP or the Pragmatic Programmer.
The discussions on naming and abstraction are particularly illuminating, exposing some fundamental tradeoffs like synthetic vs natural names, or principled vs adaptable systems of abstractions. Were these notions more widespread, a lot of the pointless rants and debates we hear in programming circles would disappear.
I would not recommend this book to beginners - this book is most useful when you are experienced enough that your struggle is to make choices, not to get things to work.