this post was submitted on 29 Jun 2024
901 points (94.9% liked)

Programmer Humor

32490 readers
513 users here now

Post funny things about programming here! (Or just rant about your favourite programming language.)

Rules:

founded 5 years ago
MODERATORS
 
you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 7 points 4 months ago (2 children)

I don’t know what the hate is unless you are trying to store time as a String property. There a special place in hell for all developers who do this.

IMHO, all you really need to know is an Epoch time stamp and whether it’s localized to the viewer or the creator… Not that complex. The problem with time zones is that politicians keep changing them

Honestly, I’d rather give the creator of NULL a slap.

[–] [email protected] 4 points 4 months ago (1 children)

I’m probably going to get a lot of hate for this, and I do recognize there have been problems with it all over the place (my code too), but I like null. I don’t like how it fucks everything up. But from a data standpoint, how else are you going to treat uninitialized data, or data with no value? Some people might initialize an empty string, but to me that’s a valid value in some cases. Same for using -1 or zero for numbers. There are cases where those values are valid. It’s like using 1 for true, and zero for false.

Whomever came up with the null coalescing operator (??) and optional chaining (?->) are making strides with handling null more elegantly.

I’m more curious why JavaScript has both null and undefined, and of course NaN. Now THAT is fucked up. Make it make sense.

[–] [email protected] 3 points 4 months ago (1 children)

To offer a differing opinion, why is null helpful at all?

If you have data that may be empty, it's better to explicitly represent that possibility with an Optional<T> generic type. This makes the API more clear, and if implicit null isn't allowed by the language, prevents someone from passing null where a value is expected.

Or if it's uninitialized, the data can be stored as Partial<T>, where all the fields are Optional<U>. If the type system was nominal, it would ensure that the uninitialized or partially-initialized type can't be accidentally used where T is expected since Partial<T> != T. When the object is finally ready, have a function to convert it from Partial<T> into T.

[–] [email protected] 5 points 4 months ago (2 children)

Ignoring the fact that a lot of languages, and database systems, do not support generics (but do already support null), you’ve just introduced a more complex type of null value; you’re simply slapping some lipstick on it. 😊

[–] [email protected] 4 points 4 months ago

Type-safe lipstick :)

[–] [email protected] 1 points 4 months ago* (last edited 4 months ago)

In a discussion about whether null should exist at all, and what might be better, saying that Optional values aren't available in languages with type systems that haven't moved on since the 1960s isn't a strong point in my view.

The key point is that if your type system genuinely knows reliably whether something has a value or not, then your compiler can prevent every single runtime null exception from occurring by making sure it's handled at some stage and tracking it for you until it is.

The problem with null is that it is pervasive - any value can be null, and you can check for it and handle it, but other parts of your code can't tell whether that value can or can't be null. Tracking potential nulls is in the memory of the programmer instead of deduced by the compiler, and checking for nulls everywhere is tedious and slow, so no one does that. Hence null bugs are everywhere.

Tony Hoare, an otherwise brilliant computer scientist, called it his billion dollar mistake a decade or two ago.

[–] [email protected] 2 points 4 months ago (1 children)

What’s wrong with NULL? How else can you differentiate between not having a value and having a blank value?

[–] [email protected] 1 points 4 months ago* (last edited 4 months ago)

The problem isn't having empty values, it's not tracking that in the type system, so the programmer and the compiler don't have any information about whether a value can be null or not and the programmer has to figure it out by hand. In a complex program that's essentially completely impossible. The innocently created bomb that causes your program to crash can be in absolutely any value.

There are ways to track it all by disallowing null and using optional values instead, but some folks would rather stick with type systems that haven't moved on since the 1960s.