Live data from Hacker News

From Java to Kotlin and Back Again

allegro.tech

31–40 of 199 posts

Re: From Java to Kotlin and Back Again

#31
post #2

The crux of this is that they're not doing Android stuff, so they have the luxury of using Java 10.

Roughly half of the complaints are against Kotlin specific features or hazard of mixing Kotlin with Java libraries - I was curious since I only use Java for Android as well and have not shifted to Kotlin.

Right, but because they were able to use Java 10, a good amount of the pain points that Kotlin was intended to address go away. On Android, you're stuck with Java 7 with one or two Java 8 features, so Kotlin helps out a lot more.

Re: From Java to Kotlin and Back Again

#32
post #3

There exist really, really good arguments for the structure of a programming language. Obvious example: I think Perl-as-is-generally-written is line noise. But complaints like "the type comes after the variable name [so that we can consistently define types, including in arguments, without inconsistent syntax like Java is now forced into]"...aren't good. You might not be comfortable with it off the jump; it's more co…

i agree with your point about the way Kotlin does blocks. the '->' syntax within the block still trips me up a lot. maybe one day i'll be used to it and not have to think about it...

Re: From Java to Kotlin and Back Again

#33
post #4
post #2

The crux of this is that they're not doing Android stuff, so they have the luxury of using Java 10.

And that is perfectly fine. Java 10 and then 11 and so on will bring a lot of niceties to developers. I switched my projects to 10. Haven’t had much issue. Now I get to use var!

Agreed. Because they had that option to them, they were able to switch back. If they were stuck with Java 7, they may have decided that the niceties of Kotlin were worth more.

Re: From Java to Kotlin and Back Again

#34

My 5 cents: It seems to me that the author did not spent enough time to learn Kotlin. The way he mixes Java types (Integer.parseInt) inside pure Kotlin code and then complains about lack of Null-Safety? It is enough to use an extension function String.toInt() to stick to Null-Safety and compiler will do the rest. His main() function? Another weird argument because Kotlin's documentation has some examples on how to wr…

There is some value to the criticism where it's easy for Java programmers to do the wrong thing because it's possible when they shift over.

Of course, that's the price you pay for compatibility with Java, but maybe there should be tooling which can give warnings where you are using commonly abused Java tools where you'd be better off using Kotlin-specific ones.

Re: From Java to Kotlin and Back Again

#35
post #29
post #27

TypeScript also has the weird reversed type declaration. I've never understood it; it's so much less natural to read. Having the type first allows you to easily mentally parse it as "A Foo named bob".

See, that's interesting to me, because I have always read declarations aloud as "bob the Foo", even when they're written "Foo bob". Reasonable people can differ, of course. Where it's harder to differ is that is much easier to parse type-after declarations and to make a consistent syntax with them--that's why Rust et al have gone that route. To do type inference in Java (or C#) they've had to add a new keyword, `var`…

That makes sense. It's definitely a subjective thing and I used almost nothing but Java and C++ for my first [counts fingers] 6 years of programming, so I'm probably biased.

Re: From Java to Kotlin and Back Again

#36
post #27

TypeScript also has the weird reversed type declaration. I've never understood it; it's so much less natural to read. Having the type first allows you to easily mentally parse it as "A Foo named bob".

for me the trouble begins when i switch between these syntaxes when going back and forth between Java and Kotlin, which i still have to do all the time

Re: From Java to Kotlin and Back Again

#37
post #28

Java version in the article: public int parseAndInc(String number) { return Optional.ofNullable(number) .map(Integer::parseInt) .map(it -> it + 1) .orElse(0); } And the Kotlin equivalent... "No problem one might say, in Kotlin, for mapping you can use the let function: fun parseAndInc(number: String?): Int { return number.let { Integer.parseInt(it) } .let { it -> it + 1 } ?: 0 } Can you? Yes, but it’s not that simple…

Or the one I posted below:

    fun parseAndInc(number: String?) = number?.toInt()?.inc() ?: 0

Re: From Java to Kotlin and Back Again

#38
post #28

Java version in the article: public int parseAndInc(String number) { return Optional.ofNullable(number) .map(Integer::parseInt) .map(it -> it + 1) .orElse(0); } And the Kotlin equivalent... "No problem one might say, in Kotlin, for mapping you can use the let function: fun parseAndInc(number: String?): Int { return number.let { Integer.parseInt(it) } .let { it -> it + 1 } ?: 0 } Can you? Yes, but it’s not that simple…

Or the one I posted below: fun parseAndInc(number: String?) = number?.toInt()?.inc() ?: 0

Oh yeah, I forgot about inc().

Re: From Java to Kotlin and Back Again

#39
post #27

TypeScript also has the weird reversed type declaration. I've never understood it; it's so much less natural to read. Having the type first allows you to easily mentally parse it as "A Foo named bob".

It feels weird to me, too, but I'd wager you'd get used to it pretty quick, just as you get used to saying "la pelota roja" instead of "the red ball".

/me hopes he didn't completely butcher the Spanish.

Re: From Java to Kotlin and Back Again

#40

Earlier quoted context omitted.

Disclaimer: not super familiar with Kotlin or Java. Safely calling option.map and having the function assume it's not called with null is very useful. Is that a real drawback to Kotlin or is there something missing from this post?

Calling Optional.map(foo -> foo.bar) is effectively equivalent to foo?.bar in Kotlin. What GP was saying is that the author is using things like parseInt and other non-idiomatic things because the author is not familiar enough with the language. Even if it weren't about parseInt vs toInt, the author could have used "number?.let(Integer::parseInt)" instead of "number?.let { Integer.parseInt(it) }" (but of course "numb…

Now that I look at the article, it occurred to me that author might have already been biased when trying Kotlin out and was already certain about the outcome hence the rather poor argumentation. The article itself is rather poorly organized and chaotic as well.
Post reply on HN