6 ms·

The user neelk states that one of the bad things about the language is "Null. In 2011." Can someone clarify for me why having null in a language is bad (other

by jazzyb 15y ago

The user neelk states that one of the bad things about the language is "Null. In 2011." Can someone clarify for me why having null in a language is bad (other than how dereferencing/calling-a-method on null in most languages results in your program crashing)? Come to think of it, I'm not even aware of a language without null.

jganetsk 15y ago
It's not null that's the issue, it's that everything is nullable by default (and there is no way to statically guarantee something non-nullable). OCaml and Haskell are not-nullable by default, and things that are nullable have an extra layer around them that must be dealt with. This is quite sensible.
- enneff 15y ago
  Go strikes a nice balance, IMO. Value types (booleans, numbers, strings, structs, arrays) cannot be null, while reference types (pointers, slices, maps, channels) may be null. Also, Go calls null 'nil', which is fitting since nil is the zero value of a reference type. (All variables are initialized to their zero value unless otherwise specified.)
  - wanorris 15y ago
    .Net does the same thing (though strings and arrays are reference types, not value types), but it doesn't really solve the problem. If you write a function that performs an operation on a dictionary/hashtable/map/associative array, it would still be nice to be able to define it into the method signature that it's required (read: errors will be caught at compile time) to actually receive a reference to a dictionary. Or alternatively, that a null value is explicitly possible and that this should be accounted for. I agree with jganetsk and others -- after having used languages like Haskell where there are non-nullable types by default, every language that doesn't do this simply feels broken by comparison. It's sort of like going back to languages that require to you manually allocate memory and perform pointer arithmetic -- you can do it, but after years in the modern language of your choice that does it for you, it just seems unnecessary and basically wrong.
  - smosher 15y ago
    That's the exact thing C does. The only thing Go does differently is put a ban on implicit conversions.
jganetsk 15y ago
It's not null that's the issue, it's that everything is nullable by default (and there is no way to statically guarantee something non-nullable). OCaml and Haskell are not-nullable by default, and things that are nullable have an extra layer around them that must be dealt with. This is quite sensible.
sdevlin 15y ago
It's not really having null that's bad. What's bad is making types nullable by default. More often than not, null is not a valid value for a variable (in my experience - YMMV). This is a common source of errors. Some languages (I'm thinking of ML and Haskell) require you to opt into nullability with an option type (e.g. http://www.standardml.org/Basis/option.html http://www.standardml.org/Basis/option.html). What's worse is that many mainstream languages do not allow you to opt out of nullability. I.e. most or all types are always nullable.
- deleted 15y ago
  [deleted]
sgk284 15y ago
The problem with null is that when anything can be null, your type system is always lying to you and as a result you don't get the full benefits of a real type system (see Haskell for a great type system). When a var is a boolean, you can't assume it's true or false, because it could also be null. Or when you pass a Car object into a function, you've been promised a Car but were lied to because it might also be null. In a proper type system, if you ask for a boolean, you know that variable is either true or false and when you ask for a car, you're guaranteed to get a car. Of course, you can always have the option of allowing null values, but you should explicitly have to state that it's okay.
robinhouston 15y ago
There’s a strand of thinking which holds that null references are a common source of avoidable errors that the compiler could have prevented in a better-designed language. The objection is not so much that nulls exist, but that it’s impossible to declare a reference variable as “not null” in a way that the compiler can check. Tony Hoare recently (2009) called null references his “Billion Dollar Mistake” [1, 2, 3]. 1. http://qconlondon.com/london-2009/presentation/Null+References:+The+Billion+Dollar+Mistake http://qconlondon.com/london-2009/presentation/Null+Referenc... 2. http://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare http://www.infoq.com/presentations/Null-References-The-Billi... 3. http://lambda-the-ultimate.org/node/3186 http://lambda-the-ultimate.org/node/3186
losvedir 15y ago
My dabbling in Haskell has given me a new perspective on null. Previously, to me "null" was just "that other value that a variable gets if the function doesn't work or something unexpected happens." It was useful if ugly. I didn't fully grasp how much that null possibility permeated my code, since I didn't know any other way. However, in Haskell, if something is an integer, it really is an integer of some sort. Null is not allowed. So if you're writing a function that works with numbers, you really have to think about what are valid inputs and outputs. If you're working with a function whose domain really is all integers, then you can indicate that with a Integer -> Integer function, and you're on rock solid ground. However, if you're writing a function like, e.g. square root, where the domain is not all integers, then you have to worry about what happens if you get a negative one. Now you can choose to bring in "null" as an allowable value, but it will have to be explicitly indicated and dealt with. Your function, for all the world to see, will be Integer -> Maybe Integer, and then any other function that uses that function will be forced to deal with the fact that a null might happen.
- timclark 15y ago
  This is Haskell esoterica, any value can set as undefined an equivalent value to null. However, you never see code using undefined as null since Maybe a is so much clearer.
  - jganetsk 15y ago
    undefined and null are quite different. It's impossible to test for undefined. You cannot expect (x == undefined) to return true. It would result in exception, in fact. You can only safely make a value undefined if you guarantee it won't be used.
cachemoney 15y ago
An alternative is an option type. In scala, you have the abstract type Option[T], which has implementations Some[T](value: T) and None[T]. Alternately, you have Either[A, B], with implementations Left[A](value: A), and Right[B](value: B). So you can define a function that takes an Either[Int, ErrorMessage], rather than an Int or null. Getting a None[Int] is better than null, because it won't throw NullPointerExceptions if you access it sensibly. Examples: def x2or0(i: Option[Int]): Int = i.getOrElse(0) * 2 def x2(i: Option[Int]): Option[Int] = i.map(_ * 2) def x2danger(iOrPossiblyNull: Int) = i * 2 // throws NullPointerException on null input
rayiner 15y ago
The responses below are an adequate summary of what would be the case if a statically typed language (Haskell, ML) featured nullable types. However, they're all largely inapposite for Dart. Dart's type system can't even ensure, at compile-time, that you'll never see an integer in a variable typed as a string. It can catch a lot of such cases, but it's fundamentally a dynamically-typed language and can't make really any guarantees at all statically. So non-nullable types in Dart would be a fiction. Any object typed anything might end up being null at runtime.
- ericbb 15y ago
  I haven't read much at all about Dart yet so forgive me if I'm missing something but it seems to me that dynamic-typing capabilities do not rule out absence-of-null. Doesn't Dart's use of optional typing mean that it really behaves as a statically-typed language in some contexts? The Go language sort of has this via interface types. Consider the following: type Foo struct { a, b int } func Bar(x interface{}) Foo { if f, ok := x.(Foo); ok { return f // x is a Foo at runtime so return it } return Foo{0, 1} } There is no need for the Foo type to have a null value. Go does have general zero-values for all types but that's somewhat different from null and not the only solution either. I think a Haskell-like model (neither null nor zero-value) could also work.
  - rayiner 15y ago
    Dart never really behaves like a statically-typed language. Take this code: http://try-dart-lang.appspot.com/s/bA0X http://try-dart-lang.appspot.com/s/bA0X It not only doesn't give an error, but it runs just fine. main() passes "cake" to bar(), which passes "cake3" to foo(), because String overloads the + operator to coerce its RHS to a string before concatenating. foo() ends up receiving a string despite being declared as receiving a number, but does what one would expect because '+' is defined for strings as well as numbers. The compiler does not complain because it does not try to unify types globally. It does not care that bar(), which is declared as taking any type then passes that to foo() which is declared as taking a number. If you change the 'var' in the declaration of bar() to 'num' you will indeed get a type error in main() when it tries to pass bar() a string. So making types non-nullable in Dart would have little utility. Dart can't statically ensure that a variable declared as 'num' doesn't end up being a 'String' at run time, much less ensure that a variable is non-null. I don't see this as a weakness of Dart. The point of Dart's optional types is to enforce some structure, provide documentation, and avoid obvious mistakes in an otherwise dynamically typed language. Statically enforcing invariants like non-nulity is really beyond its scope.
azakai 15y ago
> The user neelk states that one of the bad things about the language is "Null. In 2011." Can someone clarify for me why having null in a language is bad (other than how dereferencing/calling-a-method on null in most languages results in your program crashing)? That right there is the reason. Those crashes are a huge burden on the software industry, it's even been called the "billion dollar mistake", http://lambda-the-ultimate.org/node/3186 http://lambda-the-ultimate.org/node/3186 And of course it is possible to have references which cannot be null, for example, even C++ has this: References as opposed to pointers. Many new languages have adopted the non-null approach, off the top of my head, Rust.
bartwe 15y ago
Compiletime enforcement that a reference isn't null in a language like java is very powerfull, more useful then c++ const in my opinion.

by jazzyb 15y ago

jganetsk 15y ago

It's not null that's the issue, it's that everything is nullable by default (and there is no way to statically guarantee something non-nullable). OCaml and Haskell are not-nullable by default, and things that are nullable have an extra layer around them that must be dealt with. This is quite sensible.

enneff 15y ago
Go strikes a nice balance, IMO. Value types (booleans, numbers, strings, structs, arrays) cannot be null, while reference types (pointers, slices, maps, channels) may be null. Also, Go calls null 'nil', which is fitting since nil is the zero value of a reference type. (All variables are initialized to their zero value unless otherwise specified.)
- wanorris 15y ago
  .Net does the same thing (though strings and arrays are reference types, not value types), but it doesn't really solve the problem. If you write a function that performs an operation on a dictionary/hashtable/map/associative array, it would still be nice to be able to define it into the method signature that it's required (read: errors will be caught at compile time) to actually receive a reference to a dictionary. Or alternatively, that a null value is explicitly possible and that this should be accounted for. I agree with jganetsk and others -- after having used languages like Haskell where there are non-nullable types by default, every language that doesn't do this simply feels broken by comparison. It's sort of like going back to languages that require to you manually allocate memory and perform pointer arithmetic -- you can do it, but after years in the modern language of your choice that does it for you, it just seems unnecessary and basically wrong.
- smosher 15y ago
  That's the exact thing C does. The only thing Go does differently is put a ban on implicit conversions.

jganetsk 15y ago

sdevlin 15y ago

It's not really having null that's bad. What's bad is making types nullable by default. More often than not, null is not a valid value for a variable (in my experience - YMMV). This is a common source of errors. Some languages (I'm thinking of ML and Haskell) require you to opt into nullability with an option type (e.g. http://www.standardml.org/Basis/option.html http://www.standardml.org/Basis/option.html). What's worse is that many mainstream languages do not allow you to opt out of nullability. I.e. most or all types are always nullable.

deleted 15y ago
[deleted]

sgk284 15y ago

The problem with null is that when anything can be null, your type system is always lying to you and as a result you don't get the full benefits of a real type system (see Haskell for a great type system). When a var is a boolean, you can't assume it's true or false, because it could also be null. Or when you pass a Car object into a function, you've been promised a Car but were lied to because it might also be null. In a proper type system, if you ask for a boolean, you know that variable is either true or false and when you ask for a car, you're guaranteed to get a car. Of course, you can always have the option of allowing null values, but you should explicitly have to state that it's okay.

robinhouston 15y ago

There’s a strand of thinking which holds that null references are a common source of avoidable errors that the compiler could have prevented in a better-designed language. The objection is not so much that nulls exist, but that it’s impossible to declare a reference variable as “not null” in a way that the compiler can check. Tony Hoare recently (2009) called null references his “Billion Dollar Mistake” [1, 2, 3]. 1. http://qconlondon.com/london-2009/presentation/Null+References:+The+Billion+Dollar+Mistake http://qconlondon.com/london-2009/presentation/Null+Referenc... 2. http://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare http://www.infoq.com/presentations/Null-References-The-Billi... 3. http://lambda-the-ultimate.org/node/3186 http://lambda-the-ultimate.org/node/3186

losvedir 15y ago

My dabbling in Haskell has given me a new perspective on null. Previously, to me "null" was just "that other value that a variable gets if the function doesn't work or something unexpected happens." It was useful if ugly. I didn't fully grasp how much that null possibility permeated my code, since I didn't know any other way. However, in Haskell, if something is an integer, it really is an integer of some sort. Null is not allowed. So if you're writing a function that works with numbers, you really have to think about what are valid inputs and outputs. If you're working with a function whose domain really is all integers, then you can indicate that with a Integer -> Integer function, and you're on rock solid ground. However, if you're writing a function like, e.g. square root, where the domain is not all integers, then you have to worry about what happens if you get a negative one. Now you can choose to bring in "null" as an allowable value, but it will have to be explicitly indicated and dealt with. Your function, for all the world to see, will be Integer -> Maybe Integer, and then any other function that uses that function will be forced to deal with the fact that a null might happen.

timclark 15y ago
This is Haskell esoterica, any value can set as undefined an equivalent value to null. However, you never see code using undefined as null since Maybe a is so much clearer.
- jganetsk 15y ago
  undefined and null are quite different. It's impossible to test for undefined. You cannot expect (x == undefined) to return true. It would result in exception, in fact. You can only safely make a value undefined if you guarantee it won't be used.

cachemoney 15y ago

An alternative is an option type. In scala, you have the abstract type Option[T], which has implementations Some[T](value: T) and None[T]. Alternately, you have Either[A, B], with implementations Left[A](value: A), and Right[B](value: B). So you can define a function that takes an Either[Int, ErrorMessage], rather than an Int or null. Getting a None[Int] is better than null, because it won't throw NullPointerExceptions if you access it sensibly. Examples: def x2or0(i: Option[Int]): Int = i.getOrElse(0) * 2 def x2(i: Option[Int]): Option[Int] = i.map(_ * 2) def x2danger(iOrPossiblyNull: Int) = i * 2 // throws NullPointerException on null input

rayiner 15y ago

The responses below are an adequate summary of what would be the case if a statically typed language (Haskell, ML) featured nullable types. However, they're all largely inapposite for Dart. Dart's type system can't even ensure, at compile-time, that you'll never see an integer in a variable typed as a string. It can catch a lot of such cases, but it's fundamentally a dynamically-typed language and can't make really any guarantees at all statically. So non-nullable types in Dart would be a fiction. Any object typed anything might end up being null at runtime.

ericbb 15y ago
I haven't read much at all about Dart yet so forgive me if I'm missing something but it seems to me that dynamic-typing capabilities do not rule out absence-of-null. Doesn't Dart's use of optional typing mean that it really behaves as a statically-typed language in some contexts? The Go language sort of has this via interface types. Consider the following: type Foo struct { a, b int } func Bar(x interface{}) Foo { if f, ok := x.(Foo); ok { return f // x is a Foo at runtime so return it } return Foo{0, 1} } There is no need for the Foo type to have a null value. Go does have general zero-values for all types but that's somewhat different from null and not the only solution either. I think a Haskell-like model (neither null nor zero-value) could also work.
- rayiner 15y ago
  Dart never really behaves like a statically-typed language. Take this code: http://try-dart-lang.appspot.com/s/bA0X http://try-dart-lang.appspot.com/s/bA0X It not only doesn't give an error, but it runs just fine. main() passes "cake" to bar(), which passes "cake3" to foo(), because String overloads the + operator to coerce its RHS to a string before concatenating. foo() ends up receiving a string despite being declared as receiving a number, but does what one would expect because '+' is defined for strings as well as numbers. The compiler does not complain because it does not try to unify types globally. It does not care that bar(), which is declared as taking any type then passes that to foo() which is declared as taking a number. If you change the 'var' in the declaration of bar() to 'num' you will indeed get a type error in main() when it tries to pass bar() a string. So making types non-nullable in Dart would have little utility. Dart can't statically ensure that a variable declared as 'num' doesn't end up being a 'String' at run time, much less ensure that a variable is non-null. I don't see this as a weakness of Dart. The point of Dart's optional types is to enforce some structure, provide documentation, and avoid obvious mistakes in an otherwise dynamically typed language. Statically enforcing invariants like non-nulity is really beyond its scope.

azakai 15y ago

> The user neelk states that one of the bad things about the language is "Null. In 2011." Can someone clarify for me why having null in a language is bad (other than how dereferencing/calling-a-method on null in most languages results in your program crashing)? That right there is the reason. Those crashes are a huge burden on the software industry, it's even been called the "billion dollar mistake", http://lambda-the-ultimate.org/node/3186 http://lambda-the-ultimate.org/node/3186 And of course it is possible to have references which cannot be null, for example, even C++ has this: References as opposed to pointers. Many new languages have adopted the non-null approach, off the top of my head, Rust.

bartwe 15y ago

Compiletime enforcement that a reference isn't null in a language like java is very powerfull, more useful then c++ const in my opinion.