Multitude of Clojure Tools: Huge Advantage or Big Problem?
January 17, 2025
October 25, 2024
Freshcode
We've already talked about why developers choose Clojure and call it the most "elegant and enjoyable" language.
Also, we've gathered insights about the possible reasons for the unpopularity of Clojure. A sparse and undeveloped development toolset was listed among others.
So, how to improve the existing Clojure tool stack? What is happening right now in the community? When will we be satisfied by a fully-loaded Clojure machine and how its technical inspection will be handled? Let's think together!
In this post, we'll talk about the current state of the broad Clojure tooling ecosystem, contrast the approaches and tendencies we see today, including their strengths and weaknesses.
Clojure tooling landscape: tendencies and issues
Daniel Higginbotham, the author of "Clojure for the Brave and True", called learning a Clojure a journey through the Four Labyrinths:
Let's make a stop near the Forest of Tooling today. Clojure development basically requires:
- IDE
- REPL
- dependency and build tool(s)
Instead of using frameworks, Clojure offers a number of powerful libraries that could be put together. It's a really handy approach, comparing, for example, with the JS development universe, where you typically have to learn a number of different tools and learn how they have to be used properly together.
Such a concept provides fast and quite easy tool development. It's such clay in the developer's hands to model everything he(she) wants. Some tools have become common "household names" amongst the devs, others are riding the bench, the third ones were proved unsuitable.
It's easy to become overwhelmed by the sheer number of incomplete tools that can be included in a single project only. That is not the best factor for Clojure's 'ergonomic' and it spoils people's interaction with its ecosystem.
The main issue we are considering is a tendency of such a heuristic strategy for reaching immediate short-term goals, that is not guaranteed to be optimal and rational.
What are the risks of such an uncontrolled progression? And how to prevent Clojure tooling entropy?
Council of elders. Pandora's box or smart tool kit?
Our goal is to become an enjoyable tipster for Clojure newcomers and provide interesting content for all Clojure-lovers. We want to discuss together how Clojure is used in real-world cases, what challenges we've faced and how can we deal with them.
Today we talk about the dilemma of Clojure tooling and the balance between well-established "canonical" Clojure tools and "one-off" things.
How to solve tooling problems like a boss Clojurist? We've asked Sean Corfield and Daniel Slutsky:
What do they think of tooling in Clojure: is it an advantage — allowing developers to quickly create tools according to the business needs — or would it make more sense to improve existing tools rather than create a new one?
Clojure titans have generously shared their deep thoughts on the subject.
Sean Corfield, veteran software architect, about the importance of using standard staff
I think we have all the tooling now that is needed and it's more about helping people select those tools. The pain points, for people who are just coming to Clojure, are around not knowing how to use the toolset that works with a CLI. There are also guides needed of what set of tools to use with it. I think this is the right place for encouraging people these days.
So on the tooling side, it's not a matter of producing new tooling, it's more a matter of curating a set of tools or making a good set for people.
There are probably things that could be done around that in terms of templates to produce simple, and I emphasize, SIMPLE projects that have all the necessary tools built into them. So maybe creating templates is a good area to look at.
I often ask: "We have a perfectly good solution here why have you now been creating a competing one?". And the answer is "Yes, it does something but it's not reaching what our team would have done if they would building it".
My position is I like to encourage people to use the standard simple tooling where possible. So I am the advocate of Clojure Spec instead of Schema and others. The main reason for that this is something that is designed by the Cognitect team and fits with the language.
I definitely try to encourage people by saying "Use Clojure CLI, Use Deps, Use Clojure Spec. Use simple mainstream libraries". That's why I still recommend Compojure. It is so much easier to teach people to use it.
If you are producing guided learning then try to stick as much as possible with Cognitect standard staff and with core standard libraries even if some of the others have been very well documented and are objectively better in some way. Because it is a good concept that people need. It's why for example I told people to avoid Mount and guided them to Component. I think that Component has better architecture and it is a simpler library to use.
Daniel Slutsky, co-organizer of Scicloj, about the main challenges and solutions
I'll comment from my own perspective, being involved in the Scicloj community, that is building Clojure tools and libraries for data science.
Clojure follows the Lisp tradition of dynamic, playful exploration, and makes it easy to invent new ways of expression. One result of this spirit is indeed a multitude of tools: several excellent IDEs, alongside tools for tasks such as building, testing & deploying projects, data visualization, literate programming, etc. Tools can be customized, and individuals are encouraged to create their own intimate way of interaction with code and data.
All that can be extremely fruitful, but also presents problems, as you hinted:
The Clojure community seems to develop its ways of coping with these challenges:
To conclude, I think the multitude of Clojure tools allows Clojurians to enjoy lots of useful combinations that can be tailored to their own need of playful exploration and creation. The community seems to be coping wisely with the challenges that come with this multitude, but there is still some way to go before the toolset becomes easy, simple, and friendly for newcomers.
Freshcode team about clojure took area
Pros: Clojure enables quite simple and fast tool development.
Cons: many developers ignore the stage of searching already existing relevant tools and skip right to reinventing the wheel.
The problem of Clojure tooling development lies in inefficiency. I am talking about the number of not justified things that were created, just one-time tools for a particular case. This leads to the accumulation of duplicates and valueless tools.
But that's a question for the devs and community, not for the language per se. And, yes, it's cluttering up the tool list, but anyway it's not a problem to find ones you are looking f
at Freshcode
New tooling is developed rapidly, also new approaches to existing problems appear. For example, npm integration in ShadowCLJS is much more convenient than cljsjs wrappers, but then many applications still use Figwheel, and the development of new cljsjs libs is stagnating.
On the other hand, development of clj, cljs and some of the core libraries has slowed down. Lack of the core.spec progress has lead to several competing spec libraries (eg Schema, malli).
As for me, I enjoy Cursive's syntax highlight and refactoring abilities but it just can't keep up with all new libraries and approaches (for example, hugsql syntax).
IMO development of Clojure tooling would definitely benefit from coordinated community actions and a long-term roadmap.
at Freshcode
Clojure allows you to focus fully on the task you want to perform. And I consider it as Clojure's killer feature.
A number of other programming languages require much more integrated and complex knowledge. And, therefore, the development process becomes time-consuming and cumbersome.
For example, working with such enterprise languages as Java, and even JS, you need 1-2 weeks to deal with the project and prepare the environment, wrappers, and some other basic things to start.
Clojure is not one of those. It's a 'thing-in-itself'. Making ideas happen with Clojure is a faster and more autonomic process compared with 'usual' programming languages. The idea turns into MVP here rapidly, as well as MVP turns into a complete product.
2. And what about the growing number of different Clojure tools, both valuable and valueless, as a result of such a fast and easy process? Won't we get such a big attic of unsorted stuff at the output?
To be honest, we've already got it. I've already mentioned why such attics are more compact in some other languages — building new tools is a much more time-consuming and effort-intensive process compared with Clojure, or, for example, with Python and other scripting languages providing the same benefits.
By the way, it's interesting how the Python community deals with such side effects if are. Actually, there are more generally accepted standards in Python compared with Clojure, and the community is much larger and more skilled given the more considerable age of the language.
So, the attic with unsorted stuff already exists and the temptation to make your own tool is still great. Instead of reading somebody's poor documentation you just create your's own tool, with the same (most often) carelessly written documentation, add it to GitHub, thereby keeping the tradition of untidy tools mixture.
Is that good or bad? What we have today is definitely bad. Is it reasonable to make tools from scratch? Most probably there is already some ready-made solution you just need to find. If you've been scouring all possible sources, really went all out, and didn't find what you were looking for — here you can start to project your own tool with a clear conscience. But, please, prepare well-structured and clear documentation if you are going to release your code as open-source.
at Freshcode
How to find clojure tools you need
Clojure Repositories
The answer is simple and well-known: seek and you will find.
P.S.: and don't hesitate to ask Clojure experts to help you. Clojure community is welcoming newcomers, it's such an unspoken rule, or better to say, a free will of its members.
Other links that may come in handy
Here are also some useful links that may come in handy when looking for Clojure tutorials and how-tos.
We hope you'll get inspired enough to start contributing to some tools (smartly combining strengths of conservatism and reformism :-)) !
(UN) final verdict
So, what is the future of Clojure development tools, jokingly called by Bozhidar Batsov "underappreciated workhorses that make our lives hacking with Clojure easier, more fun and more productive"?
Despite a challenging year overall, "2020 was another good year for Clojure and its ecosystem", according to the State of Clojure 2021 Survey. So we are not panicking about the tooling state in Clojure.
The language is still young and brave and it's going through specific development milestones. Anything that proves itself as an inefficient solution, will be discarded.
Building new tools in some cases really helps to create better products, in the other cases, it breeds 'one-off' things fading into oblivion over time.
To create great things let's adhere to the principles of:
- well-organized tooling support
- consistency
- retaining the code clarity ("programs must be written for people to read, and only incidentally for machines to execute")
Please, feel free to write comments below the article if you want to share your point of view.
Freshcode provides Clojure development services matching your business goals. Do you want to know the benefits of Clojure software development or discuss ways how we can develop the Clojure community together? Please, just fill this contact form and one of our representatives will contact you within one business day.
with Freshcode
