Comment by drewcrawford | Hacker News Reader

Comment by drewcrawford | Hacker News Reader

Parent Full thread

In defense of ObjC's type system (which is the author's major gripe).

It is a duck-typed language. This is the philosophy that "if it walks like a duck... it's a duck." This is the philosophy used by lots of modern languages like Python, Ruby, and JS.

Meanwhile there is the statically-typed system, which wants you to declare things to be ducks explicitly (or to pick up a duck declaration through an inheritance system). This is the philosophy used by Java, C++, etc.

Anyway, the author's gripe isn't with ObjC's types. The author's gripe is with any duck-typed system. The whole point of these type systems is to avoid providing any strong guarantees about types. If you want strong typing, use a strongly-typed language. C++ may align better with this author's programming ideology.

It's also worth pointing out that runtime type checks are, all else being equal, slow. ObjC is used primarily in mobile environments where speed is a concern. As the author discovered, you can opt in to type checking by using NSAssert. This forces you to think about whether the cost of a dynamic type check is acceptable. NSAsserts are also disabled by default in release builds, so this gives you checking when you need them (development) and speed when you don't (production).

C++'s type system is deliberately constructed in such a way that the compiler can do the bulk of the type enforcement, which is much faster than runtime type checking. Alternately stated, this means that the programmer must write code in such a way that the compiler can infer/enforce type checks, or else they will get type errors. The author's complaints about not enough compiler errors seem to suggest to me that he would be more at home in a language like C++ that is specifically designed for this purpose.

(Author here)

I definitely prefer static typing over dynamic typing. I don't really mind duck typing so much as I mind dynamic duck typing (for example I like how Go does duck typing).

I do try to mention that preference for static typing in the post a few times, to make it clearer that it's the dynamism that's bothering me (as opposed to the design being wrong).

"static duck typing" AKA structural typing ;-)

Discussions about typing seem pretty fruitless because there are often a lot of people talking past each other because they're not working off of shared definitions of what the terms (typed untyped static dynamic strong weak) actually mean.

I generally assume people will understand static/dynamic as 'type associated with variable' vs 'type associated with value'.

But you're dead on about strong/weak. You may get away with stronger and weaker, but strong and weak have no widely agreed upon meaning w.r.t. types.

> If you want strong typing, use a strongly-typed language.

Unfortunately in iOS development, we don't have a good alternative to ObjC.

Well good is debatable but arguably C++ meets this criteria. I work on many iOS codebases that have C++ layers.

There's RubyMotion for the Ruby crowd as well. You can use Java as well (though possibly just for Games): http://www.robovm.org

sure you do, Xamarin.iOS.

No, er, it's worse than Python.

`[nil methodname]` returns nil. Python et al have the decency to crash to the ground, look embarassed, and stop running.

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.

Well, Python is duck typed, but None doesn't pretend to be a duck, a cow, a pig, etc. That sounds extremely dangerous.

In C/C++, dereferencing the null pointer is undefined. That is a hell of a lot more dangerous than doing nothing. ObjC's "defined to do nothing" behavior is a significant step up from the other languages in the "fast, compiled, bare metal" cluster (C,C++).

It's rather subjective to say that's a "significant step up". "Dereferencing a null" indicates a potentially serious underlying issue that the "do nothing" hand-holding you describe masks.

nil just always comes back with 0 or nil or whatever -- it's like a really dumb version of None in the Maybe monad, and trying to get you some of the convenience (except way, way worse from a safety perspective).

For extra fun, NSNull (the "designated" object (as opposed to an actual zero value of nil) to represent nil) doesn't happily respond to any message sent to it -- i.e., if you replace nil with NSNull somewhere in the code, it will most likely blow up.

Reply on news.ycombinator.com