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.
From Java to Kotlin and Back Again
31–40 of 199 posts
Re: From Java to Kotlin and Back Again
#32There 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…
Re: From Java to Kotlin and Back Again
#33The 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!
Re: From Java to Kotlin and Back Again
#34My 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…
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
#35TypeScript 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`…
Re: From Java to Kotlin and Back Again
#36TypeScript 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".
Re: From Java to Kotlin and Back Again
#37Java 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…
fun parseAndInc(number: String?) = number?.toInt()?.inc() ?: 0Re: From Java to Kotlin and Back Again
#38Java 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
#39TypeScript 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".
/me hopes he didn't completely butcher the Spanish.
Re: From Java to Kotlin and Back Again
#40Earlier 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…