nil is a safety/convenience trade-off -- it can be dang convenient, but it's just begging for hard-to-spot bugs to appear in your code. To use your example: >

nil is a safety/convenience trade-off -- it can be dang convenient, but it's just begging for hard-to-spot bugs to appear in your code. To use your example: > [str doSomething]; // If you really care if it happened or not, then introduce a check for nil Usually I actually care if the code I wrote did something! Writing nil checks everywhere would be non-idomatic and really annoying. (Something like Haskell gives you the best of both worlds, arguably.) I agree the language has gotten much better. I've worked on two ObjC iPhone projects, one before ARC and blocks, and one after. The impact of blocks, especially, is incredible. So, so, so much nicer. (Also object literals are a nice recent addition.) That said, the criticisms voiced in this article, which I agree with and think are real problems, are unlikely to go away -- they're just too closely tied up in the core of what objc is. (You're never going to have a nil that throws or a type-safe containers in objc, I'll predict right now.) I do overall like the language. Especially for GUI code, which tends to have lots of stuff doing relatively straight-forward things, the [soSomethingWithaThing:thing otherThing:otherThing frob:someFrob] style of method naming, while verbose, is awesome -- the code is extremely easy to read, and it's well-neigh-impossible to get bugs by mixing up the method order. (Compare this to e.g. python, where you have neither type system nor naming to tell you if you mess up parameter order.)