I've worked on numerous Clojure projects, both personal and professional. I started most my learning on Lisp, so I'm probably not the most qualified to discuss

I've worked on numerous Clojure projects, both personal and professional. I started most my learning on Lisp, so I'm probably not the most qualified to discuss this outside of the thought that many people come to Lisp and Clojure with approaches that aren't entirely compatible with Lisp. I know my thoughts are going to be controversial, so take it for what it's worth. During refactoring, do you feel more flexible, or less? I can see both sides to the argument. On one hand, static types are more rigid, and getting something to compile during a refactoring can be a pain. Often for the right reasons, but often it's due to some annoying technicality in the type system. But once you get there, "if it compiles, it runs" is a cliche that is pretty accurate in my experience. On the other hand, with a dynamic type system, you can slowly evolve a code base and see incremental progress during a refactoring, but I can never get over the dreadful feeling of "what did I forget?". Has clojure.spec worked out in terms finding bugs during refactoring/maintenance and general QA? I think there is good and bad to this, but in my experience, using a lot of types seems to be an anti-pattern. Since most web-based projects really only deal with strings, basic numbers, lists and dictionaries, I really don't see the entire benefit, even in strongly-typed languages. I work with typed languages as well and generally feel ambivalent about types. A bad refactor is a bad refactor and bad code is bad code no matter what language you are using. If you can't understand what the code is doing, don't touch it until you can test against it or test against what it's really supposed to be doing. Types don't alter this fact. Do you make use of the Lispy-ness (Homoionicity, macros, code is data, etc ...) or is it generally an anti-pattern to use these language features in daily development? Homoiconicity is the very definition of Lisp, so there is no way to work around that. Macros are generally eschewed in Lisp. It's glaringly obvious when and if you need to use a macro, and honestly, most people can go their entire career without pushing a macro into production. Code is data is pretty hand-wavey in my opinion. All it's really saying is that, if you call a function with a value, you get a value back. There is no mental quantum leap needed for this. Do you wish you had static types? If so, have you tried gradual typing like Typed Clojure? And if you don't miss types, why? I remember someone saying of Typed Clojure "We went to Clojure to get away from types!". And I'm still trying to understand the mindset. I don't think the community has any strong for-or-against opinions on types. In general, it's bad practice to use multiple-type functions. The perspective that's generally embraced is that each function does exactly one thing, which is why you see so many Lisp projects with many short functions, and if you pay attention, the functions aren't doing a lot of acrobatics based on possible types. What the community doesn't like is someone coming along and demanding something that isn't compatible. This is a little more nuanced, but it boils down to: "Add types if you want me to use it" or "Create a RoR system for me to use it." The community would rather you take the time to embrace Lisp and really try to understand what it is attempting to do before pushing your judgment on it. I often have the feeling that I'm not smart enough to use Lisp. If I had 2x the brain power, I would be able to use macros to conjure up some black magic in 100 lines what would take a mortal 5k in a lesser language. But even if I manage such a feat, I couldn't imagine bringing on another developer to that codebase. Anyone can use Lisp. Most of what you do is very simple. The entirety of Clojure is written on a single webpage. https://clojure.org/api/cheatsheet https://clojure.org/api/cheatsheet No one is building up systems with loads of macros and wild abstractions that cause a 5KLOC code base to shrink to 100 lines. This just isn't possible, and anyone that claims it is has no understanding of what a macro actually does.