finalfantasia

> The bigger issue though is wasting time wrapping Java libraries and most comments I see about Clojure interop talk as if there is no cost to it.

You are not forced to "waste time" wrapping Java libraries. As a matter of fact, thanks to the interop features that are well thought out, using Java libraries directly via the interop is encouraged and preferred to wrappers (Java Time API is a good example.) You may _choose_ to write wrappers for Java libraries if they make consuming these libraries in your code a bit nicer.

> Clojure has good foundations but the ecosystem never really developed.

There's no separate ecosystem for Clojure(Script). The established ecosystems such as JVM, .NET, and JavaScript _are_ the Clojure ecosystem. The creator of Clojure(Script) realized that it would be practically impossible to build an ecosystem from scratch without significant investment (Sun spent billions of marketing dollars alone in Java) and thus deliberately chose to make Clojure(Script) a language hosted on well-developed platforms such as JVM, .NET, and JavaScript. Also because of this focus on being a hosted language, he went to great lengths to ensure the interop with its hosting platforms is as seamless as possible. If you need an example for awkward interop with Java, try Scala.

I think what @iLemming meant is that she/he doesn’t understand the appeal of having a fancy REPL _UI_ (mostly virtual terminal emulator-based readline implementations) and working with it _directly_ as opposed to sending forms from your editor of choice to a REPL server.

I kind of hold the same opinion. Being more powerful, feature-rich, flexible than readline implementations, editors are, by design, more suited to editing forms. And, I believe, “sending forms from your editor to the REPL” is what the “REPL-driven development” encourages.