Kotlin and Dyslexia

I have mild dyslexia although I am not sure to know how to categorise levels of dyslexia and when statistics says that 20% of the population is dyslexic and some researchers says that one of the fields dyslexic perform well is software development and software architecture also does not tells what level of dyslexia could be too high to invalidate that statement. Saying that, I love programming and I work as a FullStack developer .

Kotlin is becoming my favorite language (plain vanilla JavaScript is still at the top) but I must rant about the fact that it has some design decisions that are really “dyslexia unfriendly”. I only report the one for me obviously unfriendly and maybe some people can add to it.

  1. var and val: this a source of endless struggle. Those are virtually identical and my dyslexic brain stalls. Before even attempting to evaluate that var is close to variable to make the right decision I have often already choose one or the other to be eventually corrected few seconds later or let the IDE warning me about trying to reassign a value to a (mmhh should I now use val or var…) val ! Yes I got it right !.

Not to mention that if I was Japanese this problem would be amplified by the fact that pronunciation of val and var are flattening the differences even more.

2: when & with : same stalling problem . Semantically so clear the difference but the time lag needed for the dyslexic brain to differentiate them interfere with a “smooth” flow which cause often arbitrary choices to be corrected later.

3: lambdas, lambdas with params, object callbacks: This the worst. The visual identifiable block of code is very difficult to frame or when lambda expression are typed in a single line (input parameters separated by an arrow, not return statement… what a nightmare).

I will stop here because it sounds that I am struggling with mot aspect of the language which is not true. I love it but still makes me feel more “insecure” . If some design choices have been made to improve the smooth flow of writing code, it did not pay too much attention at that 20% of the population that seems to have an high affinity with programming but that requires more uniquely identifiable and differentiable units instead of English semantically correct symbols

2 Likes

IDEA is your friend in this. You can customize highlight to use different colors for words you do not distinguish.

6 Likes

Yes it is, and there are no equivalent products to JetBrains IDEs that can match their usefulness for which I am a enthusiastic subscriber; still the language designers should be concerning themself with broader choices behind proper semantic.
If someone asks me what a var is used for and I could simply answer that is used to store “variable” values.
If he asks me what a val I cannot tell them that is used for “valuable” values but I have to borrow terms like constant, fixed, unchangeable.
Then a better choice would have been to use const or fixed or whatever can transfer the meaning more directly . A linguistic or language expert my argue that constant or fixed are not precise terms for whatever reason but JavaScript opted for const and as developer I find the choice much more expressive than val . As for the IDE I would have prefer that allowed me to alias val with fixed or any non reserved words as my local preference and ask me if I want to apply that choice consistently across libraries and imported third parties code than just apply colors .
Even more exiting and revolutionary… If I knew ideograms and Japanese kanji’s (and I knew how to use such keyboard) I could alias var and val with some cool single kanji instead :sunglasses:

When it comes to reading, he can colorize the words. And when it comes to writing, he can define templates.

Does not seem to be a problem that must be solved in the language itself.

No it is not.
In my opinion, Kotlin has perfect readability even without IDE assist. Event some complicated expressions like let chaining could be read if formatted properly. There are some expected complications from overriding index operations, infix functions and operator overloading, but it is not about readability.

This is the point. Not dyslexia. Javascript. Kotlin grows from java. Var is getter + setter compact notation, val is getter only.

Mmmhhh … I didn’t get it. Are you implying that JavaScript is responsible for having developers used to variables names such const or that the issue is coming from Kotlin having constrains tight to Java? . Are you also saying that dyslexia has nothing to do with this described situations of discomfort ?

If he asks me what a val I cannot tell them that is used for “valuable” values but I have to borrow terms like constant, fixed, unchangeable.

In case it’s not already obvious, val is simply short for value, just as var is short for variable. Not perfect antonyms, but close enough in context; and similar to the usage in terms like ‘value type’. (And it makes arguably more sense than Java’s final for fields and variables.)

Personally, I very much like their similarity. After all, they both declare a local name that can be used in the rest of the method; both take a type and/or an initialiser; both will hide a class field or other identifier in an outer scope. Apart from mutability, they do pretty much the same job, so I think it’s helpful for that similarity to be reflected in the keywords. (Form following function, and all that.)

1 Like

I mean your mind sharped to js. You can feel discomfort from dyslexia, but mind is agile and you can do your code, aren’t you? So, when you can’t explain val to others that’s usual discomfort for js devs. Not only dyslexic devs. Kotlin is still “better java” at most. It comfortable for java devs and not for all java devs, because it’s “less code idea”. Less code -> complex code. It’s like binary vs hex number representation. Shorter has more meanings per digit.

Dyslexia is a complicated issue (it is also not a single issue, but a collection of similar issues with different specific limitations and usable workarounds). I can see how var and val are very similar and perhaps hard to handle. Unfortunately, as the language is stable now, there is very little that can be done in this regard. Syntax highlighting can help, and is done also at the use site (a variable looks different from a value when referenced).

When you talk about “variable values” you are however making a semantic mistake, although the use of val does not help this. The distinction between primitives and classes does not help either. Let’s start
from the beginning: primitives.

A primitive value is something like 42. It only has the number, but not an address in memory. If I write the number again 42 is the same value as the first occurrence. To be able to work with values it is however necessary to store them in some place (as local variable, field, in an array or otherwise). The place where you store the value is (generalizing slightly) some place in memory. To use the value stored in memory you need to have a way “know” this location. There are different ways a value ends up at a location, leading to different ways to store a location.

If the location is handled by the compiler this is what is informally called a variable, but could be a (local variable, field (instance or class), constant, or temporary (only visible to the compiler)). Note that on the JVM (like on the X86 architecture) local variables and parameters work the same way. The second way to handle locations is through pointers (or references) where the location is a value itself, and used to indirectly find the memory location of the value. (This reference needs to be stored somewhere using the same, recursive, rules).

Variables are called variables because, if you have a location in memory it is possible to change the value stored at that location (assuming no hardware protection is applied). Unfortunately changing what is stored in a location can make reasoning about that location hard (for humans and compilers) and in case of multithreading makes it very hard to handle timing (and even harder for multicore processors to do this efficiently).

Looking at things from the perspective of variables (memory locations) is not the only way to work with values. The other one comes from math (algebra) where you have no storage locations, but you do have names. Given a function f(x)=x+2 the x in this function is a name for an unknown value. This x only has a value for a specific invocation of f so there are different “copies” of x for f(4), f(5) and f(42). This is obvious if you cannot change the value of x in your formula, but actually this is also true with most variables - two calls of a function that has a y variable that changes inside the function still have different locations (possibly) that have different values stored in them.

Like I said before, it is technically always necessary to have a location in memory to store a value for it to be usable by a processor. This means that even if you are purely thinking of something as a name for a specific value there is an underlying storage location. Conceptually you are however doing something quite different. So in Java a final int x=42 is an immutable variable that stores the value 42, where in Kotlin val x=42 introduces a name x for the value 42. In bytecode both are equal.

Java (inheriting from C) takes an implementation derived approach to how variables work, Kotlin takes a conceptual approach. Unfortunately this then gets muddied up with practicalities such as delegates, getters and “references”.

References are nothing more than fancy pointers. Where a pointer (a variable or value containing the address that stores another value) requires explicit usage of the address, references do this implicitly (a reference is a name for whatever is contained in the memory for which the address is held by the reference). In Java/Kotlin it is only possible to specify that the reference itself is not allowed to change (the reference will always point to the same memory). It is not possible to do this for the destination of the reference. Java/Kotlin will always use references for objects. One of the consequences is that if copying is surprising.

If you have the following:

   data class A(var b:Int)

   val x = A(42)
   val y = x

both x and y will hold the address of the same object with member b==42. If you were to run y.b=5 what happens is that field b of the object referred to by y will be changed to hold 5 (instead of 42) . As x and y refer to the same object this means that x.b would now result in the value 5.

@pdvrieze thank you for the details explanation. It is always precious to have a better understanding of the inner working.
Still my objective is to raise more consideration addressing language designers (in this case Kotlin designers) when decision are taken to name identifiers that are typed and read by millions of developers hundreds of time each day. Out-there a discreet percentage might have met a new struggle that was not encounter before. I personally do not struggle with C int, char* float and the const qualifier or the latest ECMAScript const, let and var, Swift let and var.
Also, it is interesting to point out that “The Swift programming language” book, in the basics chapter says…

…Constants and variables must be declared before they’re used. You declare constants with the let keyword and variables with the var keyword…

To be noticed that during the explanation the chosen keyword let requires a more common term as constant

Then isn’t more direct and almost superfluous the following :

…Constants and variables must be declared before they’re used. You declare constants with the const keyword and variables with the var keyword…

An interesting Stackoverflow post is this .
Why is a constant declared with the keyword “let” in Swift ?
And the accepted answer explains immutable variables.

A constant is an expression that is resolved at compilation time…
In swift the closest thing is the immutable variable. The difference may not be evident, but an immutable is not a constant, it’s a variable that can be dynamically initialized once and cannot be modified thereafter…

I guess we are back to the dilemma .
Friendly and distinctive semantics in keyword vs under-the-hood precise keywords that reflect what the compiler does (not too sure that I am phrasing this distinction correctly)

Personally… just because with this beloved language (Kotlin) I have met a new struggle caused by the choice of val/var that hitch my mild dyslexia I would have preferred that this problematics could have taken into account.

And finally… just take it as a joke… let me propose this.

immval and varval aliases to be added to the language evolution :laughing:

Looking at everything said here I don’t think there is a satisfactory solution. Changing val to let or anything else (even though it might help you and many others) is not possible because kotlin is already in a stable version and this would be a major change in the language.
My guess is that there isn’t anyone affected like this in the kotlin dev team and it just never came up during early development when this was decided. I don’t think there is any good reason for val, var except that it’s nice and similar, but as you explained this might be an issue and if it were still for debate I think most people would choose let over val now that you explained this.
I personally hope that the suggested IDE settings will help you enough so that you can still use kotlin.

As to your other points: I personally don’t think with is all too important for kotlin. It’s nice to have but there are other alternatives eg. a.run {} instead of with(a) {}. So maybe you could decide on a coding convention of not using with in your projects.

I don’t really know how to help with your third point as I don’t fully understand the problem. How is it different to other code blocks? I guess a coding convention of no in line lambdas could help here as well, not sure.