Live data from Hacker News

Learn Kotlin in Y Minutes

learnxinyminutes.com

81–90 of 239 posts

Re: Learn Kotlin in Y Minutes

#81

Earlier quoted context omitted.

Kotlin as a language has expectations on IDE capabilities. I doubt the problem of accidentally typing "r" instead of "l" at the end of a keyword is as prevalent as someone typing "var" instead of "const" and not coming back to make it immutable. A quality compiler can warn about an unmutated mutable variable which solves all problems. Remember recently on the Java mailing list there was a lot of bikeshedding concerni…

The problem isn't typing, but reading. Maybe other people's brains work differently than mine, but I'm sure I will be slightly slowed down by this.

When it comes to reading it is very clear in the IDE. val variables look normal (since immutability is encourage), var variables are underlined. You get used to it very quickly

Re: Learn Kotlin in Y Minutes

#82

Earlier quoted context omitted.

I find it a huge improvement over Java, but I wish it would have more syntax sugar for lists/arrays/maps like Swift and dynamic languages do. The mix of "hip" programming language constructs with unchanged Java verbosity feels weird to me. But if I were making an Android app, I'd definitely try to do it with Kotlin first.

What kind of sugar are you looking for? I'd like to have first-class comprehensions in any language I use, but having decent map/filter/reduce|fold implementations is good enough for the most part. (1..100).map({ it + 10 }) Doesn't seem so bad.

Mutable hashmap/associative array/whatever literals like:

    var map = {"a": 6, "b": 12}
[Whatever list type is most common/idiomatic in Kotlin] literals like:

    var list = [1, 2, 3]
etc.

Plus list/map comprehensions like Python or Haskell, as you mentioned.

Not a big deal or anything. It's only a little bit of extra typing. And the syntax sugar they do add is definitely a massive step-up over Java.

I know it'd be hard to add the map literal syntax since it would clash with Java's normal array literal syntax. And I also realize that Java has a wide variety of container types for a reason, and Kotlin wants to be a subset of and not replacement for Java, so doing this may not make a lot of sense.

I guess on reflection, my complaints aren't really valid given that context. I've just had it ingrained in me to use special characters for basic container types, since Python and JavaScript were my first languages for many years.

Re: Learn Kotlin in Y Minutes

#83
post #51

I like kotlin a lot, but suddenly there are a lot of articles in the front page about it. Kotlin isn't more cool because Google announced yesterday it is going to use it in Android. Kotlin is the same good language it was 2 days ago! (rant over) If you want to learn kotlin go to the official docs and tutorial, they are as good as the language: http://kotlinlang.org/docs/reference/ And you don't need to install anythi…

I don't think people are saying it's more cool, but the announcement sure made it more known. I'd never heard of it before the announcement (I don't do anything with the JVM these days, so I'm not up on it).

Re: Learn Kotlin in Y Minutes

#84
post #41

> Declaring values is done using either "var" or "val". "val" declarations cannot be reassigned, whereas "vars" can. I wonder why they decided on these very mistakable names. Why not const/constant/cons/whatever else just as long it's distinguishable from each other?

I'm personally a fan of the Rust way, i.e. `let` for const bindings and `let mut` for mutable ones. I think it's fairly clear which is which, and having to type four extra characters to get mutability helps reinforce the notion of const being the default choice.

If your 'let' doesn't propagate so that immutable collections are used, it's not very valuable. Just like 'final' in Java doesn't prevent anyone from mutating your ArrayList. Using 'val' instead of something more suggestive like final/const/'not mut' seems a lot nicer to me. (Edit: and indeed Kotlin having "mutableListOf" and "listOf" separation is a good step in readability. The val/var before either of those is less important.)

Re: Learn Kotlin in Y Minutes

#85

Earlier quoted context omitted.

What exactly make it a great language? What are the advantages compared to Java? I search for it but couldn't find any simple answer to that question. The fact that things are shorter to declare doesn't make it better. It makes it less readable.

A wide array of quality of life changes to Java. > The fact that things are shorter to declare doesn't make it better. This is debatable. In fact, shorter code could (but not always, of course) mean less room for error and more room to hold higher abstractions. Boilerplate is a less efficient use of cognitive energy.

Agreed, with an exception of magic non-standard out-of-context characters (#$=%>^<) with non-intuitive language-specific meanings; see bash, perl, angular... I prefer short textual keywords 99% of the time

Re: Learn Kotlin in Y Minutes

#86

> Declaring values is done using either "var" or "val". "val" declarations cannot be reassigned, whereas "vars" can. I wonder why they decided on these very mistakable names. Why not const/constant/cons/whatever else just as long it's distinguishable from each other?

In my experience as someone whose been writing scala for a couple of years (which also uses val/var), it has 100% never been confusing or a problem.

scala-mode2 (which isn't close to an IDE) also highlights vars in red so it's extra hard to get mixed up :)

Re: Learn Kotlin in Y Minutes

#87

Does it have an equivalent to Swifts if let clause? if let person = selection?.organization?.owner { setTitle(person.name) setImage(person.image) }

Yes. val person = selection?.organization?.owner?.let { setTitle(it.name) setImage(it.image) it }

ok so I'm guessing you can't operate on more then one scope at once?

    if let person1 = dashboard?.owner, person2 = selection?.organization?.owner {
    	person1.cloneProperties(person2)
    }

Re: Learn Kotlin in Y Minutes

#88

> Declaring values is done using either "var" or "val". "val" declarations cannot be reassigned, whereas "vars" can. I wonder why they decided on these very mistakable names. Why not const/constant/cons/whatever else just as long it's distinguishable from each other?

This is the usual first thought of someone who's never used the language. A few hours after writing some Kotlin code, you don't even think about it.

Re: Learn Kotlin in Y Minutes

#89
post #84
post #41

Earlier quoted context omitted.

I'm personally a fan of the Rust way, i.e. `let` for const bindings and `let mut` for mutable ones. I think it's fairly clear which is which, and having to type four extra characters to get mutability helps reinforce the notion of const being the default choice.

If your 'let' doesn't propagate so that immutable collections are used, it's not very valuable. Just like 'final' in Java doesn't prevent anyone from mutating your ArrayList. Using 'val' instead of something more suggestive like final/const/'not mut' seems a lot nicer to me. (Edit: and indeed Kotlin having "mutableListOf" and "listOf" separation is a good step in readability. The val/var before either of those is les…

I thought that's how the majority of languages worked. It just means the variable cannot be changed to reference a different value. It does not make the value immutable.

Re: Learn Kotlin in Y Minutes

#90

Earlier quoted context omitted.

My guess is it came from Scala? In practice it's not very tough to get it right.

Val might have originally been OCaml or Haskell.

Standard ML, rather.

It might have appeared in earlier MLs as an extension.

Post reply on HN