I wrote a medium sized project in clojure at my last job and it was a good experience. The team was small (under 5) so the hiring and training wasn't an issue for us. I never had a problem reading clojure code, and the only major headache I can remember, which was our fault, was that clojure keywords (think ruby symbols) used to be turned into interned strings which are stored in permgen and we were running out of permgen space. I believe this has been fixed in recent versions of clojure, but I'm not 100% sure about that.

http://eigenjoy.com/2011/03/02/clojures-keyword-can-fill-up-...

Jdk 7 puts interned Strings into the old generation instead of the permgen. Maybe give that a try.

ruby (MRI ruby, even!) has that same bug.

So does Erlang, but it's not really a bug. Symbols (atoms, whatever) are guaranteed to be a unique identifier, so the fact that they're allocated and exist for the duration of execution isn't really surprising.

It's just something you need to be aware of.

not a bug, a known issue: interned strings aren't GC'd in python, erlang BEAM, many runtimes.

So I'm not a big lisp guy, but from what I understand and what I know of CL, lisp is in a much better place on the expressiveness:simplicity relationship than Scala.

That said, some of these issues (slow collections, talent availability, tools) have nothing to do with language complexity and might affect almost any relatively new programming language if the implementors didn't consciously work to counteract it.

Lisp is in a very different domain, being dynamically/uni-typed, whereas Scala is statically typed. Statically typed languages don't aim only for simplicity/power ratio, but also for various compile-time guarantees.

"That's just conpletely false. I don't know where your assertions are coming from but language design absolutely has a great deal to do with what kind of tools / developers you can expect to find to support the language. I'm all a-huff with the sheer gall and ignorance of your assertion that I'm just not even sure what to do. Bad developer. >:( bad"

Revised: fine ok maybe a bit harsh. My opinion is that language design would be extremely influencial over how people implementing collections/tools/compilers go about doing their work and what the end result of their efforts would look like. In fact they probably are more telling of a design than anything else. That last part was sort of bs guesswork but it sounds right. Happy now?

I started writing a response to this but it got bloggy so I did that instead: http://bit.ly/u1Y6Lc