如果让我说一句我恨Objective-C的地方，那一定就是类型系统了。它很难表示出很多有用的类型(例如没有泛型)并且实际上它也不能检查你的工作(甚至在运行时)。虽然它在感觉上很动态，但是我更喜欢静态的强类型。

一开始，Objective-C没有null(但是C语言有，虽然你不常用)。替代的，Objective-C有nil，它很像null除了当你不小心在程序里使用它的时候它不会使程序停止。发给nil的消息不会抛出异常，它仅仅只返回了一个nil并且实际上不作任何的评估。

我是真的真的不喜欢nil. 例如，假设你写了像构造函数的方法，它有一个叫SuperImportantSecurityChecker的参数。
你坚持参数不是nil，因为对不合逻辑的不被执行进行安全检查是很糟糕的。
你也可以写一个测试，故意导致安全失败，并且检查下确实是失败了。你做的很好，因为你忘记了用SuperImportantSecurityChecker参数的值初始化SuperImportantSecurityChecker了。像这样的错误会几年都不会被发现，这多亏了nil。

另一个例子，当程序已经出错了，但是会继续运行，令人吃惊的竟然是缺少运行时类型检查。例如，如果你写NSMutableArray* v = [NSArray array]，Objective-C会高兴的将你的可变数组的指针指向一个不可变的数组（你以前甚至没有看到编译报警，因为NSArray.array返回id, 现在它返回 instancetype)。当你尝试去调用给“可变”数组添加对象的方法时，程序会崩溃，错误提示为“selector not found”。这个并不像不可期的nil那样糟糕，nil会悄悄地丢弃要添加的项而不是崩溃，但是查找这些错误是很恼人的。

当在块上工作时缺少运行时检查是非常恶心的，因为语言允许你过度自由的指定输入类型。这种写法看起来多么诱人,[array enumerateObjectsUsingBlock:^(NSNumber* obj, NSUInteger index, BOOL *stop) { ... }];，根据你的期望，thatobjshould通常是一个数字而不是generalid，但是有时候你会搞砸它并且不得不追踪问题所在。我已经采取了在大多数块开始前加一行strewingassert([obj isKindOfClass:[WhateverType class]])来先发制人的捕捉这些错误。

另一个值得注意的Objective-C会默默舍弃的是，如果你忘记了特定的编译选项。你或许已经知道不指定“- Objc"会导致分类方法在运行时不被接受，尽管不会在编译时被发现，但是你知道不包含-fobjc-arc-exceptions”会导致有异常抛出时ARC不能正确的进行清理吗？根据约定 强烈支持你不要捕获异常是合理的，并且速度好处显然不小，但是，苹果让他们的语言的默认执行不正确的行为着实让我受宠若惊。

基本上，我时常感觉Objective-C的类型系统是在挑战我。我也尝试写一个安全的voip应用来保护你免受你的压迫性的政府，但是我在用的语言实际上被设计成升级微不足道的错误来折中，而不是立马崩溃。我觉得，我将从不会犯低级错误，因此没有人会死，对吗？这是完美的。或者有些人受虐待。。。我也许也会检查它十多次。。。

如果让我说一句我恨Objective-C的地方，那一定就是类型系统了。它很难表示出很多有用的类型(例如没有泛型)并且实际上它也不能检查你的工作(甚至在运行时)。虽然它在感觉上很动态，但是我更喜欢静态的强类型。

一开始，Objective-C没有null(但是C语言有，虽然你不常用)。替代的，Objective-C有nil，它很像null除了当你不小心在程序里使用它的时候它不会使程序停止。发给nil的消息不会抛出异常，它仅仅只返回了一个nil并且实际上不作任何的评估。

我是真的真的不喜欢nil. 例如，假设你写了像构造函数的方法，它有一个叫SuperImportantSecurityChecker的参数。
你坚持参数不是nil，因为对不合逻辑的不被执行进行安全检查是很糟糕的。
你也可以写一个测试，故意导致安全失败，并且检查下确实是失败了。你做的很好，因为你忘记了用SuperImportantSecurityChecker参数的值初始化SuperImportantSecurityChecker了。像这样的错误会几年都不会被发现，这多亏了nil。

另一个例子，当程序已经出错了，但是会继续运行，令人吃惊的竟然是缺少运行时类型检查。例如，如果你写NSMutableArray* v = [NSArray array]，Objective-C会高兴的将你的可变数组的指针指向一个不可变的数组（你以前甚至没有看到编译报警，因为NSArray.array返回id, 现在它返回 instancetype)。当你尝试去调用给“可变”数组添加对象的方法时，程序会崩溃，错误提示为“selector not found”。这个并不像不可期的nil那样糟糕，nil会悄悄地丢弃要添加的项而不是崩溃，但是查找这些错误是很恼人的。

当在块上工作时缺少运行时检查是非常恶心的，因为语言允许你过度自由的指定输入类型。这种写法看起来多么诱人,[array enumerateObjectsUsingBlock:^(NSNumber* obj, NSUInteger index, BOOL *stop) { ... }];，根据你的期望，thatobjshould通常是一个数字而不是generalid，但是有时候你会搞砸它并且不得不追踪问题所在。我已经采取了在大多数块开始前加一行strewingassert([obj isKindOfClass:[WhateverType class]])来先发制人的捕捉这些错误。

另一个值得注意的Objective-C会默默舍弃的是，如果你忘记了特定的编译选项。你或许已经知道不指定“- Objc"会导致分类方法在运行时不被接受，尽管不会在编译时被发现，但是你知道不包含-fobjc-arc-exceptions”会导致有异常抛出时ARC不能正确的进行清理吗？根据约定 强烈支持你不要捕获异常是合理的，并且速度好处显然不小，但是，苹果让他们的语言的默认执行不正确的行为着实让我受宠若惊。

基本上，我时常感觉Objective-C的类型系统是在挑战我。我也尝试写一个安全的voip应用来保护你免受你的压迫性的政府，但是我在用的语言实际上被设计成升级微不足道的错误来折中，而不是立马崩溃。我觉得，我将从不会犯低级错误，因此没有人会死，对吗？这是完美的。或者有些人受虐待。。。我也许也会检查它十多次。。。