Nickolaus – authoring a language interface to an SDK is not impossible at all, it’s common – expected even. Keep in mind that pretty much every major language (including Objective-C) at its root is interfacing with the same shared C system libraries at runtime.

I personally don’t know what issues people have with Javascript are. I think alot of people confuse the related complexity of client-side browser development and DOM with *Javascript the language*.

I find it pretty much the opposite of Objective-C – it’s extremely fast to develop in and works fine for me, and the competing runtimes get better and better performance every year.

The only downsides are it requires the developer to know what he’s doing alot more, as it has no training wheels.

Header files: The Objective C docs say that header files are “the interface”, the definition if you will. There are some arguments towards keeping that separate from the implementation. I am not 100% convinced by this, but code duplication is kept at a minimum. Variables are only defined in the header, for example. I still find it confusing to have two separate files for every object. So in the end the main reason for header files is probably that C had header files. A stupid reason if there ever was one.

Memory management: Yes. If you are used to garbage collection this feels like coming back to the stone age of computing. Am I programming a posix system from 1973 or the iPhone? There is no excuse.

Pointers – that falls in the same category – it’s stupid.I get the feeling that in Objective-C, you kinda sorta pretend the pointers don’t exist. You pretend you are working with objects. But they are still there and no amount of denial makes them prettier. Along with alloc/retain/release it’s a bit of a nightmare.

Some you didn’t mention: Overhead. There is a lot of “stuff” all over an Objective-C class – compiler directives, header file fluff, and other things – to write a simple class you end up with two files with lots of things in them. That’s all distracting from what you want to do: Define some objects and use them.

I must disappoint you regarding alternative languages – it’s impossible to do unless Apple decides to wrap all libraries in some other language. There are many powerful frameworks in OS X and they are all in Obj-C. So if you used Ruby to program your stuff, you still have to know Obj-C in order to interact with the libraries. In the end most things you do have to do with libraries – you are very high up on the abstraction layer – a good thing – but the mountain of code you stand on is all through and through Obj-C, and some parts are even in C. The way I see it, Apple either implements an entire parallel universe of wrapped libraries, along with wrapped documentation – or Objective C.

Losing the header files, pointers, and manual memory management could even make it into a modern language….

PS: JavaScript is a problem in and of itself, it should never be the “solution” to anything