I don't "believe" things, I pragmatically choose the tools that work, the ideas that have merits. I did not say "refactoring is equivalent to structural editing", and I specifically talked about comparing Python REPL to Lisp's.

I don't lack experience working with type systems, I have used over a dozen different PLs, some of them were weirdly unusual - I once even had to program in a language with all operators in Russian.

> when you're working on large enough system

I have built and supported sufficiently large systems in various languages, and have seen firsthand the trade-offs Lisp systems can bring. The holistic experience of using Clojure often can beat systems with advanced static types, but you probably won't ever notice it, because you'd first demand something to "believe" in.

You guys (replying to the comment) seem to be convinced of my one-sided bias for defending s-expression syntax and dying for it. I'm defending it only because it gets bad rap from people unfamiliar with the merits. REPL-driven workflow, live image, structural editing, homoiconicity, code-as-data - none of these require the surface syntax to be parens and Rhombus is the living proof. Structural editing operates on any AST. The actual jewel is homoiconicity, and sadly it gets largely ignored by the majority of programmers today. S-expressions probably are the simplest form of syntax to operate homoiconic entities - the simplest notation that is at once a fully explicit tree and directly the language's own data structure. "I love homoiconicity" does not uniquely entail "I love parentheses", alas, programmers off the bat hate parentheses, often without even attempting to understand their significance - they think it's "aesthetic choice". They don't even for a second look around and get curious for why people keep making new Lisp dialects, 70 years on.