Your list reminds me quite a bit of the effusive language used by Apple engineers at WWDC, but does not reflect the larger context and objectivity of the indust

Your list reminds me quite a bit of the effusive language used by Apple engineers at WWDC, but does not reflect the larger context and objectivity of the industry outside of Apple. If we inspect your point about compilation vs interpretation, we ought to note that this is a technical decision, not an implementation constraint. Mono compiles C#/F# into native code when targeting iOS. If we look at lldb, I think your assessment is overly generous. lldb is a new, buggy, but promising debugger. Most languages -- including C#, Java, Haskell, OCaml -- have a standard and viable debugger, and this does not particularly set Objective-C apart. As for libdispatch, it simply a closure-based thread-pool executor / IO framework, like you'd find in any other language. It's better than pthreads and serves as a nice interface on top of kqueue, but it's certainly not so novel as to be the "best concurrency framework ever". For example, compare against Microsoft's Reactive Extensions; Rx allows one to implement concurrency declaratively, rather than imperatively with chained closures as is done in with libdispatch. http://rxwiki.wikidot.com/101samples#toc3 http://rxwiki.wikidot.com/101samples#toc3 Lastly, I wish to address header files. Everything in a header file could be derived automatically from the original code. This is done on almost every other modern language platform, and there's no reason it shouldn't be done here. Furthermore, headers do not elide the need for documentation; Objective-C type system is not nearly expressive enough to fully articulate the constraints and invariants of an API, and undocumented APIs are inescapably and destructively ambiguous APIs. Apple even sets a good example here by providing complete documentation for every supported API in the system.