Hacker News Reader

Comment by mojuba | Hacker News Reader

Tangent: I find the choice of keywords val vs. var in Kotlin a bit unfortunate. The way we read text (or rather skim) is a lot of the times by the shapes of entire words. Val and var are a bit too similar in this regard and I think let vs. var in other languages is much nicer.

View on HN

If I'm not mistaken, that's how Swift (which is syntactically most similar to Kotlin as far as I can tell) has it.

But "let" is already a thing in Kotlin (a scope function in the standard library).

In my experience, in practice "var" are an order of magnitude more rare than "val", so I'd be perfectly fine with "val" vs. "mutable". I wouldn't mind the verbosity - it would gently discourage the use of mutability, while making it very apparent wherever it's actually involved.

Yes, it's "let" in Swift and in some (semi)functional programming languages too.

> in practice "var" are an order of magnitude more rare than "val"

Or rather, it should be that way. Agreed, and I think because the world has been moving more and more towards functional style over the past decades, I'd predict that the next big language that will make it to the mainstream will likely take the approach "immutability by default".

On Android - my platform - 99% of var usage is just for the sake of dependency injection, which is an inevitable concession because basic building blocks of an app (like Activities, Fragments) are instantiated by the SDK, not your code, so neither your code nor the libraries it relies on have control over it and thus the DI has to happen "on the fly", by mutating fields as soon as it becomes possible. It leaves a bit of a bad taste still, but it's very much a fixed convention and therefore kind of... compartmentalized, I guess. And harmless, because I don't expect Dagger 2 to suddenly misbehave and forget to set a field.

I mean, in well-architected codebases of course. I've been lucky (or picky) enough to mostly work with such though.

Why not val/mut? Or const/mut, const/var.

const is already a keyword - it denotes compile-time constants (basically primitive types). val is constant in runtime, but it can still be computed on the fly; just assigned only once.

mut is a nice proposition, I'd certainly consider it if I were to design Kotlin

Interesting. Why not simply overload the meaning of const based on rvalue?

Like in C++, right? The compiler can decide whether it's a compile-time or run-time constant.

Kotlin's "const" corresponds directly to Java's "const", so my guess is that they don't want to burn bridges with Java where there's no substantial benefit.

On the other hand, when skimming some code, does it matter on the first pass whether a given variable is mutable? Probably not if we're just trying to get an idea of how it works; later on a closer read we can look closer if it matters.

It absolutey matters when skimming a well written code. Whether a variable is immutable or not is almost as important as its type.

Well, it is part of its type.

I find this super-important. If a variable if mutable then I need to look closely through the whole of the rest of the scope to see if/where it is mutated. If it's not then I can often mostly forget about it. Thus marking variables as immutable where possible dramatically reduces the mental overhead of reading a function.

What I've found helpful is to configure IDE to use a separate formatting for mutable variables. You don't even need `var`/`val` for that, just smart enough IDE. Something like single underline for those variables. This way they're obvious and you'll know it when reading the code.

I mostly use JavaScript (which uses `const` and `let`) and Rust (which uses `let` and `let mut`), so I've find them quite easy to tell apart just based on the syntax :)

This is the reasoning behind the "const all the things" in C and similar languages, which doesn't have distinct keywords but where you can use "const" to make things immutable.

If a variable is const-declared, I react in exactly the same way and know that I don't have to look for further uses, which I find very valuable.

I even do stuff like this, which might be extreme but I find it coherent and nice:

    void * allocate_and_fill(size_t size, unsigned char x)
    {
      void * const p = malloc(size);
      if (p != NULL)
        memset(p, x, size);
      return p;
    }

The above const-declares the local pointer p, so that it can never be intentionally clobbered inside the function, which would leak the memory. Since it's the pointer itself that is constant, not the data being pointed at, there is no problem in modifying that memory, and the return value is not const-declared in any way.

Pretty sure val/var in Kotlin comes from Scala.

Syntax wise the languages are quite similar (before we get to type systems).

At first I really hated how similar the keywords were (something like let/const seemed preferable).

After a few years of Scala you get used to it.

In fact val somehow feels "nice" and var feels "dirty" so you avoid it as much as possible.

I also find I make the `fun` and `func` mistake often when switching back and forth from Swift. Seems like a weird choice on Kotlin's part.

> The way we read text (or rather skim) is a lot of the times by the shapes of entire words.

This is a long-debunked myth. See e.g. https://docs.microsoft.com/en-us/typography/develop/word-rec...

Though note that val and var are more similar in terms of their letter content than they are in terms of their word shape.

I really like this feature of Scala, but I do understand the reason why Java went with final var instead.

Reply on news.ycombinator.com