4 ms·

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 a

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

by chanux 17y ago

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