This article is technically correct, which I'm told is the best kind of correct. However, it's also missing the forest for the trees.
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.
I agree totally. I must say, that I have seen typeless declarations in code, but I do find them to be a nuisance. Adding (id) to a declaration isn't really that hard, and makes the code a lot more radable. Why raise the treshold for the ability to read Objective-C?
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.