Hacker News Reader

Comment by mcav | Hacker News Reader

When I've needed to work with Java libraries from Clojure, I've continually felt that Clojure provides enough abstractions over Java's syntax/conventions to make it not an issue.

Java libraries are so numerous and prevalent that I'm growing to prefer that kind of availability. Coming from Python, I'm not uncomfortable at all with Clojure's java library use.

It really doesn't feel like I'm interfacing with Java. It feels like I'm interfacing with a library designed with OOP. (No more verbose or unwieldy than necessary, given an object-oriented library.)

View on HN

The problem is that many Java libraries feel over-designed compared to similar libraries for other languages. Java is the only place where you will find a class like FrogNibbleAdapterFactoryFactory :)

yep, and you might have to look in 3+ different files just to figure what's the actual class being returned at runtime. so fun to maintain!

True enough. In those cases, standard operating procedure is to hope that someone already wrote a nice Clojure wrapper for the library you want to use. Or, you read the javadocs once, then write the Clojure wrapper, and release it for other people to use.

whereas in Python:

  import frog
  frog.nibble()

Several of them are over-designed. But the biggest issue, IMHO, is that the lack of closures (which is planned to come in the next version) made a proliferation of classes that would have been removed. Just pass a closure instead. Lock api's from the concurrency package are full of examples of this.

I don't know if this works on clojure, but Jruby and Groovy solved this partially, by making closures convert into such interfaces automatically. This however, does not solve the problem of the multiplication of classes.

Reply on news.ycombinator.com