Except you don't *need* Obj-C to code on Mac. The regular C code for
X11
works, too. Granted, using Apple's X implementation isn't very
optimal, but it
does work. Sticking with C allows all those developers to code "for
Mac" as
well, with no Obj-C knowledge needed.
You can run X11 app on Windows as well, as there're several X11
servers. But none would appreciate that ;) And none would say you
don't have to use WinAPI to program Windows.
Btw. note that X11 on Mac is optional (even it is free, you need to
install it youself), doesn't run all the time, and X11 apps do not
have their own icons and do not resemble native Mac applications at all.
Has Apple ever commented on making C, or even C++, bindings? Maybe
some
enterprising coder could make something. Personally, it'd seem more
beneficial
to provide C bindings, instead of forcing app developers to use a
specific
language or to go through a sub-optimal X implementation.
Already mentioned here, there's Carbon which is pure-C API for Mac.
But IMHO this won't make things easier, since it is legacy
compatibility library, since you need to know its API to use it
anyway, and it is far less popular that Cocoa, so has less developers.
Finally there's no 64-bit Carbon and it can be taken out from futures
OSX releases.
I can see real paradox here. Being against using Objective-C is
supposed to bring wider support to the code (right?), but implies
requirement of using either Carbon or Mac OpenGL + Core libraries,
which are far LESS popular, have far LESS active programmers and LESS
tutorials and books than Cocoa and Objective-C.
So forcing C for Mac support, you drastically limit possible
developers that could work on the code :>
Regards,
--
Adam
