Cargo-cult typing, or: Objective-C's default type is id

It is true that we can omit id and still satisfy the compiler. This is the same way that we can leave out the int type in C function declarations, or completely leave out function declarations altogether if we're dealing only in ints. In both cases, though, nobody does this — and if you do this, your code will read as a mistake to anybody who has read any other Objective-C code from the past decade.

We include these "extraneous" types not for the compiler, but to make our intentions clear to the reader. This is the same reason many people and style guides use one-line compound statements or typedefs that make the token longer but more descriptive — at the same time we sacrifice a little brevity, we also sacrifice ambiguity.

It probably isn't always true that explicit is better than implicit, but it's a very good rule of thumb. If you have to choose one for a default mode, "explicit" is definitely the better choice.

As for the larger point about dynamic types, I and a lot of other old-timey Objective-C programmers felt the same way. It seems to me that powerfully dynamic languages like Smalltalk are good, and powerfully static languages like OCaml are good, but C's type system is just anemic and more bureaucratic than anything else. However, in practice, all these static facilities in Objective-C have proven really useful for writing real programs. The static analyzer can catch all sorts of errors. A combination of very consistent conventions and sophisticated static constraints has even allowed memory management to be handled for us completely through static analysis — that is just amazing, and the benefits of being rid of that responsibility are huge. Apple keeps moving in the static direction because those are the additions that Objective-C programmers are finding useful in practice.

I agree, the more loosey-goosey dynamic and implicit style works better for exploratory programming. I'll sometimes write spikes that way. But a book teaching how to write code in the language is not a throwaway spike solution, and in that environment you should either explicitly tell readers you're teaching them a style that nobody else uses in production code or — and this is my preference — just write idiomatic code.

Now that I know, though, it has become syntactic noise for me.

I wish Apple would add local type inference to Objective-C, perhaps using the existing id type or some keyword like var in C#. It would make the code so much more quicker to write, less verbose, a bit easier to change.

I mean reading and writing something like:

    var color = [UIColor green];
    var viewController = [[MyViewController alloc] initWithBackgroundColor:color];

    UIColor *color = [UIColor green];
    MyViewController *viewController = [[MyViewController alloc] initWithBackgroundColor:color];

- (void):(int)arg :(int)anotherArg :(int)someArg { NSLog(@"%d %d %d", arg, anotherArg, someArg); }

[self:1:2:3];

Try it. It compiles. It runs. How great is that? In fact, even Apple has done this!

+ (id)functionWithControlPoints:(float)c1x :(float)c1y :(float)c2x :(float)c2y;

So does this make this the best option? Should we even name our methods?

Of course, that is silly. Naming our methods appropriately tells us a lot. It means we don't have to check the documentation as much, which means we can effectively write faster. We're communicating with our code and our teammates more efficiently. The same holds true for explicitly typing method return values.

So ask yourself this: what's the default storage mechanism for a property, assign or strong? Now what was it when ARC first was developed? That's right, it was different. So you could see how someone might be confused reading your code if you weren't explicit. They might spend time looking in the wrong places for a bug. So why not be explicit? It's not about you, it's about everyone else who is left with your code.

So Brad Cox doesn't explicitly type his returns. Neither did Nextstep sometimes. That was 20+ years ago. We didn't have fancy IDEs with autocomplete; keystrokes were a luxury. That's probably why they couldn't put the 'e' on 'creat' in libc.

Last couple of Objective-C articles making it to the top of Hacker News have been bad. Just a kind warning to any budding Objective-C developers: just because it made it onto Hacker News doesn't make it good.

  @interface NSArray (XXHelpers)
  -(instancetype)reverse;
  @end

  @protocol XXReversing <NSObject>
  @required
  -(instancetype)reverse;
  @end

  @interface NSArray (XXHelpers)
  <XXReversing>
  @end

  @interface NSOrderedSet (XXHelpers)
  <XXReversing>
  @end

With that said, I think Apple are pushing the language in that direction, because recently everyone started developing for iOS, even people who didn't program at all. Apple is trying to make it easy for them. I see nothing wrong with that. It may not be the best from a programmer viewpoint, but I can understand it.

P.S. I think this is why Microsoft has embraced static typing throughout its developer ecosystem. It makes learning from scratch much easier and developers (although not very experienced ones) flock to your platform. Of course this same thinking created ASP.NET and shortened the lives of many good men. But you cannot judge them, really.