Welcome! Please see the About page for a little more info on how this works.

+1 vote
in Clojure by
edited by

Earlier this week I conversed with a person who had decided to stop using Clojure, I have summarized their points. Before we grab our pitchforks to go after any party here, I am more curious about what we can do to mitigate these tradeoffs if you agree with them. What have you tried? What's your experience? What's your advice?

I feel it's important to state my goal is not to be critical of anyone's work here. I LOVE Clojure and I find this person's insight motivates me to learn about Clojure's trade-offs and explore how to address them using the plethora of tools already at our disposal.

Below is a summary of that person's issues followed by my own thoughts.

REPL driven development

  • Felt like a work-around to the slow startup problem
  • REPL dev was not productive. Often encountered broken REPL states requiring a restart.


  • No static types.
  • How do you know what keys and values are within a map?


  • Too verbose. It seems to contradict the conciseness that Clojure typically embraces.
  • A lot of legwork required to get value from spec requiring you to write many predicates, s/ forms, checkers, etc...

My thoughts:

  • Startup time of CLJS or CLJ hasn't felt like much of a barrier to me in development but GRAAL could be a good solution.
  • I haven't encountered as much broken REPL state with Clojure but it definitely happens frequently with CLJS and Shadow. Is this something we can mitigate using libraries like Integrant or Component? What often leads to an inconsistent state?
  • As for static typing, I can see why it's a goto solution for knowing what a map contains but aside from spec how can we address it in our code?
  • Since speaking to this person I have observed there are many times where I'm executing in the REPL just to find out what data I have.
  • Should we be adding more docs to our functions to specify which keys we need? Could we make better use of destructuring to help emphasize expected keys? Are there better tooling mechanisms to help with this?
  • I don't have any issues with spec myself but I'm not the most experienced with it.
  • What I like is that you are constructing a DSL to specify the relationships in your domain logic which seems advantageous to me over static typing which brings all problems down to a comp-sci academic level.
  • Do I really need to know if this lead I'm trying to send to a vendor in my marketplace is a Record Type?

What are your thoughts?

1 Answer

0 votes

Two quick thoughts:

1) REPL driven development is less of 'a work-around to the slow startup problem' and more of 'a better way to develop software, interactively'.

After developing even a passing sophistication with a REPL, going back to a system without one (even a system with a good console), feels like donning concrete boots.

2) 'How do you know what keys and values are within a map?' - by inspecting it in the REPL. (!) I jest.

In fact, an important point to bring up here is testing. Automated testing, especially at the boundaries between separate parts of the program, mitigates some downside of not having static types. If tests prove one piece of the program will succeed if given the correct input shape (and error nicely if not), then callers of that piece can confidently pass any shape they want.

Hope that helps.