Haskell, fundamentally, is actually quite simple: it's just the lambda calculus. You could fit the typing rules on a single piece of paper, and the evaluation r

Haskell, fundamentally, is actually quite simple: it's just the lambda calculus. You could fit the typing rules on a single piece of paper, and the evaluation rules are even more trivial. It is very difficult to come up with a simpler model than the lambda calculus. Sure, it might be difficult to learn, but that's very different from being complex. Haskell is, if anything, different--but this is also why it's so much more expressive! I think this is a great example of Rich Hickey's distinction between simple and easy. Also, learning a language to some level of proficiency is an O(1) cost but the benefit is O(n) to how much you use it, so I really don't think you should consider that much. Avoiding a language because it seems difficult to learn is just shortsighted. Now, Haskell does have some complexity that other languages don't. But this is mostly in the compiler and runtime system: things like the incredible parallelism and concurrency features. There are languages that have much simpler runtimes, but Clojure ain't it: the JVM is probably the most complex existing runtime, full stop. Legacy code, also, is more a matter of being on the JVM than language design. If you have a bunch of legacy code in C, it'll fit better with Haskell than Clojure. Calling out to native programs from the JVM is a real pain. The Haskell FFI, on the other hand, is relatively nice. More generally, I think the idea that every bit of power has a price is not accurate. I agree that language design is going to be a complex optimization problem against several axes. However, this does not mean every improvement along one carries a cost along another--not every language is along the Pareto frontier! Since all languages are imperfect, you can get strict wins. Also, as I understand it, protocols do the easy part I talked about. Certainly useful, but not very interesting. I do not see how you would accomplish return type polymorphism in Clojure--something like the from_string function or polymorphic numeric literals--because the information needed is simply not there. I'm not saying it's impossible, but I've certainly never seen it done.