NULL: The worst mistake of computer science? (2015) • Hacker News Board

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

#281

Post by TickleSteve » Tue, Dec 04, 2018, 7:34 PM UTC

cultus wrote: post #252

TickleSteve wrote: post #191

Earlier quoted context omitted.

Two things are getting conflated here. Pointer issues (that I was referring to) and a failure indication. The most trivial pointer issue is a NULL pointer. This is such a trivial issue to catch its hardly even an error, yet people use that case as the exemplar for NULL issues. detecting (and handling) failures on the other hand is very much different and more in the spirit of what the option-type arguments are about.…

>The most trivial pointer issue is a NULL pointer. This is such a trivial issue to catch its hardly even an error, yet people use that case as the exemplar for NULL issues. How can you claim that NPEs are "hardly ever an error." NPEs are the most common error there is! They are indeed easy to catch, but you need to do so nearly everywhere, obscuring the code and introducing potential for error. There is no real, conc…

"hardly even an error"

not

"hardly ever an error".

in other words, NULL pointer errors are a trivial error to deal with.

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

#282

Post by Twisell » Tue, Dec 04, 2018, 7:39 PM UTC

lalaithion wrote: post #177

porpoisely wrote: post #151

NULL can mean and be different things in different domains of computer science. NULL in the database world isn't the same thing in the programming world. In the programming world, null is a result of the system architecture, systems programming, etc. In SQL, NULL is a result "lack of data". There have been debates on whether there should be different types of NULL. A NULL type for "data that is available but we don't…

All of those different nulls can be solved by not having null as a special case of your database specification, but as a first class type construct. data MightBeData a = Yes a | Unavailable | NotApplicable | NeverApplicable

NULL in databases have many properties that save a shitload of coding time and help write more secure code. To cite only one of theses useful properties NULL automatically propagate through all operations and aggregations.

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

#283

Post by kazinator » Tue, Dec 04, 2018, 7:40 PM UTC

giornogiovanna wrote: post #228

davemp wrote: post #196

Earlier quoted context omitted.

This is hard to reconcile with type theory for me. NULL, to me, implies and uninhabited type, i.e. there can never be a value with a NULL type. Using null for a "data isn't there, apply, available, etc" seems like an abuse of the type system. I see no reason that the former needs to be supported at the type level. These properties are just responses to queries, not some mystical, uninhabitable oblivion. Unnecessary t…

NULL isn't the uninhabited type, that's the bottom type. NULL is a value that inhabits every type.

Not in all languages. In Lisp dialects related to classical Lisp, like ANSI Lisp, there is a unique nil object which is a kind of symbol. It is self-evaluating and serves as (the one and only) Boolean false value, and also as a representation for the empty list, which terminates all non-circular lists.

There is no nil-like value in the domain of any other type. If you hold a value which satisfies stringp then you know you have a string of zero or more characters and not some null reference.

Because the typing is dynamic, then if you have a situation in which you would like to either have a string, or a value indicating "there is no string here now", you can use nil for that. But replacing a string variable with nil changes the type; it is not a string reference that has been nulled out, but a string object previously stored in the variable has been replaced with the nil object.

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

#284

Post by yxhuvud » Tue, Dec 04, 2018, 7:51 PM UTC

ArchTypical wrote: post #276

yxhuvud wrote: post #271

Earlier quoted context omitted.

> NULL is a value that inhabits every type. Not in all type systems. Particularly, type systems which has union types may chose to simply create a separate type for NULL. There are also variants that have separate NULL types for different base types, which also invalidate your claim.

> Not in all type systems I think this is inaccurate. We are talking about computer science, which is important and a constraint around the general type theory. A type system is different than how you interact with it, so dispensing with language-specific symbolic representation further normalizes the discussion. Fundamentally, a (computer science) type is a representation of binary, for the most part, data. That rep…

It was not I that downvoted you, but I agree with the down-voter in that you are not making good arguments. There is basically nothing in common with NULL as used by programming languages in general compared to how you want to define it in your comment. How NULL is represented internally, is totally language dependent. C and its ilk has defined it one way (that is reasonably close to your description ON SOME ARCHITECTURES - not all), but how other languages define it differ wildly.

And strings may only grow if strings are mutable, which AGAIN is extremely language dependent.

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

#285

Post by basil-rash » Tue, Dec 04, 2018, 7:57 PM UTC

masklinn wrote: post #240

gnulinux wrote: post #139

Earlier quoted context omitted.

Because it's a 0 overhead abstraction and guard against the case when you (or a coworker) forget to check for null. Are we seriously gonna pretend like you never caused a null pointer exception?

std::optional doesn't do that though, you can deref an empty optional and the result's the same as deref'ing an empty unique_ptr or a null pointer: UB.

But it makes you stop and thing before doing so. Thats the whole point.

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

#286

Post by Sharlin » Tue, Dec 04, 2018, 8:02 PM UTC

ArchTypical wrote: post #276

yxhuvud wrote: post #271

Earlier quoted context omitted.

> NULL is a value that inhabits every type. Not in all type systems. Particularly, type systems which has union types may chose to simply create a separate type for NULL. There are also variants that have separate NULL types for different base types, which also invalidate your claim.

> Not in all type systems I think this is inaccurate. We are talking about computer science, which is important and a constraint around the general type theory. A type system is different than how you interact with it, so dispensing with language-specific symbolic representation further normalizes the discussion. Fundamentally, a (computer science) type is a representation of binary, for the most part, data. That rep…

This does not make sense. Null is not the same as zero and neither is the same as an all-zeros bit pattern. A memory word interpreted as an integer has no meaningful null value. A memory word interpreted as a pointer may or may not have a special bit pattern (which may or may not be the same as integer zero) that represents a pointer to nowhere; it all depends on language semantics. The address 0x0 can be perfectly valid on some architectures. Even though in C the literal 0 denotes a null pointer constant, it does not mean that the value of a null pointer is literally zero.

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

#287

Post by taco_emoji » Tue, Dec 04, 2018, 8:04 PM UTC

userbinator wrote: post #110

To someone who has been using Asm and C for decades, these arguments just make no sense. Reading this article reminds me of the arguments against pointers, another thing that's frequently criticised by those who don't actually understand how computers work and try to "solve" problems by merely slathering everything in thicker and thicker layers of leaky abstraction. It's not far from "goto considered harmful" either.…

> ...because it indicates the absence of a value, which is a special case.

But that's exactly the problem -- it's special, meaning it's only useful for certain situations. An ideal type system would provide compile-time guarantees, rather than having to wait for users to report issues. A type system which A) allows you to define variables as non-nullable and B) requires a null guard before every dereference of nullable variables eliminates this entire class of bug. What on earth is wrong with that?

EDIT:

> Seriously? A "nullpo crash" is one of the more trivial things to debug

Even if this were true [0], wouldn't it be easier if such a crash was just never even possible?

[0] which it's not - all a nullpo stack trace tells you is that something important didn't happen, at some point before this

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

#288

Post by jstimpfle » Tue, Dec 04, 2018, 8:06 PM UTC

tangent128 wrote: post #274

jstimpfle wrote: post #103

Earlier quoted context omitted.

> Implicit nullability doesn't really save you any null checks. It sort of does, because explicit nullability forces you to do many redundant null checks when you actually knew that something could not possibly be null.

If you know something can't possibly be null, then store it as a non-nullable type as soon as you know that.

> as soon

that would need dynamically typed data...

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

#289

Post by jstimpfle » Tue, Dec 04, 2018, 8:11 PM UTC

lmm wrote: post #263

jstimpfle wrote: post #179

Earlier quoted context omitted.

> but are you saying that throwing a segfault can be a good thing? Sure, what's bad about it? A logic bug was detected, so the program should be terminated. Or how do you intend to continue? Segfault is not so different from what happens if you do "fromJust Nothing" in Haskell or get a NullPointerException in Java. You can even write a handler for the segfault, but I guess that's rarely a good idea.

> Sure, what's bad about it? A logic bug was detected, so the program should be terminated. Or how do you intend to continue? I intend to not have the logic bug in the first place, by encoding my invariants in the type system. If you "know" that the value is present rather than absent, you must have a reason for knowing it, so explain that reason to the compiler. E.g. maybe you took the first element of a list value…

> by encoding my invariants in the type system

the way I program that is nothing but a pipe dream.

> If you "know" that the value is present rather than absent, you must have a reason for knowing it, so explain that reason to the compiler.

I might know that it exists for example because it is computed in a post-processing step after a first stage but before a second stage. So it exists in the second stage but not in the first. Relying on global data (which I won't give up) makes it practically impossible to encode that the data is not there in the first stage.

And that's not a problem at all. I simply don't access that data table in the first stage... Trying to explain my processing strategy to a compiler would amount to headaches and no benefits.

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

#290

Post by da_chicken » Tue, Dec 04, 2018, 8:13 PM UTC

icedchai wrote: post #272

da_chicken wrote: post #225

Earlier quoted context omitted.

NULL isn't a Boolean value in ternary logic any more than 3.2 or 'Hello' or December 12, 2018, have Boolean values. It's UNKNOWN. UNKNOWN is related to NULL, but they don't work identically. NULL is a value that any column data type can potentially have. NULL is what comparison and evaluation operators work with. UNKNOWN is a ternary Boolean type, and the Boolean type is what Boolean operators work with (AND, OR, NOT…

NULL is an alias for UNKNOWN on many systems (like MySQL.) Other DBs don't even have UNKNOWN. UPDATE table set col=value1 and value2 works fine IF value1 and value2 are booleans.

That's a great example of MySQL creating a proprietary extension of ANSI SQL that does little more than deliberately mislead users.