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

311–320 of 377 posts

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

#311

Post by dpcx »

nayuki wrote: post #198
bunderbunder wrote: post #149

You know who works on a platform with NULL but doesn't have quite so many problems with it? DBAs. There's some need to draw a distinction between the basic idea of NULL, and the way that NULL has been implemented in most high-level programming languages. In most RDBMSes, values can't be null unless you say they are. Sometimes explicitly, as in table definitions, sometimes implicitly, when you select a JOIN type. Eith…

NULL in SQL really isn't great. For one, nullable table columns is a bad default, and you have to explicitly write out "NOT NULL" to avoid this behavior. I'd say that 90% of the time I want not-null table columns, and only 10% of the time do I want a nullable column. Secondly, NULL has weird arithmetic. It turns out that NULL=NULL is false, and NULL NULL is also false. (This is unlike C/Java/Python/etc. by the way.)…

I can get behind your first statement. Having NULLable as a default on columns is "probably" a bad idea.

I'm not so sure I can agree with the other two. NULLNULL (and NULL=NULL) both return false for a very simple reason: truly missing data _can't_ be equal to anything, including missing data... Because it's missing. You cannot with certainty say that value1 is or is not equal to each other.

For the third point... What should max(column) return when there's no data? You're telling the engine "give me the maximum value of something that doesn't exist". That is, in my experience, "missing data."

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

#312

Post by jstimpfle »

lmm wrote: post #306
jstimpfle wrote: post #289

Earlier quoted context omitted.

> 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…

> 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. So the first stage could create a handle to it, or even just a phantom "witness" that you treat as proof that the value is present. > And that's not a problem at all. I simply don't access that data table in the first stage...…

Accesses to unallocated global data is the type of errors that you typically hit on the first test run. Another example would be function pointers loaded from DLLs.

I don't think type systems help all that much. Type + instead of -, and you're out of luck.

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

#313

Post by eksemplar »

Twisell wrote: post #282
lalaithion wrote: post #177

Earlier quoted context omitted.

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.

I think you can say something similar about programming languages that don't have automatic memory assignment.

It can be perfectly valid to have a pointer reserved in memory, without having given it a value to point to yet. I see why this isn't much of an issue in 2015, but it was.

I don't think NULL is a problem at all really, but it sure isn't fun in languages like C# where you can have nullable types, but I think that's a problem with C# and not the concept of NULL.

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

#315

Post by lmm »

jstimpfle wrote: post #312
lmm wrote: post #306

Earlier quoted context omitted.

> 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. So the first stage could create a handle to it, or even just a phantom "witness" that you treat as proof that the value is present. > And that's not a problem at all. I simply don't access that data table in the first stage...…

Accesses to unallocated global data is the type of errors that you typically hit on the first test run. Another example would be function pointers loaded from DLLs. I don't think type systems help all that much. Type + instead of -, and you're out of luck.

> Accesses to unallocated global data is the type of errors that you typically hit on the first test run.

Depends what conditions cause it; the hard part is being sure that every possible code path through the first stage will initialise the data, even the rare ones like cases where some things time out but not others.

> I don't think type systems help all that much. Type + instead of -, and you're out of luck.

Not my experience at all - what do you mean? If you declare a type as covariant instead of contravariant or vice versa, you'll almost certainly get errors when you come to use it.

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

#316

Post by shittyadmin »

steveklabnik wrote: post #167
kiriakasis wrote: post #162

Earlier quoted context omitted.

the main numeric type is usize

That’s not correct, it’s i32. usize has a specific purpose: when you need a length of something in memory.

The entire idea of a "main numeric type" is sort of silly - know what data you're dealing with and pick the length accordingly!

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

#318

Post by ArchTypical »

Sharlin wrote: post #286
ArchTypical wrote: post #276

Earlier quoted context omitted.

> 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 v…

> A memory word interpreted as an integer has no meaningful null value.

What a type is, depends on what the runtime operates on. You can make a runtime that just grabs random bits of data as a type and say "that's an integer" but it's not a useful construct/example. A runtime keeps track of types in some way external to the data itself. So I'll disagree that an all-zeros is not the same as a null, because it's a common way to initialize the data that is identified with a type (like in a pointer table). It's not a 1:1 but it's common. There's not always a formalized name, but it (an uninitialized state) always exists as part of the type system (when not reusing existing memory allocation, which is an initialized state). Always.

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

#319

Post by jchw »

taco_emoji wrote: post #297
jchw wrote: post #195

Earlier quoted context omitted.

I dunno why everyone's assuming I don't know about the common solutions to the problem. TypeScript does explicit nullness without needing monads, and I actually mentioned that one. I still disagree that this is not overrated. Go's idea of nil, for example, seems OK to me, and the language would need to be way more complex to fix it. For example, it would need a type system with explicit nullness, or maybe even actual…

But nobody's talking about "getting rid of nil" wholesale. They're talking about getting rid of null/nil reference exceptions via the mechanisms of non-nullability (having the option to define some variables as non-nullable) and null guards (a compiler which forces a null check before any operation which requires a non-null value). This way you still have null, but with compile-time guarantees that you'll never get n…

That's the same as the TypeScript approach, but its never going to happen in Go because of the relatively small gain for a massive jump in complexity in the compiler.

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

#320

Post by steveklabnik »

shittyadmin wrote: post #316
steveklabnik wrote: post #167

Earlier quoted context omitted.

That’s not correct, it’s i32. usize has a specific purpose: when you need a length of something in memory.

The entire idea of a "main numeric type" is sort of silly - know what data you're dealing with and pick the length accordingly!

Yeah, I only say "main" here because it's what you should pick if you're not sure.
Post reply on HN