[dazmax]

The main problem I've seen with Objective-C is due to the fact that nil has truthiness, so this code is dangerous:

    if (input.isInvalid()) {
      reject()
    } else {
      accept()
    }

If input is accidentally nil, it's an invisible bug.

The other main complaint is when you have a long string of methods unexpectedly turn out nil at the end, it's a pain to figure out which one it was.

[uxp]

This is entirely incorrect.

nil is a pointer to the value 0, and in C there is only one value that evaluates to a logical false, which is 0. Invoking a method on nil returns 0. This itself alleviates the kind of nil-check-chains discussed in this thread:

    [[[user profile] name] isEqualToString:@"Paul"];

    [user profile] && [[user profile] name] && [[[user profile] name] isKindOf:NSString] && [[[user profile] name] isEqualToString:@"Paul"];

if user.profile.name is nil, then that expression evaluates to the value 0, which as we discovered, is the _only value that evaluates to false in C_

[cballard]

Huh?

    (int)nil == 0