5 ms·

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 ent

• tn1 4y ago
  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.
  • mojuba 4y ago
    It absolutey matters when skimming a well written code. Whether a variable is immutable or not is almost as important as its type.
    • hoseja 4y ago
      Well, it is part of its type.
  • nicoburns 4y ago
    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.
    • vbezhenar 4y ago
      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.
      • nicoburns 4y ago
        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 :)
    • unwind 4y ago
      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.
• sireat 4y ago
  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.
• V-2 4y ago
  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.
  • mojuba 4y ago
    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".
    • V-2 4y ago
      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.
      • V-2 4y ago
        I mean, in well-architected codebases of course. I've been lucky (or picky) enough to mostly work with such though.
  • R0b0t1 4y ago
    Why not val/mut? Or const/mut, const/var.
• jamil7 4y ago
  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.
• thaumasiotes 4y ago
  > 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-recognition 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.
• kaba0 4y ago
  I really like this feature of Scala, but I do understand the reason why Java went with final var instead.