I think they add clarity. I think there needs to be a word to indicate that a variable is being created rather than referenced or else it will be ambiguous as to whether you are creating something or referencing something in a broader namespace, which makes code less comprehensible. Succinctly specifying if it can be reassigned adds clarity as to what you can do with the name. For longer functions, I again feel that you would lose clarity as to whether something was previously defined or not if there were no val/var keyword. I don’t think it should be optional either – language design should encourage developers to write readable code.
I think not using any keyword might be error-prone. For example, you intend to set a property, but you made a typo, so you created local variable instead and property is unaffected. Or the opposite: you intend to create a local variable, but you forgot there is a property with exactly the same name, so you accidentally change its value. Imagine how annoying these cases would be to debug, if you look at the line of code and you believe it does an entirely different thing than it really does.
It is also consistent with the way Kotlin does other definitions, e.g.
Like Java, it uses “class” keyword to announce class definition.
Unlike Java, it uses “fun” keyword to announce function definition.
So, Kotlin is very consistent in announcing definitions with keywords in a concise way.
I am not sure whether reducing the length of the source code is actually a goal by itself. For me, it looks like in many cases where Kotlin code is shorter than Java code, the actual goal was readability and removing boilerplate helped in these cases. And I think that e.g. adding the “fun” keyword to functions was again to improve readability - in that case by increasing source code length.
With having a keyword at any definition, it is immediately clear what it is and the additional four characters val are concise enough that it does not distract from the rest of the source code.
Fair enough, though does seem like a good IDE color scheme could clear up any of those local ambiguities.
I just say this coming from python where the lack of val and var (at least in the namespace of the function) never seemed to hurt (granted though it does use “self.” to disambigue property references from local, which is another redundancy).
I’ve been bitten more than once in Python by a typo or a mistake, where I’ve ended reassigning an existing variable instead of creating a new one. And it is very annoying to find that kind of mistake…
I really like Kotlin val/var keywords and how they’re use. I find they add strong compilation safety, with very minimal boiler-plate. I think that Kotlin language tends to be explicit before being concise.
Note: default val exists in Kotlin, in the specific context of function arguments.