Daniel Martin

So here's a bit of a geeky post, but not so terribly geeky that I'm hiding the bulk behind a cut link.

"true" and "false" are simple concepts, right? Different programming languages seem to have hugely different ideas of what they are:

In C, 0 is false, any other integer is true, and the coercion rules make a null pointer false, and any other pointer true. Anything else is a compile error.

C++ follows (inherits?) the C rule, and adds true and false as things that are true and false.

In shell, 0 is a true exit value; any other exit value is false. Inside [ ], empty strings are false and other strings (such as "0" or "1") are true.

In Python, 0, 0.0, -0.0, False, None, the empty string, empty tuples, lists, and dicts are all false. Anything else (such as the string '0') is true. (A note on 0.0 vs -0.0: they're both == according to python, and both false, but print differently. One can be turned into the other by multiplying by -1)

In Perl, 0, the empty string, and undef are false, and since evaluation as a boolean imposes scalar context, an empty array or hash variable is also false. Anything else (including arrayref or hashref values to empty structures) is true. Note that because perl helpfully autoconverts like a $SOME_NOUN_HERE, the string "0" and 0.0 are to perl identical to 0, and therefore false. (hence the Perl idiom "0 but true") A full discussion of the quirks of perl around various representations of zero could probably fill a small book, but I'll note that other consequences are that the expression -0 is true, but -0.0 is false.

In Ruby, false and nil are false, anything else (including 0, the empty string, and an empty Array or Hash) is true.

In Javascript, 0, null, undefined, the empty string, false and NaN are false. Anything else (such as an empty Array, or empty Object) is true.

In Java, (since the autoboxing introduced in Java 1.5) true and Boolean.TRUE are true, false and Boolean.FALSE are false, ((Boolean) null) is a runtime exception, and anything else is a compile error.

In Haskell, True is true, False is false, and anything else is a compile error.

Google Go behaves like Java 1.4 or Haskell - true is true, false is false and anything else is a compile error.

Scala appears to behave the same way - true is true and false is false. Anything else (including an instance of RichBoolean, or of java.lang.Boolean) is a compile error.

In Common Lisp, nil, aka the empty list, is false. Anything else - including 0, the empty string or empty vectors of other types - is true.

Edge cases are hard. Off-by-one errors are painful. (see also page 25 of this pdf)

Why, then, do programmers seem to delight in creating edge cases for themselves?

I remember as an undergrad. helping out in the CS lab at Carleton. One of the first very painful assignments for people in the second CS course in our CS sequence involved making and using singly linked lists. Thorny edge cases all over the place, and with pointers too.

Now, there are some edge cases here, but not nearly as many as people think, if they simply use slightly different variables.

( C singly-linked-list digression )

Maybe special cases are the kind of thing that creeps up on you - it's easy to do just one, but soon you end up with a dozen tricky edge cases because adding each one was easier than re-thinking your algorithm. However, I often find that special cases are added in preference to using a few extra variables, or allocating a little bit more memory.

I'm thinking about this because I recently dealt with someone at work being burried under special cases. The specific problem has been simplified; I'll include it in an lj-cut below. When he called me, he'd just gotten through trying to work out how to handle all his different test cases, which were ending up in at least four tricky edge cases, and several flag variables that he was having trouble keeping separate. In fact, I was able to simplify the main loop to have just three if statements (none nested), and two of those if statements were identical.
( Fun with text manipulation in perl )

This weekend, I went through and updated the software on my machine, including getting a new release of the modem driver for my computer from intel's website. You can see where this is going, right?

Well, the driver update caused ppp to stop working. After seeing the problem occur a few times a vague memory of finding and fixing this problem with the old modem driver software began to surface. Unfortunately, I'd already completely wiped out all copies of the old driver, so I had to figure out from scratch how to fix this.

This time, I'm documenting in LiveJournal how I got my stupid cheap no-brand modem (but based intel's 536ep chipset) to behave with ppp in linux. Next time I forget and accidentally wipe out the fixed version, I'll just look back at my livejournal and say "ah, that was how I did it."

( source code diving )
| |