val list = listOf("Saab", "Volvo")
val map = mapOf("firstName" to "John", "lastName" to "Doe")
The above seems a really strange decision for a "new" language - why would you not just use the most common structure, being JSON?
From Java to Kotlin and Back Again
51–60 of 199 posts
Re: From Java to Kotlin and Back Again
#52Java 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…
To me it seems really weird to have the function take a nullable string in the first place (and not obvious that null + 1 == 0), so the right solution is probably to deal with the null values at some earlier stage – but in the interest of further bikeshedding of the implementation, a simple if-expression is pretty clean:
fun parseAndInc(number: String?) =
if (number != null) number.toInt() + 1 else 0Re: From Java to Kotlin and Back Again
#53My 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…
"didn't bother" "bitching" "no clue" "another gem" "hateful" There's really nothing in the article that warrants any of this.
Ok I have overstepped a bit (edited the post), but I will stick to the "did not bother" and "no clue". Documentation for Kotlin is really nice and it is there together with amazing Kotlin Koans online. Do you think that author who so eagerly complains about Kotlin was so eagerly learning it?
Re: From Java to Kotlin and Back Again
#54TypeScript 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`…
I'm pretty sure I've used to read them "A Foo named bob".. But I've been in TypeScript and golang land for a while now. I can kinda make sense of it because as an interface the types are what matter most, and the signature in something like F# simply be the input/return types..
Re: From Java to Kotlin and Back Again
#55Earlier quoted context omitted.
Yes, Java lambdas are just syntactic sugar over anonymous classes with a single method IIRC. You must define a full Interface to use when defining the function signature. Kotlin functions are essentially objects that can be passed around, stored in variables, etc. You can also have functions that don’t belong to any class, no need to use static methods for that.
Not exactly, lambdas use invokedynamic which has different performance characteristics when compared to anonymous classes. See a talk by Brian Goetz - https://www.youtube.com/watch?v=MLksirK9nnE
Great, thank you for the correction. I only knew of what it looked like from an implementation perspective, had no idea things worked differently at runtime.
Re: From Java to Kotlin and Back Again
#56TypeScript 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".
> Having the type first allows you to easily mentally parse it as "A Foo named bob".
See for me it's more natural to think of it as Eric is a Person, rather than Person named Eric.
Re: From Java to Kotlin and Back Again
#57Earlier quoted context omitted.
"didn't bother" "bitching" "no clue" "another gem" "hateful" There's really nothing in the article that warrants any of this.
Ok I have overstepped a bit (edited the post), but I will stick to the "did not bother" and "no clue". Documentation for Kotlin is really nice and it is there together with amazing Kotlin Koans online. Do you think that author who so eagerly complains about Kotlin was so eagerly learning it?
It's still pretty much invective (seriously, hateful?) and an invitation to a dumb programming language poop-flinging fest.
As to the author of the thing, they just wrote about not liking Kotlin, you're the one who is taking this as some sort of personal affront. How do you know how long they spent learning it? You don't.
Re: From Java to Kotlin and Back Again
#58Is it me, or does the article feel like it is written by someone who didn’t actually bother to learn Kotlin. Instead they learnt the bare minimum syntax and tried to write Java in Kotlin. The author complains a lot about how Kotlin is different from Java. Err.. it is a new language — it is supposed to be different — otherwise why bother? > I have my favorite set of JVM languages. Java in /main and Groovy in /test are…
It is just you. Edit: and some hundred others. (using my karma as stats counter)
Re: From Java to Kotlin and Back Again
#59Man i gotta disagree with almost all points in this article.
Name-Shadowing is confusing? Should be common sense to not have multiple variables with the same name in the same scope.
Optionals are ugly in Java-Interop, so we decided to just use Java instead. Great reasoning.
Re: From Java to Kotlin and Back Again
#60Java 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…
So you can emulate map with language features like that. But what about other combinators? filter, flatMap/andThen, etc? Plus of course combinators have the advantage that once you realize that optionals, lists, futures and so on have a common structure, you only need to learn the interface once.