61–70 of 199 posts
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?
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…
"didn't bother" "bitching" "no clue" "another gem" "hateful" There's really nothing in the article that warrants any of this.
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?
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?
JSON doesn’t support non-String keys, for one thing.
Not only C++; C# also. It's not very hard to confuse the author, is it :) I understand it's different from Java he's used to, but that doesn't mean one can hold every such difference against Kotlin. Not being Java isn't in and of itself a fault of a language.
Why is ":" problematic exactly? It's more concise. It's true that this gives ":" more than one meaning, but it's so clearly context-dependent I can't really see how it could cause confusion when coding. An example would help.
(Ruby uses "<" to denote class inheritance - by some miracle Ruby devs manage to get over the fact that "<" is also an arithmetic operator :) )
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".
Also, if your type is something stupidly long (ex. Java) its really easy to read something like MyAbstractFactoryBeanImplBuilder while you have a bunch of stuff in your head and space out/forget something. Humans aren't good at keeping a bunch of things in their heads, so I'd much rather just have the names of these things and then types be as a reference to return to as a "oh wait, what was this thing again?" sort of deal.
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 think the way they do blocks is odd. I think that the braces should encapsulate the body of the block, not the variable expression as well I can't find an example of what I imagine you're saying. Can you link to an example from here the reference docs? https://kotlinlang.org/docs/reference
// Lambdas are code blocks enclosed in curly braces.
items.fold(0, {
// When a lambda has parameters, they go first, followed by '->'
acc: Int, i: Int ->
print("acc = $acc, i = $i, ")
val result = acc + i
println("result = $result")
// The last expression in a lambda is considered the return value:
result
})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…
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.
The biggest red flag IMHO with Kotlin is the teams disinterest in supporting the language server protocol. They are taking a very insular approach to the ecosystem just like Microsoft used to with .Net. The world has moved on a bit from that mindset, but they are completely happy with coupling the experience to their companies IDE...