> Refactoring lisp gets harder the more complex the program gets. I have found that to be true in dynamically or duck typed languages. I have found it to be n

> Refactoring lisp gets harder the more complex the program gets. I have found that to be true in dynamically or duck typed languages. I have found it to be not true in strongly typed languages with good tooling. Example: refactoring large java program in, say, Eclipse. > Breaking up programs into more powerful little pieces is never a clean separation I would tend to disagree, to some extent. In Lisp(s), there are lots of small, sometimes obviously correct functions that do powerful operations on abstract data structures. Part of the reason for this is that unlike OOP (and I write Java daily) which has lots of data structures, Lisp has very few. In OOP you model your domain with new classes. In Lisp you model your domain with combinations of a few basic structures. (In Clojure...) List, Set, Array, Map. Maybe you have layers of separation. With one layer being between primitives that manipulate your domain objects, and another layer being the logic that decides how and when to do the manipulations. I want to solve a puzzle. The puzzle board has various states, pieces, and operations that transform a board into a new board state. Then the logic layer is an algorithm or algorithms written using the layer of primitive manipulations. That logic layer may, in fact, use canned algorithms, because the data structures are common primitives. Say, sort, search, A* search, depth first, breadth first, reduce, map fn over a sequence, etc. You can end up with a large program. But it can be a lot easier to reason about than, say, a large Java program. It seems to take more deliberate effort to keep a large java program easy to reason about.