4 ms·

“Shorter code: Kotlin’s modern design makes its code shorter.” How much shorter? How large would the code be in pure Java?

belmont_sup 4y ago
What’s pure Java?
david_allison 4y ago
Expect a 10-30% reduction with J2K, maybe another 5% once manual refactorings are made.
strulovich 4y ago
We actually made this number public in the post. It just appears laters around the conclusions sections. > On average, we’ve seen a reduction of 11 percent in the number of lines of code from this migration.
- melling 4y ago
  I was hoping for more but 11% is still significant. So that’s an extra million lines of code that didn’t need to be debugged.
  - krzyk 4y ago
    I wonder how much of this could be reduced if they used records in Java.
  - kaba0 4y ago
    An extra million lines of {, @NotNull, .stream(), .toList(). Hardly any code that would actually have bugs.
    - strulovich 4y ago
      We have a consistent braces style, so the lines that are removed are rarely those. A lot of the saves come from `?.` replacing null check chains. Many more from the shorter constructor and field initialization syntax (you can get a bunch of things in one short statement). A bunch more from usage of standard library lambda taking functions (`first`, `single`, etc.). Some more just comes from shorter lines due to less explicit types. These are all more some guesses due to conversions I've seen, and not the result of accurate analysis. We also use very little Java streams. A combination of Java 8 arriving late to Android code, and the preference to avoid extra allocations and inefficiencies streams can cause for shorter lists.
- jillesvangurp 4y ago
  There's also the line length to consider. I've seen the same on my own converted Java code. Less lines of code. But you also get lots of a really short lines. And some formatting actually spreads things out over multiple lines for readability. E.g. I use intellij's build in "put arguments on separate lines" a lot. Especially with named arguments, this is just nicer to look at. It's the same or less code but more lines. But less dense code. A more interesting metric might be simply the byte size of the source files. I would expect that to be slightly better than 11percent. Maybe closer to 20-25%.
dr_faustus 4y ago
They should switch to Perl and replace 80% of the code with punctuation
usrusr 4y ago
A nice, simple kotlin left-to-right access deep into a nullable nested object tree can quickly be four lines of java for each and every ´?.something´, for as many of them as fit into your preferred line width. In java, this often leads to either skipping more null checks than you really want to skip, or calling getters more often than necessary. Kotlin might seem a little weak to someone returning from a scala deep dive, but where it really shines is in creating a large overlay between the convenient path and the pedantic path. It removes many "in the small" tradeoffs that you just take as a given in java. It's the "better java" that groovy was not.
- ackfoobar 4y ago
  > Kotlin might seem a little weak to someone returning from a scala deep dive I dismissed Kotlin for this very reason years ago. But after seeing bad Scala codebases, Kotlin feels like a breath of fresh air.
- kaba0 4y ago
  If you have more than 2 levels of nested null-checks I would wager you are doing something fishy. You should probably go with mapstruct or similar libs (which are absolutely cool and a must for data conversions).
  - usrusr 4y ago
    On my fishy scale, requiring translation between different data models would by pretty high up. And how would it help anyways? Absence can be a perfectly valid state and alternative representations of absence like scala's Option seem pointlessly ceremonous once you've worked with a syntax that does not completely suck at dealing with null.

belmont_sup 4y ago

What’s pure Java?

david_allison 4y ago

Expect a 10-30% reduction with J2K, maybe another 5% once manual refactorings are made.

strulovich 4y ago

We actually made this number public in the post. It just appears laters around the conclusions sections. > On average, we’ve seen a reduction of 11 percent in the number of lines of code from this migration.

melling 4y ago
I was hoping for more but 11% is still significant. So that’s an extra million lines of code that didn’t need to be debugged.
- krzyk 4y ago
  I wonder how much of this could be reduced if they used records in Java.
- kaba0 4y ago
  An extra million lines of {, @NotNull, .stream(), .toList(). Hardly any code that would actually have bugs.
  - strulovich 4y ago
    We have a consistent braces style, so the lines that are removed are rarely those. A lot of the saves come from `?.` replacing null check chains. Many more from the shorter constructor and field initialization syntax (you can get a bunch of things in one short statement). A bunch more from usage of standard library lambda taking functions (`first`, `single`, etc.). Some more just comes from shorter lines due to less explicit types. These are all more some guesses due to conversions I've seen, and not the result of accurate analysis. We also use very little Java streams. A combination of Java 8 arriving late to Android code, and the preference to avoid extra allocations and inefficiencies streams can cause for shorter lists.
jillesvangurp 4y ago
There's also the line length to consider. I've seen the same on my own converted Java code. Less lines of code. But you also get lots of a really short lines. And some formatting actually spreads things out over multiple lines for readability. E.g. I use intellij's build in "put arguments on separate lines" a lot. Especially with named arguments, this is just nicer to look at. It's the same or less code but more lines. But less dense code. A more interesting metric might be simply the byte size of the source files. I would expect that to be slightly better than 11percent. Maybe closer to 20-25%.

dr_faustus 4y ago

They should switch to Perl and replace 80% of the code with punctuation

usrusr 4y ago

A nice, simple kotlin left-to-right access deep into a nullable nested object tree can quickly be four lines of java for each and every ´?.something´, for as many of them as fit into your preferred line width. In java, this often leads to either skipping more null checks than you really want to skip, or calling getters more often than necessary. Kotlin might seem a little weak to someone returning from a scala deep dive, but where it really shines is in creating a large overlay between the convenient path and the pedantic path. It removes many "in the small" tradeoffs that you just take as a given in java. It's the "better java" that groovy was not.

ackfoobar 4y ago
> Kotlin might seem a little weak to someone returning from a scala deep dive I dismissed Kotlin for this very reason years ago. But after seeing bad Scala codebases, Kotlin feels like a breath of fresh air.
kaba0 4y ago
If you have more than 2 levels of nested null-checks I would wager you are doing something fishy. You should probably go with mapstruct or similar libs (which are absolutely cool and a must for data conversions).
- usrusr 4y ago
  On my fishy scale, requiring translation between different data models would by pretty high up. And how would it help anyways? Absence can be a perfectly valid state and alternative representations of absence like scala's Option seem pointlessly ceremonous once you've worked with a syntax that does not completely suck at dealing with null.