everytime i try to learn kotlin, i can only think WTF is happening, why should it be happening?

after wasting last 4 hours, i came to this conclusion table regarding kotlin var and val notation.
And now my fucking compiler is saying that i can rather write :

val x:Int

and initialize it later, when i thought val is immutable and must be initialized at the beginning only(like public static final int x =5)

Who the fuck are those people that like this stupid language? why would you say some variable as immutable(meaning which can be changed 0 Times "ONCE" ASSIGNED A VALUE ) and when i can create a program with a variable that never got ASSIGNED A VALUE EVEN ONCE??

Use scala, its kotlin but for people who have over 20 iq

@yellow-dog was about to say something like that

@yellow-dog i didn't get the joke. Is it something related to me being week at kotlin?

No kotlin fucking sucks and scala is good, there is no joke

"why would you say some variable as immutable(meaning which can be changed 0 Times "ONCE" ASSIGNED A VALUE ) and when i can create a program with a variable that never got ASSIGNED A VALUE EVEN ONCE"

First part is true, second part is false. You must initialize values once. Not less, not more. You might have not yet learn about initializer blocks, which, give more control over these. Hope this helps: https://pl.kotl.in/QOKegazE-

Also, I have to look at Scala, because I've heard much about that language so far, like I did now.

Lasoloz is correct, as a reference don't forget that you can do that in java too

final String s;
s = "hello";
...use s...

Is valid code, also

final String s;
if(condition){
s = "hello";
}else{
s = "goodbye";
}
...use s...

Is still valid, but:

final String s;
if(condition){
s = "hello";
}
...use s...
Is not valid because s can stay unassigned, which is wrong. Kotlin didn't change anything in that logic except that val cannot be null, but unassigned != null

@Hazarth You just made me remember, that instance initialization blocks do exist in Java like in Kotlin. (And I had to write an example for this too :D https://onlinegdb.com/H17QE3Zx8)

@Hazarth damn. I have been working with java for 3+ years and that's a thing i have never used nor will I, in future.

For me , if something is final, it already has a value to it. In real life too, we either say

"this is a candy" (meaning it can either be orange or banana flavored or no flavored at all, ie String candy;)

Or we say :
"this is definitely a banana flavor candy" (i.e final String candy = "banana" )

We will never say:
"This is definitely a candy of some flavor that will be determined after you call the company , but company must tell you the flavor else the world will get blasted"

i.e
final string candy;
if(companyTellsFlavor()="banana"){
candy = "banana"}
else {
candy ="orange"} // must provide this fallback 'else' or the code is invalid

@StopWastingTime Even though the example seems a little stretched to me, I agree on the part, that final is something we define once and for all. I think the main reason why you are allowed to do the definition later and not at the time you declare the variable is that you might want to reduce the number of scopes without declaring a mutable variable.

You can abuse the system this way and write incomprehensible code obviously, but you also can improve the readability by not writing a new function if not necessarily needed. For example:

final Type myVar;

if (condition) {

myVar = initMyVarInOneLine();

} else {

myVar = initMyVarInTwoLines();

}

useMyVar(myVar);

If the initializer branches are kept short and clean then you are reducing the number of scopes or functions needed.

Or if you don't like it this way, you can always stick to the ternary operator when possible.

@Lasoloz

Of course the example I provided is stretched and you can have n+1 number of ways to write clean code. Personally I've never really written initializer blocks and they might be used rarely, but I think they can also have legitimate usage.