A low effort meme I made

# random

[Youssef Shoaib [MOD]]

A low effort meme I made

[Sam]

Accurate

[Pablichjenkov]

But null doesn't express anything. What do you express with null? What meaning it has to you?
Numbers have no null value for instance. You don't need to have null in a set of values. Doesn't offer anything.
Most of the time it is an uninitialized reference but not always. People use it to communicate errors, but it loses the error information.
Why not initialize values with whatever value represents empty or non-initialized in your value's domain?

[Pablichjenkov]

I agree with you somehow for performance reasons but null in general makes the software less expressive.

[Youssef Shoaib [MOD]]

Same exact thing for Optional though. Ultimately, Rich Errors will be the way to go moving forward

[Pablichjenkov]

Right, optionals are a big NO

[efemoney]

IMO Null is not a value, it’s the absence of a value so that the combination of null + T gives you something optional, ie its either there or its not there.
Using Optional<T> the model is not any better than just using null ie T? .

[efemoney]

I agree on the point about errors and I think they should not be represented as null BUT I also think there are valid cases where errors can be handled & “_coalesced”_ into an optional type (instead of being propagated)

[gildor]

Expressing everything as an error instead of just "well, result for this input is null" doesn't make software automatically better, you need "no value" sometimes, sometimes you need an exception, trying to wrap them all together so far was not very successful imo

We will see how rich errors in Kotlin will do on practice, but so far it's quite promising

[phldavies]

Optionals can be useful in payloads where you need to distinguish {"myField": null} and {}

[gildor]

They are, but it more like a patch for bad design of json API, also usually it handled better by more domain specific primitive rather than generic Optional

[Pablichjenkov]

null is not needed in a language. I don't recall last time I have declared a variable null-able.
You can always replace null with a specific initial value.

var type: Type? = null
vs
var type: Type = TypeInitialValue

[gildor]

Well, we do strongly disagree here

[Pablichjenkov]

Above pattern improves readability. Think of a when clause.

when {
  nullable > 0 -> computeStuffPos()
  nullable < 0 -> computeStuffNeg()
  0 -> computeZero()
  null -> error()// non intuitive what to do
}

Vs

val InitialValue = 0
when {
  nonnullable > 0 -> computeStuffPos()
  nonnullable < 0 -> computeStuffNeg()
  InitialValue -> computeZero()
}

You see how null introduces entropy in the top when

[gildor]

No one said that you need nullability everywhere, that is the whole point, usually you don't need, but also sometimes you do need, it's not extreme at all

[Pablichjenkov]

In a few scenarios perhaps and like I said before, it may perform better especially memory RAM consumption. But most of the time you don't need a nullable. Just selecting the right initial value express things better.

[gildor]

I'm not talking about ram
Most of the time yes, but having no null in the language is completely different story
Also null is better than 0 or -1 or "" in most of the cases as initial value

[Pablichjenkov]

Also null is better than 0 or -1 or "" in most of the cases as initial value

This one is the key here. Right, when it comes to primitive types yes. But in cases of data classes, model classes and richer types. I would prefer to define my own initial value as a constant or object to express the non initialized state. But for primitives I agree with you

[gildor]

Obviously, if there is already sealed/enum hierarchy, you don't need null and it discouraged, but it not always the case, and add sealed hierarchy on top of existing types just to avoid null doesn't make program better (or at least not in all cases)