3 ms·

Which Java idioms do Kotlin programmers frown on? (I am one) The only ones I can think of are where the language provides a feature that automates some Java bo

Which Java idioms do Kotlin programmers frown on? (I am one) The only ones I can think of are where the language provides a feature that automates some Java boilerplate, so it wouldn't make sense to write things out by hand anymore. Otherwise they're semantically identical languages so the gap isn't big.

lmm 7y ago
Things like builders no longer make sense if you have named arguments. Transforming or filtering a collection is more idiomatic than mutating it in-place. Factories don't make sense when first-class functions do the job better. Basically everything that's frowned on in Scala is also frowned on in Kotlin, in my experience.
- thu2111 7y ago
  Good points. It'd be great if the kotlin compiler could produce builders or "withers" automatically.
  - lmm 7y ago
    Would you really want them? If you write code in that style then you're giving up a lot of the advantages of Kotlin. IMO there's a contradiction at the heart of Kotlin's positioning. As the quote goes, a language that doesn't affect the way you think about programming, is not worth knowing. If programming Kotlin is just like programming Java, why not just keep programming Java? If you want to switch to Kotlin because it's going to unlock a better way of programming, then that's going to have to mean changing how you program. It may work as a trick to get users on board at the start, but ultimately the language will have to find its own idioms and patterns, or else go the way of CoffeeScript.
    - thu2111 7y ago
      I'm talking about what it compiles down to. Kotlin routinely generates bytecode that uses Java idioms either for its own ABI or in addition to it. So yeah, if some builder classes were produced behind the scenes for an immutable data class, why not, that'd be cool. You could always disable that feature with a flag if for some reason the bytecode size was an issue.

lmm 7y ago

Things like builders no longer make sense if you have named arguments. Transforming or filtering a collection is more idiomatic than mutating it in-place. Factories don't make sense when first-class functions do the job better. Basically everything that's frowned on in Scala is also frowned on in Kotlin, in my experience.

thu2111 7y ago
Good points. It'd be great if the kotlin compiler could produce builders or "withers" automatically.
- lmm 7y ago
  Would you really want them? If you write code in that style then you're giving up a lot of the advantages of Kotlin. IMO there's a contradiction at the heart of Kotlin's positioning. As the quote goes, a language that doesn't affect the way you think about programming, is not worth knowing. If programming Kotlin is just like programming Java, why not just keep programming Java? If you want to switch to Kotlin because it's going to unlock a better way of programming, then that's going to have to mean changing how you program. It may work as a trick to get users on board at the start, but ultimately the language will have to find its own idioms and patterns, or else go the way of CoffeeScript.
  - thu2111 7y ago
    I'm talking about what it compiles down to. Kotlin routinely generates bytecode that uses Java idioms either for its own ABI or in addition to it. So yeah, if some builder classes were produced behind the scenes for an immutable data class, why not, that'd be cool. You could always disable that feature with a flag if for some reason the bytecode size was an issue.