A better comparison here is with C/C++/go, e.g. other languages that are designed to be fast and compiled.

In any of those, dereferencing a null pointer is undefined. The compiler can literally emit code that plays Nethack in this situation [0]. ObjC's "nothing will happen" behavior is a significant improvement in safety against similarly-situated languages.

[0] http://feross.org/gcc-ownage/

You're incorrect about Go. It's in the spec that derefing a nil pointer will cause a runtime panic (~ an exception).

http://golang.org/ref/spec#Address_operators

I stand corrected.

Not defending "undefined" here, at all. I'd rather see the definition be, at least, exit(0xff) (or some other mechanism that reliably denotes "method not found", "message not found", etc).

I'm pretty sure I'm on record in HN for ranting about the fact that C & C++'s undefined & funny behavior literally created multimillion dollar industries in building analysis tools to cove their gaping problems. Which is why I am tend to boost Rust when possible (designed for correctness and determinism! woo!).

Dropping errors is not IMO better or worse. Both are silent failure modes.

I find it far more convenient to type something like

    NSArray *a = [self somethingThatProducesAnArray];

    if (a.count > 0) {
      // do something
    }
    else {
      // do something else
    }

than

    NSArray *a = [self somethingThatProducesAnArray];

    if (a && a.count > 0) {
      // do something
    }
    else {
      // do something else
    }

Well, first, you aren't calling a method, you are sending a message. It's different. So, of course, sending a message to somebody that isn't home is going to yield you an empty response.

Again, message, not method.

Er... I would hope that I get some sort of Not At This Address notification (in some fashion - exception, special return value, option type, etc, etc, etc.). Dropping the ball like that by default is really not helpful in building correct systems.