What is wrong with NULL

Post by paulddraper » Tue, Sep 01, 2015, 12:05 AM UTC

bcheung wrote: post #97

Here is what is wrong with Option. option.ifPresent(x -> System.out.println(x)); So instead of just checking to see if it is NULL you want me to create an instance of a specialized class that holds my variable that has a method that acts like an "if" statement that I need to pass an anonymous function to that receives the value I already have? Why not just do: x && System.out.println(x) or: System.out.println(x) if x…

Post by paulddraper » Tue, Sep 01, 2015, 12:10 AM UTC

paulddraper wrote: post #60

kinghajj wrote: post #7

Earlier quoted context omitted.

Rust, too! Edit: Btw, I disagree with how the article categorizes Rust in comparison to Haskell. It shows that Rust has std::ptr::null, but neglects the fact that Haskell has Foreign.Ptr.nullPtr. Either both should be "5 stars" or both should be "4 stars".

Author here. I didn't know that about Haskell. Admittedly, the "rating" is pretty rough, maybe even a bad idea. I've seen std::ptr::null more than I ever have Foreign.Ptr.nullPtr. But really, both are usually used for compatibility with external libraries/programs/runtimes, not for idiomatic language programming. Both great languages in my book :)

Post by bcheung » Tue, Sep 01, 2015, 12:20 AM UTC

paulddraper wrote: post #119

bcheung wrote: post #112

Earlier quoted context omitted.

Composability comes from functions, macros, and inheritance. What does that have to do with types? "In fact, composibility is really the fundamental issue behind many of these problems. For example, the Store API returning nil for non-existant values was not composable with storing nil for non-existant phone numbers." That's only because you invented some abstraction that got in your way in the first place. NULL is a…

This is not contrived. (1) A cache returns something or NULL. It's generic; i.e. implementation doesn't care what it is storing: integers, strings, etc. (2) A particular value of interest may be NULL or non-NULL. But now I can no longer use my generic cache and my values of interest together. A very real example of this is Java's Map interface. It's completely up to implementation on how they handle null, making inte…

  cache = {}
  getFromCache = (key) ->
    return cache[key] if cache[key]?
    throw "not found"
  
  doSomethingWithValue = (key) ->
    try
      value = getFromCache(key)
    catch
      value = getValueFromNonCache(key)
    return _doSomethingWith(value)

Post by kazinator » Tue, Sep 01, 2015, 1:05 AM UTC

paulddraper wrote: post #13

kazinator wrote: post #2

The mistake is an unsafe null: making every object type carry a value in its domain which says "Oops, though my type says I'm a Foobar, I'm not actually an object, la la la! Have a free exception on me, in your face!" Lisp's NIL is brilliant. It's in its own type, the null type! And it's the only instance of that type. No other type has a null instance. Null references in the language simply reflect the tension betwe…

NIL is fine ... as long as you have some container for the opposite. There should be a way to express Maybe >, aka an optional optional value. The Store article in the article is an example of when this would be needed: a cache optionally has an optional phone number for a person. If Lisp has the equivalent of Maybe > (perhaps a singleton list of a singleton list?), then the optionality is composable. Otherwise, the…

Post by lambda » Tue, Sep 01, 2015, 2:48 AM UTC

bjz_ wrote: post #98

lambda wrote: post #57

Earlier quoted context omitted.

Came here to say this. In fact, I think every language that they give 5 stars to has some form of "foreign pointer", "raw pointer", "unsafe pointer" or the like that is nullable, for FFI and other low level tasks. I think that anything which has no null in normal, idiomatic code, outside of "unsafe", "ffi", or similar subsets, should get 5 stars. The distinction is really about whether you need to worry about any pos…

> Likewise, I think that in Scala and Swift, null is only present for compatibility purposes, and idiomatic code does not use them. I'm not sure about F#. I believe though that with the exception of Swift, null can infect these language's quite easily via the FFI, and the guarantees aren't as strong. I haven't used them much though, so I could be wrong.