The interop is good, but it’s not perfect. It’s especially bad when reflection is involved (see what happens when you deserialize data class Data(val SomeKey:String) with jackson.)
Other problems revolve around functions named to and in and is being unusable in some situations.
Not to mention that one gremlin dsl class named __!
Kotlin is nice, but IMO the interop is less nice than Clojure’s interop or even the F#/C# interop
If Rumi were a programmer. I'm really good at self-proclaimed manifestos. Too reckless to be an entrepreneur. Open-source fanatic. Bare-metal hardware, virtual machine, and all-computing wisdom.
I missed the point of how the interop could be better in Clojure. For one, you can't write serious Clojure for Android, which is a major use case for Java nowadays. What I really disliked when using Clojure interop is that I ended up writing "clunky" Clojure just to fit into Java's way of doing things. Just having to use an object-oriented call from a Lisp syntax feels really messy.
IMO Kotlin has the best interop story so far for everyday use cases.
True, but I almost never had to just "cast and hope" with clojure calling java code. When it comes to "serious" java (read: "enterprise class" with as much derision as possible) reflection tends to become involved and Kotlin's type system is quite a bit more conservative.
If Rumi were a programmer. I'm really good at self-proclaimed manifestos. Too reckless to be an entrepreneur. Open-source fanatic. Bare-metal hardware, virtual machine, and all-computing wisdom.
That was spot on. I love functional programming and Clojure got me for a while until I had to do exactly that.
In my wildest dreams I see Lisp becomes a mainstream language people use to teach and learn programming. I'm still writing Scheme on the side sometimes.
If Rumi were a programmer. I'm really good at self-proclaimed manifestos. Too reckless to be an entrepreneur. Open-source fanatic. Bare-metal hardware, virtual machine, and all-computing wisdom.
The interop is good, but it’s not perfect. It’s especially bad when reflection is involved (see what happens when you deserialize
data class Data(val SomeKey:String)with jackson.)Other problems revolve around functions named
toandinandisbeing unusable in some situations.Not to mention that one gremlin dsl class named
__!Kotlin is nice, but IMO the interop is less nice than Clojure’s interop or even the F#/C# interop
I missed the point of how the interop could be better in Clojure. For one, you can't write serious Clojure for Android, which is a major use case for Java nowadays. What I really disliked when using Clojure interop is that I ended up writing "clunky" Clojure just to fit into Java's way of doing things. Just having to use an object-oriented call from a Lisp syntax feels really messy.
IMO Kotlin has the best interop story so far for everyday use cases.
True, but I almost never had to just "cast and hope" with clojure calling java code. When it comes to "serious" java (read: "enterprise class" with as much derision as possible) reflection tends to become involved and Kotlin's type system is quite a bit more conservative.
I agree about the awkwardness of
I tended to hide those away under the rug.
That was spot on. I love functional programming and Clojure got me for a while until I had to do exactly that.
In my wildest dreams I see Lisp becomes a mainstream language people use to teach and learn programming. I'm still writing Scheme on the side sometimes.
Tangentially, looking at my
let, I saw a familiar construct staring back at me:LOL. Actually Kotlin stole quite a lot from Scala, which is a functional language inspired by Lisp. So your observation wasn't wrong.