4 ms·

> a mistake as its almost certainly clear from, for example, another difference I list in the immediately following sentence... I didn't reply to that sentence

> a mistake as its almost certainly clear from, for example, another difference I list in the immediately following sentence... I didn't reply to that sentence because I didn't want to have to point out your understanding of Objective-C was incorrect, it is not weakly typed, only some Foundation objects are weakly typed. As the other comment here mentions, syntax is trivial (although being informed by 20 years of language design is not so trivial to me day to day), the key differences in overall safety, expressiveness and features in the language is far bigger than trivial method syntax.

tolmasky 10y ago
Uh oh, about to get into an argument over terms that have no precise definition, but I believe that in the context of Objective-C vs. Swift, Objective-C is perfectly fair to be considered weakly typed. In fact I think that in the context of Objective-C vs. most other typed languages it is perfectly fair to consider Objective-C weakly typed, especially when the dominant culture involved using id everywhere and since generics were only added very late in the language so your base collection classes were all weakly typed for 99% of the life of the language. I'd find it really eyebrow-raising for someone to not consider Objective-C "more weakly typed" than Swift, or do you think that Swift did not introduce a culture of stronger typing? But I digress: regardless of whether syntax is trivial or not, my point is that I believe wanting to have a clear break from a syntactic perspective with a language that was plagued as being "different looking" for its entire life was probably a goal in the creation of a new language. Do you really not remember pre-Swift where "Objective-C is weird looking" was an actual argument people would make? Objective-C could have been made more safe, it could not however have its syntax drastically altered without considering it a new language.
tolmasky 10y ago
Also, for the record, before Apple got serious about protocols, AppKit and WebKit were full of respondsToSelector: mumbo-jumbo, so you're just wrong about Objective-C not being weakly typed. If I can type it weakly, then it is weakly typed. And by can I mean can effectively, that is to say, thanks to Objective-C's reflection you can both use id and still interact with it, vs creating an AnyObject type class in a stricter strongly typed language where the compiler will not let you then just call whatever method you want on it. In fact, remnants of this clearly remain in WebKit where you have protocols where every method is optional, and thus everything is respondsToSelector: protected, making a "strongly typed" description highly suspect.
mpweiher 10y ago
> your understanding of Objective-C was incorrect, it is not weakly typed, That's an, er, interesting statement. Objective-C is probably about as weakly typed as it is possible to get and still have the ability to write type annotations. From a static typing perspective, it combines the strongly dynamically typed world of Smalltalk with the weakly statically typed world of C, and with the strong possibility of C-style consequences (kaboom) if you get it wrong. First of all, the ability to statically type Objective-C objects was added to the language after-the-fact (NeXTStep 2.x or 3.x?), and those types have been and continue to be largely cosmetic (with one crucial exception). So if I have "NSNumber *a" and the actual object is an NSString, the runtime will select the NSString methods, not the NSNumber methods. Subverting the "type checking" is about as easy as can be: (a) assign from/to "id" (b) pipe through a collection (now we have pseudo-generics) (c) cast (d) declare methods on a protocol that you never implement anywhere (or that has been implemented somewhere else). The crucial exception is that if you have, roughly speaking, C types (particularly ones that aren't equivalent to an 'id' in machine-representation) in your message signature, you will crash if you signatures are incompatible because you got the wrong one. Which is why I advocate for the safe "id subset"[1]. Marcel [1] http://blog.metaobject.com/2014/05/the-spidy-subset-or-avoiding-copeland.html http://blog.metaobject.com/2014/05/the-spidy-subset-or-avoid...

tolmasky 10y ago

Uh oh, about to get into an argument over terms that have no precise definition, but I believe that in the context of Objective-C vs. Swift, Objective-C is perfectly fair to be considered weakly typed. In fact I think that in the context of Objective-C vs. most other typed languages it is perfectly fair to consider Objective-C weakly typed, especially when the dominant culture involved using id everywhere and since generics were only added very late in the language so your base collection classes were all weakly typed for 99% of the life of the language. I'd find it really eyebrow-raising for someone to not consider Objective-C "more weakly typed" than Swift, or do you think that Swift did not introduce a culture of stronger typing? But I digress: regardless of whether syntax is trivial or not, my point is that I believe wanting to have a clear break from a syntactic perspective with a language that was plagued as being "different looking" for its entire life was probably a goal in the creation of a new language. Do you really not remember pre-Swift where "Objective-C is weird looking" was an actual argument people would make? Objective-C could have been made more safe, it could not however have its syntax drastically altered without considering it a new language.

tolmasky 10y ago

Also, for the record, before Apple got serious about protocols, AppKit and WebKit were full of respondsToSelector: mumbo-jumbo, so you're just wrong about Objective-C not being weakly typed. If I can type it weakly, then it is weakly typed. And by can I mean can effectively, that is to say, thanks to Objective-C's reflection you can both use id and still interact with it, vs creating an AnyObject type class in a stricter strongly typed language where the compiler will not let you then just call whatever method you want on it. In fact, remnants of this clearly remain in WebKit where you have protocols where every method is optional, and thus everything is respondsToSelector: protected, making a "strongly typed" description highly suspect.

mpweiher 10y ago

> your understanding of Objective-C was incorrect, it is not weakly typed, That's an, er, interesting statement. Objective-C is probably about as weakly typed as it is possible to get and still have the ability to write type annotations. From a static typing perspective, it combines the strongly dynamically typed world of Smalltalk with the weakly statically typed world of C, and with the strong possibility of C-style consequences (kaboom) if you get it wrong. First of all, the ability to statically type Objective-C objects was added to the language after-the-fact (NeXTStep 2.x or 3.x?), and those types have been and continue to be largely cosmetic (with one crucial exception). So if I have "NSNumber *a" and the actual object is an NSString, the runtime will select the NSString methods, not the NSNumber methods. Subverting the "type checking" is about as easy as can be: (a) assign from/to "id" (b) pipe through a collection (now we have pseudo-generics) (c) cast (d) declare methods on a protocol that you never implement anywhere (or that has been implemented somewhere else). The crucial exception is that if you have, roughly speaking, C types (particularly ones that aren't equivalent to an 'id' in machine-representation) in your message signature, you will crash if you signatures are incompatible because you got the wrong one. Which is why I advocate for the safe "id subset"[1]. Marcel [1] http://blog.metaobject.com/2014/05/the-spidy-subset-or-avoiding-copeland.html http://blog.metaobject.com/2014/05/the-spidy-subset-or-avoid...