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

271–280 of 377 posts

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

#271

Post by yxhuvud »

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.

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

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

#272

Post by icedchai »

da_chicken wrote: post #225
masklinn wrote: post #217

Earlier quoted context omitted.

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

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.

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

#273

Post by jchw »

cyphar wrote: post #229
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…

Don't get me wrong, Go does nil a lot better than some other languages (being able to call methods on a nil is sometimes a good thing depending on how your methods handle it -- most methods don't handle it well at all). The fact that even most map operations (access and deletion) also "just work" is really useful. But I think you're over-selling the zero values feature of Go. It is very rare to see third-party librar…

I'm not overselling zero values in Go. Simply try to envision the cascading consequences on the language if you removed the zero values; no existing Go code would work, and I think the language would need to shift so much that even hello world couldn't be automatically translated to such a language. All to prevent a single type of runtime error among many, one that Go developers are not complaining about the way that Java, JavaScript, C developers have.

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

#274

Post by tangent128 »

jstimpfle wrote: post #103
virtualized wrote: post #61

Earlier quoted context omitted.

It's the worst mistake because it made you believe that its atrocious ergonomics are actually superior to more sensible solutions. Implicit nullability doesn't really save you any null checks. It just makes it possible to forget necessary checks. It was fine to design a language with nullable pointers in the 70s. It's unacceptable nowadays. nil in Go is a major mistake.

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

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

#275

Post by yxhuvud »

dtech wrote: post #223
davemp wrote: post #205

Earlier quoted context omitted.

Yes, option types are awesome. No, they are not nulls. Algebraic data types are not direct support "no data found at the type level". Algebraic types are really just a fancier enum/union type. It just so happens that inventing special sentinel values is awesome when you have an algebraic type system to check your work.

Take a look at Kotlin or Typescript†. Basically, they decided to fully design the language with support for null-as-option. That means several things: * T (non-nullable) and T? (nullable) are different types. T? = T | null * Where T is expected T? is not accepted, but where T? is specified T is also accepted * T? is automatically cast to T in the places where it's asserted to be not null, e.g. within an if(x != null)…

If you like those features, I think you would like Crystal, which has much of the same. Full union types, flow typing and type inference for basically everything on the stack makes for a very fluid and scripting language like experience while keeping type safety.

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

#276

Post by ArchTypical »

yxhuvud wrote: post #271
giornogiovanna wrote: post #228

Earlier quoted context omitted.

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

> 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 representation has to inhabit some part of bounded memory. When that memory is initialized (empty), it's some form of NULL, for a lack of another term. It exists for every type system in computer science.

> There are also variants that have separate NULL types for different base types, which also invalidate your claim

That's not the same thing. Different NULL types make sense for different sized discrete (fixed bounds) memory allocation. A unicode character has a fixed size allocation, while a string might be unbounded allocation (it grows in some fashion, as needed).

Edit: Kneejerk downvoting, classy.

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

#277

Post by yxhuvud »

lmm wrote: post #258
dtech wrote: post #223

Earlier quoted context omitted.

Take a look at Kotlin or Typescript†. Basically, they decided to fully design the language with support for null-as-option. That means several things: * T (non-nullable) and T? (nullable) are different types. T? = T | null * Where T is expected T? is not accepted, but where T? is specified T is also accepted * T? is automatically cast to T in the places where it's asserted to be not null, e.g. within an if(x != null)…

That's a terrible approach because it's inherently noncompositional and thus breaks parametricity. You can't tell whether T? is the same type as T without knowing what T is, so if you use T? and handle null in your generic functions then they might suddenly misbehave when passed a null. (Previously said T?? rather than T?, thanks to corrections in replies)

> You can't tell whether T?? is the same type as T?

Huh? T?? would always be the same type as T?. `T | NULL | NULL == T | NULL`.

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

#278

Post by crooked-v »

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.

Consider Javascript, where undefined and null are both unique primitive values.

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

#279

Post by kazinator »

davemp wrote: post #196
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…

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…

This is clear in (Common) Lisp.

There is a null class/type whose one and only instance is the special object nil.

This nil also itself names a type which contains no instance: its domain of values is the empty set. This is the type at the bottom of the type spindle, corresponding to the NULL that you're talking about.

nil is a special self-evaluating symbol representing Boolean false, the empty list, and this bottom type.

So you see, if we just don't conflate the null object with the null set type, everything works out.

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

#280

Post by dragonwriter »

lmm wrote: post #258
dtech wrote: post #223

Earlier quoted context omitted.

Take a look at Kotlin or Typescript†. Basically, they decided to fully design the language with support for null-as-option. That means several things: * T (non-nullable) and T? (nullable) are different types. T? = T | null * Where T is expected T? is not accepted, but where T? is specified T is also accepted * T? is automatically cast to T in the places where it's asserted to be not null, e.g. within an if(x != null)…

That's a terrible approach because it's inherently noncompositional and thus breaks parametricity. You can't tell whether T? is the same type as T without knowing what T is, so if you use T? and handle null in your generic functions then they might suddenly misbehave when passed a null. (Previously said T?? rather than T?, thanks to corrections in replies)

I think you have too many ? in there; you can't tell if T? is the same type as T unless you know if T is U? for some U. (This is true of untagged unions more generally, ? is just shorthand for | null.)

But T?? is always identical to T?.

Post reply on HN