Programming for Mac OS X
Programming for Mac OS X is as interesting as it is frustrating.
For those who don't know, Mac OS X is basically your garden variety Unix system with Apple's special sauce on top, in the form of additional components and GUI.
Apple's X-Code development toolkit is also based on top of GNU's standard C compiler (though more recent versions can use several different compilers). Then besides standard C, they support Objective C. In fact, the compiler itself supports C++, C, and a number of other languages and variants.
In fact, if you want to write a typical "hello world" CLI program, you just compile a normal C or C++ version, and it will work fine. If you want to access other standard Unix features, you can do that the way you normally would in BSD (Which Mac OS is a variant of).
When it comes to GUI programming, though, is where you get stuck. The interface "framework" (Cocoa) is written in Objective C, and it's not so easy to call it from outside of an Objective C program. More to the point, even non-GUI higher level Apple frameworks are the same. The "Core Location" Framework is Objective C, and if I'm not mistaken, the Bluetooth is as well. I would assume most of the higher-level Apple developed code follows this standard.
Now don't get me wrong, I'm not saying that there is anything wrong with Objective C. I think it's fine, and theoretically at least, it has some strong points over C++. But back in reality land, many languages exist, and almost *all* of them use standard C notation for dealing with external data because, well, C has been the most common and simple language for a very long time.
Just to give an example, if you want to write a command line program that spits out your current location using the Core Services API, and your application is not going to be written in Objective C, you have to face an uphill battle just to do such a simple function call. With C functions, there is a simple pointer you can jump to to call the code after placing the inputs on the stack (or wherever), and you take care of the output when it's done. This certainly isn't impossible with Objective C, but it will be more difficult than necessary.
I don't disagree with Apple's decision to use Objective C for application development - it is as a good of a choice as any - but for low-level utility calls, it's not a great idea. If they want Objective C to have easy object-oriented access, they can always wrap the original C style functions in an OOP library, as is done everywhere else in the computer world. Yes, it's a pain, but it's less of a pain in the long run than forcing everyone else to build a bridge to you.
(I will also mention, this has be an issue with KDE as well, as KDE is written in C++, and non-C++ applications have had difficulty calling KDE functions).
For those who don't know, Mac OS X is basically your garden variety Unix system with Apple's special sauce on top, in the form of additional components and GUI.
Apple's X-Code development toolkit is also based on top of GNU's standard C compiler (though more recent versions can use several different compilers). Then besides standard C, they support Objective C. In fact, the compiler itself supports C++, C, and a number of other languages and variants.
In fact, if you want to write a typical "hello world" CLI program, you just compile a normal C or C++ version, and it will work fine. If you want to access other standard Unix features, you can do that the way you normally would in BSD (Which Mac OS is a variant of).
When it comes to GUI programming, though, is where you get stuck. The interface "framework" (Cocoa) is written in Objective C, and it's not so easy to call it from outside of an Objective C program. More to the point, even non-GUI higher level Apple frameworks are the same. The "Core Location" Framework is Objective C, and if I'm not mistaken, the Bluetooth is as well. I would assume most of the higher-level Apple developed code follows this standard.
Now don't get me wrong, I'm not saying that there is anything wrong with Objective C. I think it's fine, and theoretically at least, it has some strong points over C++. But back in reality land, many languages exist, and almost *all* of them use standard C notation for dealing with external data because, well, C has been the most common and simple language for a very long time.
Just to give an example, if you want to write a command line program that spits out your current location using the Core Services API, and your application is not going to be written in Objective C, you have to face an uphill battle just to do such a simple function call. With C functions, there is a simple pointer you can jump to to call the code after placing the inputs on the stack (or wherever), and you take care of the output when it's done. This certainly isn't impossible with Objective C, but it will be more difficult than necessary.
I don't disagree with Apple's decision to use Objective C for application development - it is as a good of a choice as any - but for low-level utility calls, it's not a great idea. If they want Objective C to have easy object-oriented access, they can always wrap the original C style functions in an OOP library, as is done everywhere else in the computer world. Yes, it's a pain, but it's less of a pain in the long run than forcing everyone else to build a bridge to you.
(I will also mention, this has be an issue with KDE as well, as KDE is written in C++, and non-C++ applications have had difficulty calling KDE functions).
Comments
Post a Comment