While simplicity may matter, I believe Clojure to be a poor example of it -- it's a lot of functions all thrown together in basically one namespace, with poor error handling, and a tendancy to throw a 50 line traceback with a lot of random symbols in it.<p>Clojure macros are the antithesis of simple, and the need to indent a scope for every new variable actually fights against TDD in my experience.<p>I recently wrote a good chunk of a RESTful SQL-backed application in Python in two days that took a team of 3 people in Clojure over 2 months to just get to the basic level of library support one would expect from things like sqlalchemy and flask.<p>Clojure isn't simple -- it's basically a step up from assembler in how little it provides.<p>Simplicity is having all the power tools and being able to put them together and be instantly productive, and to support programming in multiple paradigms.<p>While it's not the norm, I sometimes feel many FP purists spend so much time debating purity and giving basic concepts complex names - when they could be using something else and getting much more done.<p>Side effects aren't the devil and are sometimes neccessary to get real work done. Bad code can be written in anything, and it just takes experience.<p>I'd much rather see a language focus on readability, maintaince, and rapid prototyping than side effects.<p>Functional programming concepts have benefits - I love list comprehensions and functools.partial in python is pretty neat, but when you can also have a decent object system, and embrace imperative when steps are truly imperative, you can get a whole lot more done.