Live data from Hacker News

Learn Kotlin in Y Minutes

learnxinyminutes.com

161–170 of 239 posts

Re: Learn Kotlin in Y Minutes

#161
post #147
post #79

Earlier quoted context omitted.

Not even a bad thing. It's a pragmatic JVM language. It's 100% interoperable with Java without baggage like Groovy has. It's probably going to look like Java. Scala can look like Java if you write it very imperatively. What's nice about Kotlin is that the language supports idioms that allow you do diverge from "looking like Java" as you write it more.

Hope we never see "looks exactly like Java syntax but behaves differently when you run it" like we see in Apache Groovy, e.g. their == operator acts differently to Java's.

Pretty much every language's `==` operator acts differently and more sanely when compared to Java's.

Groovy had a very different initial design philosophy compared to Kotlin. The Groovy design philosophy was give Java developers a good highly-dynamic scripting language that still felt like Java but also made it more suitable for writing quick and dirty plugins, scripts and other extension bits to Java programs.

Kotlin is more in the "Java is great already, but has a lot of legacy issues, let's take all the stuff learned in the last two decades and make a Java++"

Re: Learn Kotlin in Y Minutes

#162

Earlier quoted context omitted.

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.

Yep. I think the names themselves are quite unambiguous to boot. A variable is something that varies in value, meaning it can be changed. A value is always that same value; 5 is never 6. Pretty straightforward if you ask me.

I'm guessing the parent is just complaining that if you are reading code very fast (particularly if you're browsing repositories on your phone) it is hard to distinguish between "val" and "var."

Re: Learn Kotlin in Y Minutes

#163
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.

I agree with making mutability require more typing, although I'd prefer going without the redundant `let`.

It's not redundant; for example

  let (mut x, y) = (1, 2);
x is mutable, y isn't.

That is, let is the way that you introduce a new binding, always.

Re: Learn Kotlin in Y Minutes

#165
post #132

I like this val z = (1..9).map {it * 3} .filter {it I'd like it more if it said it performed the functions in parallel. If it does this Automagically I'm sold. If it doesn't, is there an easy to use form that does do batch operations like map in parallel?

I guess they're just showing off mapKeys, but couldn't that line be eliminated with:

  .groupBy {if (it % 2 == 0) "even" else "odd"}

Re: Learn Kotlin in Y Minutes

#166

Earlier quoted context omitted.

`val` is never an appropriate name for a variable because it tells you nothing at all about what the variable contains.

never is strong requirement. maybe it doesn't need to tell. Int::add(int val)

I tend to use `num` in those spots.

Re: Learn Kotlin in Y Minutes

#167

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…

my beef is with 'val' being keyword. How many variables did you name val in all your coding? I certainly did.

I alway use (key, value) or (k, v). :p

Re: Learn Kotlin in Y Minutes

#168
post #162

Earlier quoted context omitted.

Yep. I think the names themselves are quite unambiguous to boot. A variable is something that varies in value, meaning it can be changed. A value is always that same value; 5 is never 6. Pretty straightforward if you ask me.

I'm guessing the parent is just complaining that if you are reading code very fast (particularly if you're browsing repositories on your phone) it is hard to distinguish between "val" and "var."

Let alone type them wrong on a tired night.

Re: Learn Kotlin in Y Minutes

#169

Earlier quoted context omitted.

`val` is never an appropriate name for a variable because it tells you nothing at all about what the variable contains.

Except when iterating through a hash, where 'key' and 'val' are my go-to names for stuff

Just use 'value'.

Only you can be sure of shortened words even if it looks obvious. Not good in a team.

I never understood people who shorten words to make the program look cryptic. Maybe it was someone who taught you how to program had it that way or somehow it makes you feel your program looks cooler if it looks more cryptic.

Re: Learn Kotlin in Y Minutes

#170

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…

my beef is with 'val' being keyword. How many variables did you name val in all your coding? I certainly did.

None. However I have used 'value' for iteration when I couldn't think of anything better.
Post reply on HN