patrick dewane gathers wool

Dear Null - Feedback

Wow, almost 5,000 hits and still going strong. I appreciate the feedback, which has surpassed my expectations of none. Page views down this dark alley usually hover around two or three a day, so I'm still not sure whether or not to file a bug report with TypePad (perhaps they forgot to carry the 0).

Anyway, I wanted to take some time to address some comments I've read here.

Missed the point

For those of you who missed the point of the article, let's try this one more time.

A predicate modifies a subject. Check. A predicate asserts some truth about the subject. Check. Without a subject, a predicate has nothing to modify. QED.

Or for you more manly programmers (this is just a joke, keep reading), how about a CFG:

Sentence  => Subject Predicate
Subject    =>  Shirt | NULL
Predicate =>  is blue

Those are your productions. Your non-terminals are bolded and your terminals are not. The language defined by that CFG yields the sentence:

"is blue."

Throw that sentence out in casual conversation.

What I thought was an obvious point went over the heads of most readers. I have to assume I did a terrible job explaining myself. So here is an equation to help:

NULL + Boolean = ambiguity

Now I cannot speak for you, but I have a hard time finding a place for ambiguity at my dinner table of logic. If we modify a null subject with a predicate, we assert some truth that carries ambiguity because the assertion carries an implication regarding the subject. In our blue shirt example we yield false when the shirt is not blue and when we do not have a shirt to modify. This is ambiguity.

Really missed the point

Quite a few comments were made regarding my desire to banish NULL from the universe. I'm not sure what post you were reading, but it surely was not mine.

I stumbled upon this noteworthy comment:

"'NULL makes things messy get rid of null'".

That comment was made as a summary of my post, and what a terrible summary it was! Shame on you.

Funny on accident

Here is my favorite comment by far:

"What happened to programmers being real men? I'm talking about doing things like allocating and freeing memory, doing pointer arithmetic and using multiply linked lists, all before a hearty breakfast of steak, vodka and cigars.

Now, coddled by managed code, generics and closures, we see febrile man-children wetting their pants about something as simple as nulls. Man up for fuck's sake."

Now that is funny! Let's pick this one apart:

1. "What happened to programmers being real men?". What happened to insightful input. As a general rule of thumb, if the first sentence of a comment is an ad-hominem attack then the commenter is more than likely a real man, perhaps even one that wears Old Spice and eats deep fried bacon.
2. "I'm talking about doing things like allocating and freeing memory, doing pointer arithmetic and using multiply linked lists...". Now I know this is a real man! One that throws abstraction and grammar to the wind!
3. "Now, coddled by managed code, generics and closures...". Wow, just wow.
4. "...wetting their pants about something as simple as nulls. Man up for fuck's sake.". Sexism aside, would you mind helping me change my pants?

Monads

I came across several comments suggesting that the venerable Maybe Monad (nullable value type) would solve this particular problem. While it does solve this particular problem, let’s not lose sight of the actual problem.

A nullable Boolean would certainly remove any ambiguity, essentially giving us the third Boolean value “I don’t know”. So now we are asserting the fact that we do not have a subject to modify, which is the actual problem. It may sound like we’re getting closer, but we’re not.

What are our choices for dealing with this new Boolean value? Well I suppose it depends on the context of the program. Perhaps it is OK and we can continue on our merry way. Imagine a customer wanting to purchase blue shirts. The customer applies some type of filter, and this filter removes non-blue shirts.  A non-existent shirt is not blue, so the filter gladly ignores it. We then return all blue shirts and our customer is happy.

But now imagine our customer wants to purchase every non-blue shirt and we use the same filter. Every time our filter returns false, we sell that shirt to our customer. Uh oh. We will attempt to sell a NULL shirt to our customer, which would more than likely result in an exception somewhere down the line.

Remember, our problem is not that the Boolean type is insufficient. So why amplify it? (I’m not making a case against nullable types, I’m just making an observation).

Ignoring the problem

I was surprised to see how many “solutions” were presented which did not directly address the problem. Rather, many solutions targeted the Boolean type as not being meaningful enough.

Perhaps my sense of humor is senseless, but I find all this rather amusing. Look around at all the abstraction and complication we create to deal with such a basic issue. I’m not saying this abstraction and complication is not necessary. I just find humor in our ability to complicate.

Actual insightful commenters

Imagine how happy I was to find how many other programmers saw the problem, laughed a bit, and got involved in meaningful discussions. Thank you to those people, you’ve most definitely taught me a few things.

Would a non-issue has sparked such a debate? I would like to think not, but I am biased.

Wrapping up

I wrote "Dear NULL" in literally an hour. I stumbled upon a block of code that looked very similar to the one posted in that article, and it just made me stop and think for a moment. After thinking about it, it made me laugh a bit.

There are countless ways to deal with NULL, and each language offers new and enlightening abstractions to push the problem further away from its realization.

Monads are an option, namely the Maybe monad. Contracts could work. A change of perspective and/or changing the name of function could help. Building a JK flip-flop with some spare gates and doing some other manly shit would probably just make me wet my pants.

I merely found a block of code that made me giggle.

Dear NULL

UPDATE!

Due to the amount and breadth of feedback I’ve received regarding this post, I had to write a follow-up to clear the air a bit. After reading this post, continue over to meta-Dear NULL.

To not be or not not to be

This is a quick post, I promise this will not take long.

Dear NULL,

You’ve certainly made a mess of things, haven’t you?

I would like to know what you really are, but then again, you really aren’t anything. And at the same time, you’re comparable to anything.

Show a little existentialism and do something with yourself.

Sincerely,

Everyone

I find it funny, in a tragic comedic sense, that we must study the semantics of a missing value and how it interacts with an actual value. Although irrelevant for this post, what I find even more funny is when mathematics (such as category theory) provides type constructors for missing values. As if we could actually amplify nothing!

Please note that I am not making a case against NULL, I’m just making some observations.

Well anyways, here is what I stumbled on today that sparked this post:

bool IsShirtBlue(Shirt s)
{
    return s != null && s.ShirtColor == Shirt.Color.Blue;
}

(I’ve replaced type names to protect myself the innocent)

Given a shirt, I will tell you if it is blue as long as I’ve been given a shirt. Hmmm.

Obviously if the function returns true, you have a blue shirt. What if this function returns false? In that case, your shirt is not blue. Or you do not have a shirt, therefore it cannot possibly be blue. Well which one is it?

Are you laughing yet? If not, answer this question:

Does bigfoot wear a size 32 men's shoe?

If you’re still not laughing, please remember that you must provide a Yes/No answer and either answer carries the implication that bigfoot does exist.

The general problem is that predicates work on subjects. In this example, the subject is Shirt and the predicate is Blue. On the surface it appears we always have a subject, but we do not. We simply have a reference to what could be a shirt. Our subject may not exist, therefore the predicate has nothing to modify (modify here is being used in a grammatical sense).

You might think I’m making a bigger deal out of this than it really is. You might be right. But that does not change the fact that NULL is nothing and anything at the same time. This is a paradox, and one that at least deserves some scrutiny.

The NULL anti-pattern

At this time I would like to introduce the NULL anti-pattern. It is quite simple really, is in the shape of a function, and it look something like this:

bool PredicateRegardingArgument (object p)
{
    return p != null && Predicate(p);
}

There are three ingredients in this anti-pattern:

1. The function returns a Boolean value.
2. The function has some parameter, p, comparable to NULL.
3. The function tests some instance value of p.

The reason I call this an anti-pattern is because the function makes no distinction between an argument exhibiting some behavior and the argument having a value that can exhibit the behavior. In other words, our predicate may not have a subject to modify.

It is not difficult to imagine a more dangerous scenario:

bool IsFileInUse(string path)
{
    return path != null && blah blah blah
}

(this is just arbitrary code)

When this function returns true it means the file is in use, and therefore must exist. But what does it mean if the function returns false? A file that exists might not be in use. But does a file that does not exist exhibit any type of interaction with its environment? I think not.

You could argue that we might simply skew our perspective a bit and accept the fact that a single Boolean value might carry more meaning than simply true or false. That’s too shallow an argument however and certainly is not a solution.

We could fix this problem by introducing another Boolean value, which I will call NULL. Ha, I crack myself up sometimes.

There are two reasonable solutions to this problem, perhaps more. Both solutions are quite obvious and you’ve more than likely thought of them already. The first is a simple exception:

bool IsShirtBlue (Shirt s)
{
    if (s == null)
    {
        throw new ArgumentNullException("s");
   }
    // arbitrary

}

The second is an instance method:

class Shirt
{
    bool IsShirtBlue()
    {
        // arbitrary

    }
}

I never said this was going to be complicated.

A mountain out of a molehill

I have to imagine that bugs exist due to the NULL anti-pattern. This may be especially true in organization which routinely use multiple languages since there is not much consistency regarding how different languages treat NULL. If you know SQL, you know what I mean.

I might just be at the bottom of the molehill.