Definitive answer to the message-eating nil argument
The message-eating nil is a built-in or optional feature of some programming languages that lets you ignore message execution on nil (or null) object. Objective-C does that. In SmallTalk, Ruby and some other languages you can add this behaviour in runtime.
Why is it useful: for instance, accessing person.address.street_name will simply yield nil if either person, address or street_name are nil. Another example is iterating nil instead of a list without checking if it is nil.
Some like message-eating nil because it saves a lot of boring code and helps avoiding some silly crashes. Others dislike the feature on the ground that it hides errors and makes it more difficult to reason about all the code paths.
However, here I present a definitive answer to the question whether your next programming language should or should not support message-eating nil.
Nil should be message-eating.
Here is why: when you switch from a language without message-eating nil to the language which has one, you only spend a week or two adapting to the new style and being puzzled from time to time where the hell the data is missing. After a longer period of time, you will change your style and find it useful and easy to program using this feature. But when you switch from such language to the one without message-eating nil, you will notice just how much useless if/then conditions are being added in your code. And when you forget adding one somewhere, you will get silly crashes in production code. Silly because you already know the nil would have been handled if it was allowed to be propagated.
Please, allow nil to eat messages.
PS. If you think of adding message eating to NilClass in Ruby, remember that metaprogramming can be dangerous.
