4 ms·

null

23 points by vladev 17y ago

chanux 17y ago
Null is an element of any given set. So it's natural enough. Maybe the way we human use it in implementations is wrong. But after all Null is defined by human anyway. "...And you, as a consumer of that method, need to check every time if the return value is Null. If you don’t – you (usually) get a Null pointer exception and your program crashes." Can't this be handled by the language itself, by default?
- vladev 17y ago
  "Can't this be handled by the language itself, by default?" - yes - languages do that check, but it's done at runtime and if it fails - you get an exception.
- limmeau 17y ago
  Null is an element of any given set? I'm not sure I understand you there. Do you mean that e.g. "the absence of a natural number" is a member of the set of natural numbers?
  - chanux 17y ago
    Yeah I was talking about the Null found in math. It makes me feel that 'Null everywhere' natural & we can use in our implementations safely.
    - limmeau 17y ago
      But there's an important difference: 0 is still a number and can safely be added to other numbers, "" is a string which can safely be concatenated with other strings. Java null, however, does not denote a neutral value, it denotes an absence of value, a hole in the paper where a value should be. In fact, if a type has a neutral element on the conceptual level (like 0 or the empty string or the /dev/null logger), then the null-object pattern is applicable and we can return NullObjects instead of null references, so null references are superfluous. If the type has no conceptual neutral element, however, the null reference doesn't relate to a meaningful entity on the conceptual level, either. (Medusa cars which kill you if you try to read the license plate are an obvious exception)
- pmjordan 17y ago
  Can't this be handled by the language itself, by default? The problem with this is that nobody has come up with a sensible universal default other than crashing in some form or another. I doubt there is one. Static typing is just an attempt at failing earlier (at compile time, not runtime). An example of non-crashing null behaviour: embedded systems without virtual memory where 0x0 is a valid memory address. Dereferencing/jumping to 0x0 makes your code carry on as normal. Hilarity ensues.
  - stcredzero 17y ago
    Smalltalk, in normal operation, never crashes when an unexpected nil is encountered. An exception is thrown, but this is actually just more bog-standard Smalltalk code running normally. (You can get a hard crash if you're doing something out of the ordinary, like calling out to a DLL. One "out of the ordinary" snippet that I like: "Semaphore allInstances do: [ :each | each release]") If you had an OO language mandating a Missing version of every type you define, then you can guarantee that you will fail at compile time. This has a better granularity than requiring the programmer to catch exceptions. The compiler can tell you which methods you need to implement, and the IDE could even scaffold them for you!
- ovi256 17y ago
  I propose eliminating Null/None all together. Simply do not allow a pointer to be initialized to none, but require it to point to an object. The object should not be collected as long as the pointer is valid. Just throw exceptions if you need to, and handle those. Semantically, exceptions and special null values are the same - they let you know something went wrong. However, I think that null values are a syntactic oddity much like a vestigial limb now that we have exceptions.
  - limmeau 17y ago
    What do you suggest as a replacement for nullable fields?
    - ovi256 17y ago
      Ouch, forgot that. Well, I guess the database could use Null values internally, but they should be translated into exceptions as soon as possible - as in, throw a NullFieldException if the field is accessed. However, checking for these all the time would be just as wasteful as checking for null values. I now see the advantages of the monad way.
  - stcredzero 17y ago
    In a statically typed OO language, why not have an implicitly created MissingObject? Whenever you define a class Foo, you automatically get MissingFoo for which you must define any methods that Foo understands.
- jrockway 17y ago
  Can't this be handled by the language itself, by default? Of course; most sane languages require an explicit annotation to say that an object can be null. If it's not that type, there is simply no way to create an object that is null. (Haskell is an example of a langauge like this; no objects can be null. Maybe and Either build on top of this system to provide a well-defined approximation of null.)
pmjordan 17y ago
Okay, I realise this is probably a naïve question, but it hasn't been answered by any of the anti-null articles. Usually, null as a return value has some kind of special meaning, like indicating a failure or other edge case. Making null go away doesn't mean that case can't happen, you just need to handle it differently. The example in the article String com = tld("example").getOrElse("unknown"); is one of those lovely academic examples which is completely out of touch with reality. Unless you're doing nothing but displaying it to the user, the string "unknown" is just as bad as the null object in almost every way, and worse in others: there's a reasonable chance that "unknown" will one day be a valid TLD. So the proposed solution with the Option<> generic type really is just a reminder to the programmer. There's no technical advantage. You might even see a decrease in performance if the compiler can't optimise it away. Except we already have a reminder mechanism: checked exceptions. Remember those? Remember how popular they are? C# actually has this concept of nullable types. It doesn't apply to class types which are always nullable, but structs (with mostly value semantics as opposed to identity semantics) can be either nullable or not - just like C/C++'s passing by value I suppose. Except they're so unwieldy to use due to the OMG IT MIGHT BE NULL paranoia (you can't do anything as ridiculous as access a member without unboxing... which will throw a NullPointerException if null - score!), you may as well redefine your struct as a class and use that. (which breaks cases where you didn't want it nullable. score 2!) I won't even treat C++ references (&) as a realistic attempt at a non-nullable type system because safety and C++ don't go together anyway. [1] I've not used scala, so if someone has a good, realistic example of code where scala's non-null system works well, I'd love to see it. I guess I have to add that I actually liked static typing for a long time (I've done my stereotypical 10000 hours of C++), until I noticed I was just slowing myself down and my code in dynamic languages wasn't any worse, just quicker/easier to modify. Is this a sign of programming maturity? Is static typing the "training wheel" mechanism for beginning programmers? I'm starting to think so. [1] void bar(Foo& f); Foo* p = 0; bar(*p);
- vladev 17y ago
  I agree, the example with the tld part wasn't the best - maybe an url schema (http part) would have been much better. "So the proposed solution with the Option<> generic type really is just a reminder to the programmer." - exactly. But a good program is a program that works, so we need to achieve that first. :)
limmeau 17y ago
I agree with the author that having an option datatype makes the intention "this method returns some Foo or nothing" clear. However, the suggested encoding of an option type in Java blends poorly with subtyping because a JOption<MySubtype> is not a subtype of JOption<MySupertype>. For a quick optional-return scenario, it may work, but as a substitute for nulls in optional parameters, you'd have to remember the precise type of every parameter and create non-empty JOption instances in a rather verbose way. As an alternative, you could use a tool like Findbugs and its @Nullable annotation.
- vladev 17y ago
  In Scala's type system that can be expresses as well - it's called type variance. I believe C#4.0 might be getting this.
  - limmeau 17y ago
    In C#4.0, apparently you can declare JOption as interface NOption<out T> { ... } such that NOption<Mysub> is a subtype of NOption<Mysuper>. Still messy to read, though, and C# has ?-types anyway.
sovande 17y ago
So what happens if I call the new improved method tld with a null argument? Yep, a NullPointerException raised by lastIndexOf.

23 points by vladev 17y ago

Null is an element of any given set. So it's natural enough. Maybe the way we human use it in implementations is wrong. But after all Null is defined by human anyway. "...And you, as a consumer of that method, need to check every time if the return value is Null. If you don’t – you (usually) get a Null pointer exception and your program crashes." Can't this be handled by the language itself, by default?

vladev 17y ago
"Can't this be handled by the language itself, by default?" - yes - languages do that check, but it's done at runtime and if it fails - you get an exception.
limmeau 17y ago
Null is an element of any given set? I'm not sure I understand you there. Do you mean that e.g. "the absence of a natural number" is a member of the set of natural numbers?
- chanux 17y ago
  Yeah I was talking about the Null found in math. It makes me feel that 'Null everywhere' natural & we can use in our implementations safely.
  - limmeau 17y ago
    But there's an important difference: 0 is still a number and can safely be added to other numbers, "" is a string which can safely be concatenated with other strings. Java null, however, does not denote a neutral value, it denotes an absence of value, a hole in the paper where a value should be. In fact, if a type has a neutral element on the conceptual level (like 0 or the empty string or the /dev/null logger), then the null-object pattern is applicable and we can return NullObjects instead of null references, so null references are superfluous. If the type has no conceptual neutral element, however, the null reference doesn't relate to a meaningful entity on the conceptual level, either. (Medusa cars which kill you if you try to read the license plate are an obvious exception)
pmjordan 17y ago
Can't this be handled by the language itself, by default? The problem with this is that nobody has come up with a sensible universal default other than crashing in some form or another. I doubt there is one. Static typing is just an attempt at failing earlier (at compile time, not runtime). An example of non-crashing null behaviour: embedded systems without virtual memory where 0x0 is a valid memory address. Dereferencing/jumping to 0x0 makes your code carry on as normal. Hilarity ensues.
- stcredzero 17y ago
  Smalltalk, in normal operation, never crashes when an unexpected nil is encountered. An exception is thrown, but this is actually just more bog-standard Smalltalk code running normally. (You can get a hard crash if you're doing something out of the ordinary, like calling out to a DLL. One "out of the ordinary" snippet that I like: "Semaphore allInstances do: [ :each | each release]") If you had an OO language mandating a Missing version of every type you define, then you can guarantee that you will fail at compile time. This has a better granularity than requiring the programmer to catch exceptions. The compiler can tell you which methods you need to implement, and the IDE could even scaffold them for you!
ovi256 17y ago
I propose eliminating Null/None all together. Simply do not allow a pointer to be initialized to none, but require it to point to an object. The object should not be collected as long as the pointer is valid. Just throw exceptions if you need to, and handle those. Semantically, exceptions and special null values are the same - they let you know something went wrong. However, I think that null values are a syntactic oddity much like a vestigial limb now that we have exceptions.
- limmeau 17y ago
  What do you suggest as a replacement for nullable fields?
  - ovi256 17y ago
    Ouch, forgot that. Well, I guess the database could use Null values internally, but they should be translated into exceptions as soon as possible - as in, throw a NullFieldException if the field is accessed. However, checking for these all the time would be just as wasteful as checking for null values. I now see the advantages of the monad way.
- stcredzero 17y ago
  In a statically typed OO language, why not have an implicitly created MissingObject? Whenever you define a class Foo, you automatically get MissingFoo for which you must define any methods that Foo understands.
jrockway 17y ago
Can't this be handled by the language itself, by default? Of course; most sane languages require an explicit annotation to say that an object can be null. If it's not that type, there is simply no way to create an object that is null. (Haskell is an example of a langauge like this; no objects can be null. Maybe and Either build on top of this system to provide a well-defined approximation of null.)

pmjordan 17y ago

Okay, I realise this is probably a naïve question, but it hasn't been answered by any of the anti-null articles. Usually, null as a return value has some kind of special meaning, like indicating a failure or other edge case. Making null go away doesn't mean that case can't happen, you just need to handle it differently. The example in the article String com = tld("example").getOrElse("unknown"); is one of those lovely academic examples which is completely out of touch with reality. Unless you're doing nothing but displaying it to the user, the string "unknown" is just as bad as the null object in almost every way, and worse in others: there's a reasonable chance that "unknown" will one day be a valid TLD. So the proposed solution with the Option<> generic type really is just a reminder to the programmer. There's no technical advantage. You might even see a decrease in performance if the compiler can't optimise it away. Except we already have a reminder mechanism: checked exceptions. Remember those? Remember how popular they are? C# actually has this concept of nullable types. It doesn't apply to class types which are always nullable, but structs (with mostly value semantics as opposed to identity semantics) can be either nullable or not - just like C/C++'s passing by value I suppose. Except they're so unwieldy to use due to the OMG IT MIGHT BE NULL paranoia (you can't do anything as ridiculous as access a member without unboxing... which will throw a NullPointerException if null - score!), you may as well redefine your struct as a class and use that. (which breaks cases where you didn't want it nullable. score 2!) I won't even treat C++ references (&) as a realistic attempt at a non-nullable type system because safety and C++ don't go together anyway. [1] I've not used scala, so if someone has a good, realistic example of code where scala's non-null system works well, I'd love to see it. I guess I have to add that I actually liked static typing for a long time (I've done my stereotypical 10000 hours of C++), until I noticed I was just slowing myself down and my code in dynamic languages wasn't any worse, just quicker/easier to modify. Is this a sign of programming maturity? Is static typing the "training wheel" mechanism for beginning programmers? I'm starting to think so. [1] void bar(Foo& f); Foo* p = 0; bar(*p);

vladev 17y ago
I agree, the example with the tld part wasn't the best - maybe an url schema (http part) would have been much better. "So the proposed solution with the Option<> generic type really is just a reminder to the programmer." - exactly. But a good program is a program that works, so we need to achieve that first. :)

limmeau 17y ago

I agree with the author that having an option datatype makes the intention "this method returns some Foo or nothing" clear. However, the suggested encoding of an option type in Java blends poorly with subtyping because a JOption<MySubtype> is not a subtype of JOption<MySupertype>. For a quick optional-return scenario, it may work, but as a substitute for nulls in optional parameters, you'd have to remember the precise type of every parameter and create non-empty JOption instances in a rather verbose way. As an alternative, you could use a tool like Findbugs and its @Nullable annotation.

vladev 17y ago
In Scala's type system that can be expresses as well - it's called type variance. I believe C#4.0 might be getting this.
- limmeau 17y ago
  In C#4.0, apparently you can declare JOption as interface NOption<out T> { ... } such that NOption<Mysub> is a subtype of NOption<Mysuper>. Still messy to read, though, and C# has ?-types anyway.

sovande 17y ago

So what happens if I call the new improved method tld with a null argument? Yep, a NullPointerException raised by lastIndexOf.