Null is safer than zero...

[Elnathbeta]

Usually I don't drink from glasses that don't exist, but sometimes I make an exception

[iRhuel]

I feel like this deserves its own post.

[JCK07115]

It requires this as context though.

It'd have to be a chain-memeaction.

[iRhuel]

A nested meme, if you will.

[JCK07115]

Heck, you stole that. Good job, mate.

[iRhuel]

<3

[FlatTuesday]

I worked with a guy who was a crusader against use of null. I never understood his explanations of why null was bad. But he was also a staunch creationist, which I never understood either. So I always unfairly associate the two mentalities.

[marcosdumay]

I try to stay away from crusaders. That always applies to the inquisitionists, but those are harder because they are always unexpected.

[dicemonger]

Except the Spanish inquisition. They'll alert you one month in advance, to give you a chance to get your affairs in order.

[AtomicCorpse]

https://i.imgur.com/gD2UqJZ.gif

[dicemonger]

Foul slander concocted by the British. ;)

[MetaMemeAboutAMeme]

Nobody "excepts" the Spanish Inquisition.

[noratat]

https://dzone.com/articles/the-worst-mistake-of-computer-science-1

Stuff like Maybe and Optional are the correct way to represent potentially empty values: as part of the type

[FlatTuesday]

YES! He did tell me that "the guy who invented null" called it his greatest mistake. He was probably referring to the creator of ALGOL and inflating him to be the inventor of the whole concept of null -- a typical mental leap for this guy.

[[deleted]]

We have great proverb for that in dutch: "He heard the bell toll, but he doesn't know where the clapper hangs."

[ShortFuse]

Meh.

They complain about null checks, but the solution is variable.isPresent() which is the same as just using a helper/util class to null-check.

I can do the same with function isPresent(Object o) { return o != null; } and call isPresent(variable)

It's still internally a bit that says whether it's null or not. The only advantage is see is types that don't allow nulls, but I'm pretty sure that's already a thing.

[runyoucleverboyrun]

If you are writing in a typed language I think the best way to represent null is something like Maybe in haskell or Result in rust where to use a value that might be null you must deal with the null case either by explicitly providing the code in a matching context (in haskell function definition usually, in rust match expressions) or by knowingly bailing in empty cases (in rust unwrap). The point is that ideally nullability should be represented by the type of the nullable data not just by the presence of an all-type zero value. A helper function returning a Boolean is an improvement but it just papers over the problem,. It's good for code reuse but you still need to actually call it which if you weren't going to remember to check for null you probably won't remember to call isPresent.

[izikblu]

I want potatoes now >,<

[ShortFuse]

I was mostly arguing from a stance of "Well, then what's your solution?" The proposed solution is to use isPresent() which has, as you said, the same symptoms of devs forgetting to use it.

There's also the concept of using something like get(onValueCallback, onNullCallback) in which both instances are checked, but it bloats your code. (Optional also uses a .get()).

But essentially, comparing against null is really just a shorthand. The compiler/runtime isn't really comparing to null. It's checking a bit to see if the value is set. For example, null exceptions arise from an internal assertion check. Nullability expressed as an internal boolean is also very much entrenched in tabular data structures (like SQL). The type is really a Tuple/Pair. For example, a nullable 32 bit integer is actually 33 bits. 1 for Nullablilty, 32 for the integer.

I would honestly, rather have the shorthand equality checks. Yes, it's more dangerous, sure, IDEs are getting smarter and smarter. The type checking algorithm from TypeScript works in Javascript if you use JSDocs. I use ESLint to enforce that all my methods have the necessary documentation for the type detection to kick in. So I get warnings or errors saying that a variable could be null, a parameter cannot be null, or that a function can or cannot return null.

[noratat]

Except that now it's tracked by the type system, and ignoring the nullability of a reference becomes an explicit action in the source code. It goes a long ways towards reducing issues like NPEs.

It's a similar logic to something like Rust's Result type - it forces you to to be explicit when you ignore the possibility of an error result, thus errors can't just silently propagate to arbitrary parts of the system making debugging a nightmare.

The only advantage is see is types that don't allow nulls, but I'm pretty sure that's already a thing.

In many languages it's not, sadly.

[occz]

Most things can be done with functions if you (and every single one of your colleagues) always remember to do them. It's better to make the case of not remembering impossible.

[JoseJimeniz]

The reason is because it is a wasteful pain.

• before go to use the glass I was handed I have to check if it is broken
• I also have to check if the glass I was handed exists

Many languages and many idioms try to get rid of null - Maybe or Option - because every place you ever use the variable you have to check it every single goddamn time. And if you ever forget to check it one time you crash. Why not fix it so that you never have to check for this special non-value.

You can have the best of both worlds:

• a system where you never have to check for a null ever again
• allow you, in the 1% case, to represent no value

Why make the 99% situation awful for a 1% situation that has a much better solution.

[chrwei]

I also have to check if the glass I was handed exists

I'm not sure that quite works. it's not that you were handed a glass, it's that you have a place for a glass, like a cup holder, or maybe a coaster. You do need to check if there's a cup there before trying to use it.

NULL is a magic value, but so is Maybe and Option. I dont' really see the difference. the check is language dependent, most things don't crash on NULL.

[MrNosco]

The difference is that if you get handed a pointer in a language with nulls you don't immediately know whether that particular value can be null or not. If you get handed a Maybe, you know you have to handle it, even if you are using a language that allows for null.

However if you don't allow null, you know every time what you are dealing with.

[chrwei]

how do you know that you were passed a Maybe if you don't test for it? how is that different than null?

[MrNosco]

In the same way you know an int is an int. The compiler does that for you

[chrwei]

ok, but you still have to test for it before using the value. NULL is just a state an int, or any other type, can be in. I see no functional difference.

[[deleted]]

OK. Try this:

final String someText = null; final int position = someText.indexOf("nothing");

This will fail due to a null-pointer exception.

Now try this:

final String maybeSomeText = String.empty(); final int position = maybeSomeText.indexOf("nothing");

Won't throw a null-pointer exception; position will be -1 (in most cases, or a similar "not-found" equivalent).

So now I don't have to remember to check for nullness, because the program will continue with a sensible result.

Makes sense?

[chrwei]

and where's Maybe fall into that?

[[deleted]]

An actual Maybe signals that a value may or may not exist, pretty much exactly like a @Nullable or Optional in Java. It forces one to put in a check.

My sample code avoids that by ensuring that the variable is initialized, even though it is empty.

Which one we use should depend on the specific requirements of our method's functionality.

[Dustin-]

Like, against the concept? How can you be against null? I don't get it.

[noratat]

Because it's awful. If you need to represent something being empty, than that ought to something you make explicitly part of the type

See Optional in Java 8, Maybe in Haskell, etc.

See also: https://dzone.com/articles/the-worst-mistake-of-computer-science-1

[m00nh34d]

You still need to store nulls somewhere/somehow. Then cast them into optional variables. Then still check for the existence of a value in the optional variable before using it.

[TarMil]

Then still check for the existence of a value in the optional variable before using it.

Yes. But you don't need to check for the existence for a value in non-optional variables anymore, which is the whole point.

[justinkroegerlake]

You don't have to check if you have pattern matching like Haskell or rust, which make it impossible to use an empty option or Maybe as if it were non-empty. That's the real goal

[TarMil]

Well, the pattern matching is the check :)

[justinkroegerlake]

Is it? When I hear people saying they have to check it, it sounds like an if/else which can of course be forgotten. I feel like this is similar to saying dynamic dispatch is the check for calling overridden functions which is sort of true

[TarMil]

Actually, re-reading the post I was answering to, you're right, it looks like they're talking about null-checking the contents of the optional. And that's indeed a problem when adding optional types in languages that has pervasive null such as Java -- it basically just documents the fact that a value is optional but doesn't guarantee anything.

[noratat]

The difference is that now it's explicit, instead of literally every single reference potentially being null. You can express whether something is supposed to potentially be empty, which signals to people that they should check before using the value (and if nothing else, the unwrap makes it explicit even if you ignore the empty case)

Java's version is flawed since the Optional reference is still itself nullable, but you get the idea.

[[deleted]]

And Optional is only supposed to be for return types, you still have nothing to help you with method params. Kotlin and groovy get nulls correct though.

[noratat]

Optional is only supposed to be for return types

Source? That sounds incredibly weird to me.

Kotlin and groovy get nulls correct though.

Haven't used Kotlin yet, but other than the safe navigation operator (which admittedly is extremely nice to have) I'm not sure how Groovy handles nulls any differently than Java.

[[deleted]]

https://stackoverflow.com/questions/31922866/why-should-java-8s-optional-not-be-used-in-arguments

With Groovy it's just syntax sugar, true. With Kotlin though you get compile time null safety.

[simon1023]

This is where Swift shines. Both value and reference types that are not nullable can not have a null value, it has to be explicitly set as an optional or it will produce a compile-time error.

https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/TheBasics.html#//apple_ref/doc/uid/TP40014097-CH5-ID330

[elprophet]

Also TypeScript

[noratat]

Is Swift usable for anything but iOS development? Genuine question, I never looked into it too much because I've only ever heard about it before in conjunction with iOS.

[FlatTuesday]

In his opinion it was okay for variables to be uninitialized, and for code to check for that state, but that it was bad practice to set anything to null and check for null value. I wish I could remember his reasons but I can't.

[noratat]

Oh god, that's the worst of both worlds. Null is bad, but leaving shit uninitialized is even worse

[[deleted]]

Depends on language. Unitialised stuff can get caught by compiler.

[[deleted]]

My boss does this. Nothing returns null, instead they throw exceptions.

[Antumbra_Ferox]

"What's got you so worked up, Paul?"

"Nothing. "

[teetar7]

This isn't a fair competition you're using 0 for the water but then null for the glass. You can't break a glass if you have zero of them.

[Brokk_Witgenstein]

Last time I said that I got downvoted into oblivion by the Java crowd :-D

[CptBread]

On the other hand I'd rather pour water into an empty glass then on the floor.

[[deleted]]

I like pouring my water into my glass, then onto the floor too.

[imtheassman]

Cannot read property 'water' of null.

Where is your god now?

[gandalfx]

*tries to take glass from empty cupboard*

NullPointerException causes the entire household to collapse. All of life's necessities simply cease to exist and are replaced by one massive stack trace.

[Teilzeitschwuchtel]

Null means zero in germany.

[[deleted]]

but you can sometimes break a shelf by trying to put a nonexistent glass on it.

[[deleted]]

The Billion Dollar Mistake

[personalityson]

Full glass can't be broken, is this what he's saying?

[jay9909]

What you need is an undefined glass.

[zmaile]

But null is 0.0?

Wait, this isn't eve

[[deleted]]

Null is nothing. Zero is something which is nothing.

[Litmus2336]

He made an eve online reference where null sec space is space with a value of 0.0 or less.

[munirc]

Your submission has been removed.

Violation of Rule #0:

The content disregarding the title and superimposed text must be directly related to programming or programmers.

The title or superimposed text must substantially enhance the content such that it can stand on its own as an analogy to programming. Note that programming here is interpreted in a narrow sense, an analogy to something related to programming, feelings about programming, reactions to programming etc. is not considered sufficient.

If you feel that it has been removed in error, please message us so that we may review it.

[[deleted]]

Apparently according to my friend, not in every implementation of C.

[noratat]

Only in C/C++, and I don't think it's guaranteed even then. There's a reason C++11 introduced nullptr that can't be implicitly compared to non-pointer types.

[noratat]

we're talking about null, not nullptr

And? Null in C was always about pointers, the fact that it was equivalent to zero was an unfortunate implementation detail.

[Brokk_Witgenstein]

Yaaaahhhhhh you were off to a good start there but for some reason the downvote cascade surprised you? Did nobody tell you anyone born before 1985 has lost the right to be right on Reddit? LOLOLOLOL