3 ms·

I like Kotlin too, but in which way is it "much more expressive" in your opinion? What can you express in Kotlin that you can't express in Java? Scalas type sys

I like Kotlin too, but in which way is it "much more expressive" in your opinion? What can you express in Kotlin that you can't express in Java? Scalas type system is much more expressive than the one in Java as an example. Only thing that comes to mind in Kotlin is non-nullable references. Most of the stuff in Kotlin looks more like less boiler plate (data classes) than "more expressive".

pabl0rg 9y ago
It's not immediately obvious, but when you write some Kotlin you'll see. Little things that are a apin in Java and elsewhere are quick and natural in Kotlin: - nullable types are smoother than Options - null checks are relatively painless - the stdlib works with you, not against - named parameters and optional parameters means no need for builders - etc. Etc.
- _Codemonkeyism 9y ago
  I have written some Kotlin, and perhaps it's me, but I don't see. "nullable types are smoother than Options - null checks are relatively painless" Might be the case, but Options are more expressive in that I can combine them and restrict them with other type classes to express larger constraints. Reusabilty is higher e.g. with Monad transformers like OptionT. So nullable types are less code, but also less expressive as building blocks of larger constructs. They might be also less expressive because they conflate two concepts: Not initialized and not-there, whereas Option expresses not-there and _ (in Scala) expresses not-initialized. "named parameters and optional parameters" Not sure how this more expressive?
oweiler 9y ago
There are quite a few things in Kotlin which are not possible in Java * Top level declarations * Sealed classes * Coroutines (in Java this is currenty only possible with Bytecode manipulation) * Inlined Functions and Reified Generics * Covariant Collections * Tail Recursion
- _Codemonkeyism 9y ago
  I do not argue that Kotlin is a nicer and a language with more features that are useful. What of these would you call "more expressive"? I'd agree with sealed classes, they express a limited set of possible classes. Perhaps tail recursion as I can express problems in way of recursion without stack overflows. I don't think coroutines are more expressive than Futures/get, only a runtime optimization for many concurrent executions.
  - joshuamorton 9y ago
    Async/await coroutines (C#, python, ECMAscript 7) are much nicer than futures, at least ime. I think that in terms of expressiveness of async code it goes callbacks -> futures/promises -> coroutines Because callbacks are a completely different style of code, your async looks totally different. Futures and promises are better, but still make it difficult to ever break out of the async context, coroutines make the difference between async and normal code nonexistant, and allow clean escape from an async context.
- rbobrowicz 9y ago
  >Tail Recursion Interesting. I thought the lack of proper tail recursion is a JVM limitation. Hence why Clojure uses loop/recur to handle it by translating it to a loop rather then as an actual tail call. Which means things like mutually recursive functions are not possible in Clojure without blowing the stack. How does Kotlin handle that? Is it internally rewriting to a loop or trampoline, or did they find some way to actually make proper tail calls?
  - calcifer 9y ago
    > Is it internally rewriting to a loop Yes. You add a `tailrec` modifier to your function. The compiler then checks if the last op in the function is a call to itself. If it is, it gets replaced with a loop. If not, you get a warning that `tailrec` is ignored.
- calcifer 9y ago
  > Reified Generics It's implemented with some bytecode hackery and hence limited to inlined functions [0], which makes it significantly less useful. Funny how a misguided design decision from the Java 1.5 days (running generic 1.6 code with a 1.5 jre) still haunts us today... [0] https://kotlinlang.org/docs/reference/inline-functions.html#reified-type-parameters https://kotlinlang.org/docs/reference/inline-functions.html#...

pabl0rg 9y ago

It's not immediately obvious, but when you write some Kotlin you'll see. Little things that are a apin in Java and elsewhere are quick and natural in Kotlin: - nullable types are smoother than Options - null checks are relatively painless - the stdlib works with you, not against - named parameters and optional parameters means no need for builders - etc. Etc.

_Codemonkeyism 9y ago
I have written some Kotlin, and perhaps it's me, but I don't see. "nullable types are smoother than Options - null checks are relatively painless" Might be the case, but Options are more expressive in that I can combine them and restrict them with other type classes to express larger constraints. Reusabilty is higher e.g. with Monad transformers like OptionT. So nullable types are less code, but also less expressive as building blocks of larger constructs. They might be also less expressive because they conflate two concepts: Not initialized and not-there, whereas Option expresses not-there and _ (in Scala) expresses not-initialized. "named parameters and optional parameters" Not sure how this more expressive?

oweiler 9y ago

There are quite a few things in Kotlin which are not possible in Java * Top level declarations * Sealed classes * Coroutines (in Java this is currenty only possible with Bytecode manipulation) * Inlined Functions and Reified Generics * Covariant Collections * Tail Recursion

_Codemonkeyism 9y ago
I do not argue that Kotlin is a nicer and a language with more features that are useful. What of these would you call "more expressive"? I'd agree with sealed classes, they express a limited set of possible classes. Perhaps tail recursion as I can express problems in way of recursion without stack overflows. I don't think coroutines are more expressive than Futures/get, only a runtime optimization for many concurrent executions.
- joshuamorton 9y ago
  Async/await coroutines (C#, python, ECMAscript 7) are much nicer than futures, at least ime. I think that in terms of expressiveness of async code it goes callbacks -> futures/promises -> coroutines Because callbacks are a completely different style of code, your async looks totally different. Futures and promises are better, but still make it difficult to ever break out of the async context, coroutines make the difference between async and normal code nonexistant, and allow clean escape from an async context.
rbobrowicz 9y ago
>Tail Recursion Interesting. I thought the lack of proper tail recursion is a JVM limitation. Hence why Clojure uses loop/recur to handle it by translating it to a loop rather then as an actual tail call. Which means things like mutually recursive functions are not possible in Clojure without blowing the stack. How does Kotlin handle that? Is it internally rewriting to a loop or trampoline, or did they find some way to actually make proper tail calls?
- calcifer 9y ago
  > Is it internally rewriting to a loop Yes. You add a `tailrec` modifier to your function. The compiler then checks if the last op in the function is a call to itself. If it is, it gets replaced with a loop. If not, you get a warning that `tailrec` is ignored.
calcifer 9y ago
> Reified Generics It's implemented with some bytecode hackery and hence limited to inlined functions [0], which makes it significantly less useful. Funny how a misguided design decision from the Java 1.5 days (running generic 1.6 code with a 1.5 jre) still haunts us today... [0] https://kotlinlang.org/docs/reference/inline-functions.html#reified-type-parameters https://kotlinlang.org/docs/reference/inline-functions.html#...