Dr. Brad Cox -- and he had one main goal in mind: Be a strict superset of C
That's as worthy a goal as inventing car that is strict superset of the horse carriage or a plane which is strict superset of a hot air baloon. Strict C is not suitable for OOP due to lack of overloading and creation/management of name spaces.
This is by design. It allows dynamic messaging. You can even, for example, send a message to nil and everything is fine.
You should't have to execute hundreds of CPU instructions to make a function call that checks for the whether function pointer (or its parent ptr) is null. Three CPU instructions can easily handle it (e.g. OR EAX,EAX; JZ skip; CALL EAX). In fact this dubious "feature" has probably cost me more debugging time than any other "feature" -- an uninitialized/released object quietly returns 0, that breaks something else many steps later, which needs then to be backtracked to the source problem. I would rather the code crashed right there at call, so I can find it on the first crash, rather then reconstructing it from some subtle malfunction much later on.
Again, only something you need in a statically linked object-inheritance style language like C++.
There is absolutely no gain (other than saving efforts of the compiler writer at the expense of programmers & end users CPU/battery) in hashing method names and searching them in a hash table for each invocation of class method/property access compared to storing the target function address into an array of pointers (which can be fixed-up/reloacted if needed by loader) and calling them via function pointers retrieved in a single instruction via compiler generated index. The array of pointers, with an extern/export allowing access to it to the app, has full dynamical felxibility equal to anything provided by hashed method names, while using hundreds times fewer runtime CPU instructions (with more complex compiler code instead). Single step once through assembly code of a method call or property access, and recall that all it is doing is one or two instruction worth of actual task.
Again, by design. Named arguments makes Objective-C one of the best languages for code readability. You don't have to wonder what the arguments are!
I don't find [obj string:string count:count] any more readable than obj->string(count) or *obj(string,count). It's needless clutter that saved the compiler writer trouble of implementing name mangling & overloading by shoving that part of compiler job to the brains of future programmers. Compiler designer saved himself few weeks at the expense of few hundred million weeks of work for programmers. Great deal.
I agree that the Cocoa library objects / methods are verbose, but this is a GOOD thing.
It's a good thing if you are manager who hasn't programmed since college and wish to peek at what some code is doing, without learning the language. Cocoa names are like having manual for the class rewritten over and over in each statement.
But if you are trying to follow the pattern specific to the task of your code, the vast volume of the Cocoa names smothers it, making even the most trivial algorithm look like rocket science. Dragging with each name its whole ancestry is exactly opposite from the objective of abstraction, which is the key tool in conquering the complexities of programming. All aspects that are not strictly specific to narrow task that some function/method is doing, should be out of sight, just like the one of most valuable abstraction tools in computer languages, functions, hide all the variation of the caller's context and purposes from the implementation of the function. The function knows only the aspect of the world defined by its parameters & return values and need not worry about whether, say rectangle it is operating on is screen rectangle or room floor...
With its lack of overloading, named args, poor name space partitioning,... the Obj-C is completely contrary to the objectives of abstraction and Cocoa merely wraps around that fundamental defect, amplifying it as it layers its functionality around it. Further, the people who are attracted to such anti-abstraction language are naturaly anti-abstraction (concrete, pro busywork) types, hence that type of midset will form self-reinforcing anti-abstraction loop with the system they are evolving, making it even worse.