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?

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.

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.

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:

1. Maintainability. Will it be possible to keep maintaining all these many tools, where most of them are maintained by very few developers, in a community that is relatively small?
2. Compatibility. Are the different tools somewhat compatible with each other? This might be important for sharing work across individuals and teams, and for learning resources. For example, if one creates a certain data visualization report in one tool, it may be desirable for others to use that visualization in their own tools, and possibly develop it further with other tools.
3. Composability. With the multitude of different tools for different needs and uses, can users still have everything they need? Can different tools be combined in harmony in a useful way?
4. Welcoming beginners. One aspect where the Clojure ecosystem could arguably improve is beginner-friendly resources. To allow newcomers a comfortable entry to the ecosystem, it is important to create experiences that feel familiar and unsurprising. Can this need be in harmony with the spirit of multiple, individualized tools?

The Clojure community seems to develop its ways of coping with these challenges:

(a) Common infrastructure. Tool authors collaborate to create layers they can use across projects. Orchard and REPL-Tooling are some of the famous examples. Another example: for data visualization, both Chlorine and Notespace have adopted parts of the Pink-Gorilla project.

(b) Standardization. There is a tendency to create and adopt standard protocols and data formats, that are used across tools. Quite a few tools use the nREPL protocol for interaction, which is made to be extended for various needs. Data visualization tools such as Pink-Gorilla, Chlorine, and Notespace are adopting common visualization formats so that users can create content on one tool, and then share it for use on another.

(c) Separation of concerns and composition. The Clojure community tends to create tools and libraries that can focus on one task while composing with others for other tasks. Some famous examples are linters such as Clj-Kondo and static analysis tools such as Clojure-lsp, which can be used from several Clojure IDEs. For another example, some data visualization/inspection tools such as Oz, Literate, Pink-Gorilla, Notespace, REBL, Reveal, and Portal, can be used in an editor-agnostic way. This means that users can use their favorite code editor or IDE while enjoying the visualization tool alongside it. Clerk, a new upcoming tool that was just announced yesterday, advocates this approach too. For some of those tools, the composition is done using the above-mentioned nREPL. This hopefully makes the flow of interaction familiar and unsurprising.

(d) Beginner options. That is still a challenge. Hopefully, the fact that most Clojure tools combine well with most IDEs can matter a lot for newcomers, as it allows them to pick a familiar and easy IDE, and still enjoy additional tools without breaking their habits too quickly. Some IDEs, like Calva, put a lot of effort into creating a beginner-friendly environment. So the situation is hopeful.

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.

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 :-)) !

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.