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.
<medium>Let's make a stop near the Forest of Tooling today.<medium> Clojure development basically requires:
dependency and build tool(s)
<medium>Instead of using frameworks, Clojure offers a number of powerful libraries that could be put together<medium>. 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 <medium>fast and quite easy tool development<medium>. 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.
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:
<medium>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?<medium>
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 <medium>a matter of curating a set of tools or making a good set for people.<medium>
There are probably things that could be done around that in terms of templates to produce simple, and I emphasize, <medium>SIMPLE<medium> 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 "<medium>Use Clojure CLI, Use Deps, Use Clojure Spec. Use simple mainstream libraries<medium>". 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. <medium>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.<medium> 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:
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.
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.
<medium>The language is still young and brave and it's going through specific development milestones<medium>. 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
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.