I wouldn't say it's a broken idea. It's just an idea that doesn't scale. Working in a dynamic codebase - especially a Lisp one - basically means you have to be familiar with how everything you're using works. You can't rely on interfaces; you have to fully hold everything in your mental model. When this is feasible - usually meaning that you or a small cohesive team wrote all of it yourselves - the tradeoff is a huge amount of expressiveness. The barriers between the program in your mind and the program in the code get very small, and you can just make things, concisely, unhindered. This is all well and good, but expressiveness tends to be at odds with constraints, safety, and team communication. Lisp is just one extreme of that spectrum.
Personally I feel better having some of those constraints even on throwaway solo projects, though that might not be perfectly rational.
I will also say that Clojure's heavy focus on immutable data helps somewhat with this problem. You can at least count on functions not having side-effects. Usually. Hopefully.
>I wouldn't say it's a broken idea. It's just an idea that doesn't scale. Working in a dynamic codebase - especially a Lisp one - basically means you have to be familiar with how everything you're using works.
That's FUD. Just make your code modular. Lisp gives you tools: namespaces, and systems.
>You can at least count on functions not having side-effects.
The great majority of functions in Lisp don't mutate data.
Personally I feel better having some of those constraints even on throwaway solo projects, though that might not be perfectly rational.
I will also say that Clojure's heavy focus on immutable data helps somewhat with this problem. You can at least count on functions not having side-effects. Usually. Hopefully.