4 ms·
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 mak
by mcav 16y ago
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.)
- frognibble 16y agoThe 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 :)
- mkramlich 16y agoyep, 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!
- gcv 16y agoTrue 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.
- mkramlich 16y agowhereas in Python: import frog frog.nibble()
- DanielRibeiro 16y agoSeveral 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.