Technovangelism

When designing a programming language what should evaluate to false? Why not make life easy and only allow the boolean value false to evaluate to false like C#. Or why not make developers write less code by allowing null, 0, and empty lists to evaluate to false? The latter seems like a useful rule because it should allow the developer to save time by writing significantly less code, and less code is always a good thing, right? Why write if (list.Count > 0) when you could just write if (list) ?

I have often been confused by ruby’s decision to evaluate nil as false. Mostly because all objects have the method nil? which allows for a much faster to check then writing if (obj == nil) but of course much slower than writing if (obj). When all objects have the nil? method, why not trade the four extra keystrokes for a little more verbosity to make expressions that much clearer? When I write ruby, I prefer the use of the nil? method to evaluate whether an object is nil. And thanks to the unless conditional, I don’t even have to use the bang operator when I want to know when an object is not nil. This amount of immediate readability might be a little extreme, but I have found it quite helpful.

When do the benefits of saving developer time outweigh the problems caused by lack of verbosity? When you multiply the number of keystrokes saved per expression, by the millions of times if statements and while loops are written every day, a significant amount of time is saved when more things evaluate to false. But what about the amount of developer time that is wasted trying to determine exactly what is supposed to be evaluated? When is it truly worth it to make a developer’s life easier and how can one measure this?