Null considered beneficial

The nil or null value was discovered, seemingly independently, when creating Lisp (perhaps IPL too), PL/I, Simula, Algol W, and BCPL (where it was just integer 0).
An all-bits-zero value was already in use by assembly programmers for marking the end of a linked list or tree.
It arises naturally when implementing pointers and linked lists.
Null is a list terminator, an uninitialized value, a dummy object, a null or revoked capability.
Null makes garbage collectors and secure memory allocators possible.

Without pointers, there would still be a null analogue.
Fortran programmers used to use array indices as pointers and a 0 index as null.
Process calculi often have a null process which can be compared by identity.

Null is one of the most noble and powerful discoveries of programming.
Although it is very simple, a full understanding of its power cannot be detailed in such a short post.

>>1
https://en.wikipedia.org/wiki/0_%28number%29#History

The symbol nfr, meaning beautiful, was also used to indicate the base level in drawings of tombs and pyramids and distances were measured relative to the base line as being above or below this line.

0 is not a real number. If someone asks you "how many cats you have?" you will reply "none", not "0". 0 does not exists, it is just another jewish lie.

>>3
The most cats I had at once were 16. I now have 2.

>>3
The one cat I have isn't real either.

I have 2i cats.

The fact that NIL is both symbolp and consp is a plague on Common Lisp.

My other cat is a cdt.

>>6

2 cats

LOL!

2i girls 1 cup

>>1
Null is a sentinel value. Of all the bit patterns an address can take we reserve one to mean no value. It is a useful implementation strategy like you said, and it is popular because it is so obvious and easy to implement. The same idea is used in C-strings and NULL terminated pointer arrays and linked lists and trees.

But we can do better. The program already logically distinguishes between pointers that point to things and ones that don't. In some places we cannot know whether a result will be successful (e.g. get the next item in the list) so we allow a null pointer to be returned in certain cases. In other places we require that a pointer is not null, because the computation doesn't make sense otherwise. In many languages this turns into function preludes with boilerplate null checks, and forgotten checks gives you exceptions and segfaults.

Therefore an Option/Maybe/etc. type together with pointers that cannot be null is clearly preferable, because intent is expressed in the code. Wherever there is uncertainty you have an optional reference, and you need to handle both cases if you need to access the value that is potentially there. In other places where a value is always present references can be used directly and safely. It's an easy way to make sure there are no missing null checks, and you never accidentally dereference a null pointer again. It is also as cheap as traditional pointers, because the compiler can implement it with a sentinel value if it so pleases.

>>11

It is also as cheap as traditional pointers, because the compiler can implement it with a sentinel value if it so pleases.

It's worth noting Rust uses exactly that optimization. Option<pointer> is stored without a tag, NULL for None and pointers are recorded verbatim so the storage is pointer-sized as in C.

This optimization won't work on many kinds of enums but it will work for user defined types that qualify, such as Options (defined in std, but you might define your own if you go std-less), data-less enums, enumerations (C-style) and #[repr(C)] enums (C ABI.)

>>12
How can this work for C ABI enums? It is completely valid in C to define an enum type that contains constants over the entire range of an int. It's also very common for C programmers to explicitly define enum constants for sentinel values like -1 or 0 (which will be the first value in any enumeration by default anyway).

>>13
I don't understand the question. With #[repr(c)] they are ABI-compatible, which incidentally fulfills the optimization. Can you explain your reasons for doubt?

>>14
My point is there is no single value in C enums that can represent None in Rust, thus the optimization can't be used.

I use null in JavaScript but it's not an empty list. I heard that null === [] was called ``pornographic'' by some old guy. I don't get what pornography has to do with it.

>>15
I'm not talking about Option<_some_repr(C)_type_> types. I'm saying you can implement something like MyOption<T> or some C ABI enum (or any of the others mentioned) and the type will not be stored with a tag.

>>17
Okay. That those cases don't use a separate tag is nice, but not surprising (I'd be really disappointed if there was a tag).

>>18
I don't think C++ can do this. Anyway, I am a pessimist and I was surprised, not for #[repr(C)] but that all enums that could be space-optimized are. The optimization doesn't work on Option<MyStruct> since MyStruct is larger than a pointer, but it does work on Option<Box<MyStruct>>, so it can apply differently at concrete types.

Having to declare pointer semantics explicitly makes me like Rust even less.

>>11

Therefore an Option/Maybe/etc. type together with pointers that cannot be null is clearly preferable, because intent is expressed in the code.

Not really. It says there might not be a pointer but it doesn't say why.

>>21
Use Result then. BTW it doesn't have to be a pointer.

In Yiddish we usually say נול (pronounced /nul/), but in modern Hebrew is אפס, which its translation would be more like "naught"... anyways, >>3, the stupid idea of 0 is not a Jewish invention: the degenerated Babylonians created it.

>>23
Who's the more foolish, the fool or the fool who follows him?

An unsigned integer is a maybe gonad. maybe 1..∞. Nothing is 0.