5 ms·

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'

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.

Strilanc 13y ago
(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).
- frou_dh 13y ago
  "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.
  - Strilanc 13y ago
    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.
stevoski 13y ago
> If you want strong typing, use a strongly-typed language. Unfortunately in iOS development, we don't have a good alternative to ObjC.
- mikeblue 13y ago
  sure you do, Xamarin.iOS.
- drewcrawford 13y ago
  Well good is debatable but arguably C++ meets this criteria. I work on many iOS codebases that have C++ layers.
- Moto7451 13y ago
  There's RubyMotion for the Ruby crowd as well. You can use Java as well (though possibly just for Games): http://www.robovm.org http://www.robovm.org
icebraining 13y ago
Well, Python is duck typed, but None doesn't pretend to be a duck, a cow, a pig, etc. That sounds extremely dangerous.
- dilap 13y ago
  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.
- drewcrawford 13y ago
  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++).
  - Iftheshoefits 13y ago
    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.
pnathan 13y ago
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.
- drewcrawford 13y ago
  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/ http://feross.org/gcc-ownage/
  - frou_dh 13y ago
    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 http://golang.org/ref/spec#Address_operators
    - drewcrawford 13y ago
      I stand corrected.
  - pnathan 13y ago
    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.
- jawngee 13y ago
  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.

Strilanc 13y ago

(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).

frou_dh 13y ago
"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.
- Strilanc 13y ago
  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.

stevoski 13y ago

> If you want strong typing, use a strongly-typed language. Unfortunately in iOS development, we don't have a good alternative to ObjC.

mikeblue 13y ago
sure you do, Xamarin.iOS.
drewcrawford 13y ago
Well good is debatable but arguably C++ meets this criteria. I work on many iOS codebases that have C++ layers.
Moto7451 13y ago
There's RubyMotion for the Ruby crowd as well. You can use Java as well (though possibly just for Games): http://www.robovm.org http://www.robovm.org

icebraining 13y ago

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

dilap 13y ago
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.
drewcrawford 13y ago
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++).
- Iftheshoefits 13y ago
  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.

pnathan 13y ago

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.

drewcrawford 13y ago
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/ http://feross.org/gcc-ownage/
- frou_dh 13y ago
  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 http://golang.org/ref/spec#Address_operators
  - drewcrawford 13y ago
    I stand corrected.
- pnathan 13y ago
  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.
jawngee 13y ago
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.