Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

NULL: The worst mistake of computer science? (2015)

lucidchart.com

Post reply on HN
Print view View original

211–220 of 377 posts

Re: NULL: The worst mistake of computer science? (2015)

#211

Post by estebank »

jhomedall wrote: post #147
pdkl95 wrote: post #50

> NULL is a value that is not a value. And that’s a problem. The problem isn't NULL, it's languages not enforcing the necessary checks for the "no data" condition. Option can still be NULL ("None" in rust), wrapping NULL in a struct doesn't provide any safety. The safety of Option wrapper types is from the other language features (like rust's "match") and a stricter compiler that forces the programmer to write the NU…

> Option can still be NULL ("None" in rust) 'None' in Rust is part of the Option enum, not an equivalent to null. pub enum Option { None, Some(T), }

It can be at the machine level. If T is NonZero, then sizeof(Option) == sizeof(T).

Re: NULL: The worst mistake of computer science? (2015)

#212

Post by da_chicken »

nayuki wrote: post #202
bunderbunder wrote: post #187

Earlier quoted context omitted.

I guess. My tendency is to think that it's more a problem for developers who are new to SQL, and are surprised to find out that, despite having the same name, nulls in SQL don't have the same semantics as nulls in other languages. Once you get a handle on the semantics, though, they make a lot of sense. The trick is to understand how SQL's NULL is rooted in mathematical formalism, not the pragmatics of dealing with p…

In SQL, NULL NULL yields false. You use IS NULL / IS NOT NULL to test for NULL values. In programming languages, NaN!=NaN yields true. You use x!=x to test for NaN values. Saying that SQL NULL is rooted in mathematical formalism doesn't explain anything, because anything (even nullptr and NaN) can be explained in mathematical formalism. What we want is a simple semantic model that a human can understand and one that…

> In SQL, NULLNULL yields false.

No, NULL NULL yields UNKNOWN. That's why NULL NULL and NOT (NULL NULL) behave the same: they have the same value. UNKNOWN is a first-order truth value in ternary logic.

The key is that in a WHERE clause, a record is only returned if the WHERE clause evaluates to TRUE. Not TRUE or UNKNOWN. TRUE.

Re: NULL: The worst mistake of computer science? (2015)

#213

Post by tabtab »

From my practical experience, Null has a use, but is over-used or misused. If you concatenate a Null string to other non-Null strings, the Null should usually be treated like a zero-length string instead of nullifying the ENTIRE expression result. I know this differs from how numbers typically are treated, but so be it. Strings are not numbers.

Without that behavior, one often has to write verbose statements such as: denull(stringA,"") || denull(stringB,"") || denull(stringC,"") || denull(stringD,"") etc. ("denull" name varies per vendor. "||" is concatenate here.)

Re: NULL: The worst mistake of computer science? (2015)

#214

Post by bluejekyll »

nayuki wrote: post #190

I agree with pretty much everything in the article. However, I would give Java a lower score because no one uses java.lang.Optional in practice, and there is too much legacy libraries and application code that cannot or will not be changed. Also, the @NotNull annotation isn't in Java SE; it is made available through various third-party libraries. A language with a null value can dramatically simplify things for a lan…

It appears that Java will eventually get Value types, which will allow for Optional to be defined on the stack, at least making it actually do something useful.

Re: NULL: The worst mistake of computer science? (2015)

#215

Post by icebraining »

rusk wrote: post #189
icebraining wrote: post #123

Earlier quoted context omitted.

You can conceptualize the Maybe based on the NULL, but there's no point in the compilation or runtime in which they actually become NULLs, it's just a regular container value.

Which is the same as if I go and ensure a default "noop" value is assigned ... it's logically a NULL. I don't know anything about it except that it hasn't been assigned.

It's not a NULL. A NULL is a value that is considered by the type system to be a valid instance of a given type, except it doesn't actually fulfill the type's contract. A Maybe is a completely different type, much like a list or a map or a tree.

Re: NULL: The worst mistake of computer science? (2015)

#216

Post by TheCoelacanth »

enriquto wrote: post #53
doubletgl wrote: post #34

Isn't there an inherent need in programming to express an explicit "nothing" value? Coming from Python and JS, I never found None/null to be much of a problem. I in fact like the distinction of null and undefined in JS. Using null allows you to distinguish from the accidental undefined.

> Isn't there an inherent need in programming to express an explicit "nothing" value? In numerical calculus: yes, most certainly. What do you expect the result of log(-1) to be? The alternative is to use specially tagged particular numbers as "no-data", and pray so that they do not appear naturally as the result of computations.

That doesn't mean numbers need to always be nullable. It means that `log` doesn't return a number, it returns a nullable number.

Re: NULL: The worst mistake of computer science? (2015)

#217

Post by masklinn »

nayuki wrote: post #202
bunderbunder wrote: post #187

Earlier quoted context omitted.

I guess. My tendency is to think that it's more a problem for developers who are new to SQL, and are surprised to find out that, despite having the same name, nulls in SQL don't have the same semantics as nulls in other languages. Once you get a handle on the semantics, though, they make a lot of sense. The trick is to understand how SQL's NULL is rooted in mathematical formalism, not the pragmatics of dealing with p…

In SQL, NULL NULL yields false. You use IS NULL / IS NOT NULL to test for NULL values. In programming languages, NaN!=NaN yields true. You use x!=x to test for NaN values. Saying that SQL NULL is rooted in mathematical formalism doesn't explain anything, because anything (even nullptr and NaN) can be explained in mathematical formalism. What we want is a simple semantic model that a human can understand and one that…

> In SQL, NULLNULL yields false.

It yields NULL, not false. So do NULL = NULL or NOT NULL.

Re: NULL: The worst mistake of computer science? (2015)

#218

Post by chongli »

kzrdude wrote: post #141
chongli wrote: post #136

Earlier quoted context omitted.

No, the problem with null is the inability to enforce, at the type level, that a particular value is not null. C simply does not have a type for "guaranteed valid pointer to x".

C allows defining new types though, so it can be done.

Could you provide an example? Either source code or a link. I want to see how you might define a type for "guaranteed to not be null pointer to char".

Re: NULL: The worst mistake of computer science? (2015)

#219

Post by masklinn »

danesparza wrote: post #145
masklinn wrote: post #58

Earlier quoted context omitted.

> The problem isn't NULL, it's languages not enforcing the necessary checks for the "no data" condition. Talking about "NULL" pretty much implies that. When Tony Hoare talks about null references, it's about every reference being nullable in languages like Java or C#, not about the ability to conceptually wrap/opt non-nullable references in a nullability thingie.

Psst: I think the thingie you're referring to is called a 'monad': https://en.wikipedia.org/wiki/Monad_(functional_programming)

No. The thingie may or may not be monadic, but I'm using thingie because it could be a "library" sum type, or it could be a magical-ish builtin, or it could be some other mechanism.

Re: NULL: The worst mistake of computer science? (2015)

#220

Post by masklinn »

vmchale wrote: post #193
pdkl95 wrote: post #50

> NULL is a value that is not a value. And that’s a problem. The problem isn't NULL, it's languages not enforcing the necessary checks for the "no data" condition. Option can still be NULL ("None" in rust), wrapping NULL in a struct doesn't provide any safety. The safety of Option wrapper types is from the other language features (like rust's "match") and a stricter compiler that forces the programmer to write the NU…

> Option can still be NULL ("None" in rust), wrapping NULL in a struct doesn't provide any safety. The safety of Option wrapper types is from the other language features (like rust's "match") The advantage here (especially true in Haskell) is that you can use monadic error handling to make this far more pleasant.

That's a secondary nicety (alongside the ability to make everything "nullable" not just the references/pointers subset), the primary advantage is that:

1. it clearly separates "nullable" and "non-nullable" providing better modelling tools

2. the compiler assists/mandates null-checking, providing better type-safety

Post reply on HN