Hacker News Reader

Comment by Udo | Hacker News Reader

I agree that the invokation idea is relatively wild, that's why I made it into a separate point. There are somewhat successful languages out there where sending a message to a null object doesn't do anything. If this is a class of bug that happens to you frequently, it's probably not for you. But once you get into the mindset that each method call is prepended by a virtual conditional, my hunch is you would know pretty quickly why your method isn't being called.

View on HN

I see this behavior as implicit error silencing.

Wouldn't you prefer seeing:

  foo .? bar . baz .? roo

To know that nil is not even a possibility for `bar`?

Why not make the nil check (or error silencing) explicit when it is so cheap to do so?

I already talked about my reasoning. But you are correct when you say this is a form of implicit error silencing. Dynamic languages usually have many features which could be described as implicit error silencing, and even statically typed ones often do. Implicit type conversions would be an example. You could very well argue any behavior that deviates from how the processor architecture handles data types and conditionals constitutes a silenced error of some kind. The question becomes where you personally draw the line.

Indeed I believe in Python's motto of "Errors should never pass silently. Unless explicitly silenced."

I think that Javascript's silencing of wrong parameter counts, Perl's (non-strict) allowing string concat, and non-well-founded implicit coercions (i.e: ones that change the semantics of the value) are all terribly horrible.

I believe that those who value convenience over safety deserve neither and will lose both.

> There are somewhat successful languages out there where sending a message to a null object doesn't do anything.

The reasons that is defensible in message passing systems is because such systems are basically recapitulations of computer networks, and object nullity is equivalent to a network partition. That's the kind of failure mode that you handle in the policy layer, which is above the runtime layer in an application system just as it would be above the network layer in a distributed system.

And most Objective-C (one of those languages) developers I've talked to about this would recall nightmares about that behaviour.

It's debatable whether this behavior was a good fit for Objective-C, since it's not actually a dynamically typed language. People reasonably expect their Obj-C compiler to do static checks and in this context dynamic behavior is an unwelcome surprise. It would be interesting if, for example, Smalltalk developers share the same frustration. My guess would be: probably not.

My go-to example in favor of the idea would be languages and libraries where 'null' and 'empty list' cause the same behavior in list-processing functions.

Objective-C is definitely dynamically typed, feel free to use "id" and go to town. To say nothing of swizzling.

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.

Huh?

    (int)nil == 0

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_

I would simply point to Apple's new language, Swift, dropping that feature as proof that they don't think it's the best way to design a language.

Our team is split (I don't know how evenly) on whether Obj-C or Swift's behavior is better. There are some staunch defenders of Obj-C's pattern being better.

I personally prefer requiring the programmer to explicitly handle nil/null. I think it improves maintainability, because future developers can see the code is correct, and it protects against changes (ex: you knew nil could never happen when your code was written, but then someone changed it so nil does occur and now your code is broken). It also saves future developers from spending time reasoning about the behavior of the code when nil occurs.

I prefer Optional to implicit nullability, but the debate isn't really between Optional and implicit nullability (is there any question there?).

The distinction is between segfault and returning 0 bits, and I'd say that returning 0 bits is generally better, because most of the time, in iOS apps, especially in absence of a "??" operator, it's what you want. For example, in a table view data source you don't have to check if your data array is non-null, just return its count, it'll be 0 if it is.

i.e. Optional monad > return all 0 bits > segfault

Reply on news.ycombinator.com