I'm a static typing person, too, but considering how wildly popular dynamic languages are for Web development, it's hard to take blanket criticism like this seriously.

As far as large projects go, my own experience has been that the dirty truth is that, past a certain size, nothing is statically typed, anyway. Either it's decomposed into a bunch of smaller services that communicate using a weakly-typed messaging system, or it's a monolith that resorts to some sort of stringly typed mechanism for communication among the major components. I know the speakers at tech conferences say we're supposed to keep it strongly typed and use a ports and adapters pattern to limit the scope of impact for type changes, but that just doesn't seem to be how it ever happens in practice.

It makes me think that the Clojure folks might really be on to something, and that, for large business applications, static typing is trying to solve the wrong problem. I'd personally love to get a chance to take its specs system for a spin.

This is true BUT data is easy to refactor and Clojure is really about Data. Clojure's big picture is a principled mental framework for reasoning about data, and as such gives us the core vocabulary and utilities we need to write programs that operate on data in a principled way (immutable data structures, immutable database etc).

So Clojure IMO is today in this awkward spot of saying "Here, use these new principles of data to go solve problems in this new better way!" but nobody has really deeply figured out what that even means. The whole middle ecosystem layer has yet to be written.

But it's happening, there's a movement of believers coordinated by Rich's talks and working to this common goal. And when it works, the whole 100k+ loc system that can't be changed will be but a memory.

(I am Hyperfiddle co-founder, Hyperfiddle poses the question: is it possible to express sophisticated database applications out of just data? We think we've made enough progress to show that the answer is probably yes. Hyperfiddle apps are not stored in git but rather in Datomic. And for special cases where you do need custom code, you can just drop down a layer seamlessly into Clojure.)

Recently Clojure error messages have vastly improved: http://insideclojure.org/2018/12/17/errors.

As well, Clojure has an opt-in solution to type issues: https://clojure.org/about/spec

In fact spec is also the reason of those better error messages!

In my experience the new spec system (a sort of gradual typing) greatly helps in both refactoring and both surfacing and explaining errors, if you havent worked with clojure 1.10 I’d recommend to give it another go.

Also spec is still in alpha so it will keep getting better.

There are also nice linters now like clj-kondo that integrate with Emacs.

https://github.com/borkdude/clj-kondo

Honest question (as I've been out of the Clojure world for a little bit): which refactoring tools integrate with or use spec?

Look at https://github.com/clojure-emacs/clj-refactor.el

Thank you!

I disagree — I am refactoring a large project (60k LOC, that's a lot in the Clojure world!) continuously and find that a type system would just get in the way. On the other hand, clojure.spec together with :pre/:post conditions works great and helps me a lot by checking things that no type system would verify (such as validity constraints on entire data structures).

Error messages stopped being a problem with Clojure 1.10.

Clojure has a type system... but I know what you mean. Perhaps you could expense a copy of Martin Fowler's new 2nd edition of Refactoring? It uses JavaScript, so applying the lessons to Clojure will be even easier. Refactoring in dynamic languages just isn't an obstacle for some of us, I don't know why, but that book is the only thing I can think of that might help someone having trouble bridge the gap.

Clojure has spec now, you can define and "force" your types there.

Error messages have improved since v1.10. Regarding type, Clojure offers spec.