4 ms·

Keep in mind that Tony Hoare, the inventor of the null pointer, calls this invention his billion dollar mistake. I generally think that he is right and use of n

by harryh 11y ago

Keep in mind that Tony Hoare, the inventor of the null pointer, calls this invention his billion dollar mistake. I generally think that he is right and use of null should almost always be avoided.

agumonkey 11y ago
In other paradigms (Lisps) null is a lot less than a billion dollar mistake, it seems it goes better with map/filter/fmap patterns. In imperative languages, data is tied to control, and null means segfault.
- Peaker 11y ago
  When some ELisp code crashes in my emacs with an error like: error: (stringp nil): not a string I think it indicates Lisps suffer from this problem too...
  - agumonkey 11y ago
    It does, I said 'a lot less' not 'zero dollar mistake'. Recursively defined lists take care about nil, and since it's one of the most used ways to program in lisp it makes a lot of logic nullproof.
userbinator 11y ago
Despite what he says, I don't think Hoare actually invented the "null pointer", as address 0 for "not exists" or "end of list" was probably a common convention ever since linked structures existed and independently discovered by many others. (The other convention would be the all-bits-1 value, but I'd assume that testing for 0 was easier and thus more widely adopted. Also, "0 = nothing" makes great sense.) IMHO Optional just feels like another typical Java dogmatic overabstractionism. "Null pointer exception? So what? Just catch it." Then again, I mostly use C/Asm.
- harryh 11y ago
  Given that the Option type has existed in programming languages other than Java for decades I don't think it makes sense to call it a "typical Java" thing. I can see how a C/Asm programmer wouldn't like it though. Very different mindsets. :)
  - userbinator 11y ago
    The difference is that other languages which originally had the Option type don't have null, so it's the only option. I meant it's typical of Java to take features from other languages, resulting multiple slightly-different-but-incompatible ways to achieve the same thing.
    - harryh 11y ago
      I certainly agree that Java would be a much better language if NULL could be eliminated completely. Backwards compatibility though... sigh
- adevine 11y ago
  Yeah, Optionals came from other languages, not originally Java. IMO the problem with Optionals is that they'll never suffice unless they are part of the language itself, like in Swift. As this article pointed out, Optionals aren't supported in any existing APIs, so you still have to do a ton of null-checking everywhere. And there is nothing that guarantees an Optional reference itself can't be null, which is why you really want language-level support.
  - lomnakkus 11y ago
    I'm probably being a bit too pedantic here, but strictly speaking they don't need to be part of the language at all. You just need basic support for (generic/parametric) algebraic data types. For example, Haskell has Maybe which is not part of the language nor treated specially by the compiler in any way. It is part of the Prelude (think "standard library"), so that (basically) all libraries can agree on what "Maybe a" means.
asveikau 11y ago
By all means, have more clumsy, less straightforward ways to represent the lack of a value in your code, because Tony Hoare says so.
- Peaker 11y ago
  An Optional type is more clumsy than null checks and null returns sprinkled everywhere??
- harryh 11y ago
  The problem with NULL is that it can be there for literally any reference in your code. So, unless you are careful, you can get an NPE when calling any single object method. In languages without NULL this can never happen making them much easier to reason about.
  - cam- 11y ago
    A NullPointerException is unchecked as well. I would say about 40% of our code is checking for null to avoid NPEs especially with APIs. You have to protect yourself and cannot take nothing for granted.
  - asveikau 11y ago
    My initial reaction: programming ain't bean bag. Them's the breaks. Then I think of it and I see the real problem is languages making all nonprimitive types into pointers without being explicit. In a language like C it's more obvious what can be null.
    - harryh 11y ago
      If null can be problematic then certainly making it more obvious when you might have a null is a pretty good idea. I tend to think, however, that getting rid of null completely as a concept is even better. One less thing to worry about.
deleted 11y ago
[deleted]

by harryh 11y ago

Keep in mind that Tony Hoare, the inventor of the null pointer, calls this invention his billion dollar mistake. I generally think that he is right and use of null should almost always be avoided.

agumonkey 11y ago

In other paradigms (Lisps) null is a lot less than a billion dollar mistake, it seems it goes better with map/filter/fmap patterns. In imperative languages, data is tied to control, and null means segfault.

Peaker 11y ago
When some ELisp code crashes in my emacs with an error like: error: (stringp nil): not a string I think it indicates Lisps suffer from this problem too...
- agumonkey 11y ago
  It does, I said 'a lot less' not 'zero dollar mistake'. Recursively defined lists take care about nil, and since it's one of the most used ways to program in lisp it makes a lot of logic nullproof.

userbinator 11y ago

Despite what he says, I don't think Hoare actually invented the "null pointer", as address 0 for "not exists" or "end of list" was probably a common convention ever since linked structures existed and independently discovered by many others. (The other convention would be the all-bits-1 value, but I'd assume that testing for 0 was easier and thus more widely adopted. Also, "0 = nothing" makes great sense.) IMHO Optional just feels like another typical Java dogmatic overabstractionism. "Null pointer exception? So what? Just catch it." Then again, I mostly use C/Asm.

harryh 11y ago
Given that the Option type has existed in programming languages other than Java for decades I don't think it makes sense to call it a "typical Java" thing. I can see how a C/Asm programmer wouldn't like it though. Very different mindsets. :)
- userbinator 11y ago
  The difference is that other languages which originally had the Option type don't have null, so it's the only option. I meant it's typical of Java to take features from other languages, resulting multiple slightly-different-but-incompatible ways to achieve the same thing.
  - harryh 11y ago
    I certainly agree that Java would be a much better language if NULL could be eliminated completely. Backwards compatibility though... sigh
adevine 11y ago
Yeah, Optionals came from other languages, not originally Java. IMO the problem with Optionals is that they'll never suffice unless they are part of the language itself, like in Swift. As this article pointed out, Optionals aren't supported in any existing APIs, so you still have to do a ton of null-checking everywhere. And there is nothing that guarantees an Optional reference itself can't be null, which is why you really want language-level support.
- lomnakkus 11y ago
  I'm probably being a bit too pedantic here, but strictly speaking they don't need to be part of the language at all. You just need basic support for (generic/parametric) algebraic data types. For example, Haskell has Maybe which is not part of the language nor treated specially by the compiler in any way. It is part of the Prelude (think "standard library"), so that (basically) all libraries can agree on what "Maybe a" means.

asveikau 11y ago

By all means, have more clumsy, less straightforward ways to represent the lack of a value in your code, because Tony Hoare says so.

Peaker 11y ago
An Optional type is more clumsy than null checks and null returns sprinkled everywhere??
harryh 11y ago
The problem with NULL is that it can be there for literally any reference in your code. So, unless you are careful, you can get an NPE when calling any single object method. In languages without NULL this can never happen making them much easier to reason about.
- cam- 11y ago
  A NullPointerException is unchecked as well. I would say about 40% of our code is checking for null to avoid NPEs especially with APIs. You have to protect yourself and cannot take nothing for granted.
- asveikau 11y ago
  My initial reaction: programming ain't bean bag. Them's the breaks. Then I think of it and I see the real problem is languages making all nonprimitive types into pointers without being explicit. In a language like C it's more obvious what can be null.
  - harryh 11y ago
    If null can be problematic then certainly making it more obvious when you might have a null is a pretty good idea. I tend to think, however, that getting rid of null completely as a concept is even better. One less thing to worry about.

deleted 11y ago

[deleted]