Hacker News Reader

Comment by coldpizza | Hacker News Reader

> 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?

View on HN

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 :)

I second this. Not to mention that you end up using val most of the time in practice, so there really is no confusion.

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.

Thankfully that would be a simple compile-time error. The message might even be readable.

If you type var and mean val - would there be any error?

(I'm sure that this is just something you need to get used to, I'm merely trying to point out that this could be a silent typo/mistake)

In actuality it will be extremely obvious in the IDE and the developer would not make this error.

if "val" is a constant, and you try to mutate it later, the compiler will tell you, "That ain't gonna happen."

In many cases, you would get warnings when accessing a var that you don't get when accessing a val. Also, IntelliJ suggests converting to val if a var is never reassigned.

As others said, not a problem if you are using an IDE (and a specific one.)

Considering who authored the language, I am not surprised at all.

It's even worse when your primary keyboard is Dvorak!

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.

Sure, but Kotlin is more about being explicit and less about evangelizing one style of programming over another. It's very pragmatic in that way. There are plenty of scenarios where you're maintaining local state (properly encapsulated within a class, exposing a functional interface, etc) and you need mutable fields. Even plenty of scenarios where you want to operate on a value mutably in a function and then return it. It may seem confusing at first but in practice I've never mixed the two up.

But this most likely is because Scala uses val/var.

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.)

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.

It really depends on the language. 'const' in C works differently from 'const' in other languages (even C++, which has some great 'const' use cases that make guarantees about whether values will change, not just about the symbol binding), they both work differently than 'final'. Similar confusions with 'static'. If all you want to say is "cannot reassign this symbol", then 'val' is great and sidesteps this whole history of readability and meaning confusion.

In Rust, it does (in general) make the value immutable. Most mutations of values in Rust are done through mutably borrowing the value, which you can't do when the value is defined with `let` rather than `let mut`, the exceptions being things like `Mutex`, which gives you a value that can be mutably borrowed when you acquire the lock.

> * If your 'let' doesn't propagate so that immutable collections are used, it's not very valuable.*

That's nonsense.

1. You cannot implement immutable collections without `let` / `final`

2. The Java Memory Model has special visibility guarantees for `final` (which does propagate), making it really, really useful

3. Having the guarantee that a certain reference won't change is still useful even if the object referenced is a mutable ArrayList; e.g. ref = null

1. Sure you can, if you have encapsulation.

2. Java does a lot with the keyword 'final'. I guess here you're talking about the concurrency behaviors of it? Does it bother you that you can remove 'final' via reflection?

3. It's still useful (e.g. not needing to use yoda-style ifs in languages where you can assign inside an if expression Just In Case you forget an =), but not very. That's my whole point.

1. the issue is one of visibility; e.g. you can initiate and pass / share String objects safely between threads without synchronization or worries because underlying String there's a final char[] backing it.

What `final` guarantees is that the variable will be initialized and visible (along with all its referenced objects) before the class constructor is finished. Without this guarantee you'd need `volatile` semantics or locks, which are more problematic.

2. yes, I'm talking about multi-threading; if the user removes "final" via reflection, or modifies final references via reflection, then it gets what he's asking for; but no, it does not bother me because I never do that and I stay away from libraries using reflection anyway.

That's a misnomer, not a misgiving.

val/var/const/whatever only describe the reference, not the value. It doesn't really make sense for that annotation to, say, swivel a collection between ImmutableList and MutableList.

Now, you might be right that it's confusing, this difference between reference mutability and value mutability. I see beginners struggle with it in Javascript's new let vs const all the time.

Even with Object.freeze() it only prevents mutation of the top-level keys.

> If your 'let' doesn't propagate so that immutable collections are used

It does; if you don't use `let mut`, you can't mutate the variable at all, which includes the contents of a collection.

(Given that someone will mention RefCell if I don't, I'll add: "barring unusual trickery".)

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.

Am I being a complete noob that only knows Python (I am) if I ask: Why do you need to declare that something is a mut or string or whatever? Python doesn't seem to need such extra lines with obvious declarations.

Dynamic languages can convert types in runtime (so 1 + "f" = "1f") and not so many languages (not only dynamic) cares about mutability.

Supporting an addition operator that accepts mixed type operands has no relationship to being dynamically typed.

This is weak typing not dynamic typing.

1 + f in modern Python results in a ValueError.

From quick check, it looks like Java can do this coercion, and it's not dynamically typed.

A couple important benefits (there are many others, as well as drawbacks) are

1) the compiler can then warn you when you violate your own declarations before the code is ever run. e.g. it can tell you that you've mutated something you said you didn't want to, or that you've taken the sum of an int and a list.

2) the compiler can guarantee certain things at compile time and thus eliminate the overhead of checking them at runtime. since a value in Python can be anything, before performing a string operation on a string the python runtime must first check that it is a string, while the runtime of a language like rust can assume that it is because that was guaranteed at compile time.

As others have mentioned, the idea is to have the compiler enforce certain things for you to reduce the chances of making an error. One illustrative way I've seen it explained is that if you accidentally make a variable immutable when you want it to be mutable, you get a very straightforward compiler error message saying something like "you can't mutate this variable since it's const; maybe you should make it mutable?". On the other hand, if you want a variable to be immutable but it's actually mutable and you change it, you can end up with all sorts of tricky bugs like race conditions which are much harder to debug.

Not OP, but why do you need the 'let' at all? Why not x = 7 mut y = 3 ?

Because it's a bit too error-prone:

   mut listOfLeftHandedOralHygienistsInKazakhstan = getThem()
   // several lines later
   listOfLeftHandedOralHygienistsInKazahkstan = getThemAgain()

You thought you were reassigning the mutable variable, but you actually created a different immutable variable.

This can be prevented by having different operators for assignment and re-assignment. Some languages do that: in OCaml / F#, re-assignments use '<-' while declarations use 'let (mutable) x =' (they can't drop the 'let' because they use '=' as the Boolean equality operator).

... and whoops, the next thing you know your left handed oral hygienist has apocryphally crashed into Venus.

https://en.wikipedia.org/wiki/Mariner_1

My sibling is correct, but also, there are grammar issues with doing it that way. They're not insurmountable, but much, much simpler with the let.

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 concerning this point. I don't think it matters near as much as the discussion surrounding it thinks.

Oh, and finally, "const" has a specific meaning: compile time constants.

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

That does help a lot.

I'm happy to be dependent on my IDE.

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

`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.

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.

Agreed - at that point, I don't know why you wouldn't just (consistently) use 'k' and 'v'. 'val' adds some weird cognitive load, to me.

I dunno, I am horizontally challenged. I like condensed code style like minimizing words, 2 spaces for indent, etc.

'value' is frequently a keyword or property on objects, and has specific meaning in a lot of contexts. For names, IMO 'k' and 'v' also work, but I find an abundance of single-letter variables hard to read. key and val it is.

`val` isn't the variable name, it's the declaration. I'd imagine `val multiplier = 2' to make perfect sense. `var` likewise doesn't connote any truly valuable information other than the label for the memory location that follows is mutable.

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

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

I find this syntax very clear, usually start with val and try to stick to it. Moving to var is one char-change only. Also val stands for "value" which is a well known term for immutable data. I think about const as static values, while val are instance values.

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.

And I was soooo close :)

I mean the combination of val (immutable) and var (mutable) as keywords to declare bindings. OCaml uses let and so does Haskell, right?

It's obviously very strongly influenced by Scala, to the point of adopting a number of its syntax decisions that are considered questionable (procedure syntax, infix notation, "=" function definitions).

I will echo what the others have said; it's not what I would choose, but in practice it's never been a problem when I'm writing Scala.

Why are Scala's "=" function definitions questionable? It makes absolute sense since a function should return a value.

They might be referring to the update methods:

  val array = new Array[String](10)
  array.update(7, "hello")
  array(7) = "hello" // simply calls out to update

I still fail to see what makes this questionable. It's just syntactic sugar that you don't even need to use, and which is pretty clear when you see it in the wild.

Oh yeah I don't think it's questionable at all, just guessing what they're talking about.

For the same reason omitting braces in C-style-syntax conditionals and loops is questionable, i.e. misleading indentation.

As a bit of an unreformed code golfer and a fan of ML-style syntax, I actually kinda like it myself; I was just listing a few things that are "considered questionable" (by some people) and present in both languages.

I'm guessing here: With const there's always the disccusion about consts not being constant, e.g. when referencing an array or object (reference itself is constant). With "val" you don't have that confusion?

But why not let? Or any word that doesn't start with "va"?

I've been writing Kotlin for a year and a half and it has yet to be an issue.

Probably because that's what scala does

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.

Const exists too, but for compile-time constant. Var and val are ok due to the general conciseness of the language (they don't get lost in the noise of other ceremonies). Plus, being a language though to benefit from strong tooling, IDE's will generally display the two differently.

Rust has a pattern-matching "let" and then you can prefix names within any pattern with "mut" to make it mutable. So a basic mutable var is "let mut" but it's just a combination of two other features. I think it's a totally neat design.

With an IDE you could apply different highlighting styles to the two to minimize confusion.

I bet you can change the val color to something that contrasts the var color in an IDE.

The IDE underlines mutable variables at both definition and use sites. Values are not underlined. It's a perfectly fine way to visually distinguish them.

var = variable (can vary/change)

val = value (constant)

What can be mistaken?

At a quick glance one might mistake var for val since they're only one letter apart. The definitions do make sense though.

I don't find it to be confusing but you'd get more autocomplete help if let was used for constants.

l => let

v => var

Very good point. Fortunately, it's only one keystroke saved.

It could be two if it inserted the space for you!

One keystroke, not two? I type l<tab> in Xcode then I'm typing in the variable name. You'll have to arrow down if it's the wrong one then hit return.

You can argue that it's really not much extra work but it all adds up. Especially when you try to code on a tablet, which I find myself doing occasionally.

Pet peeve here: "variable" and "mutable" aren't concepts that are useful to conflate. Imagine a function that takes a variable and prints its value to the command line. There's no mutation of the variable going on, so the variable is immutable. And yet it's still a variable because each time that you call this function, the value that gets printed is allowed to vary. This is distinct from a constant, where each time you call the function the value of a constant must be the same.

The look?

value as being immutable is a common idiom

Reply on news.ycombinator.com