Volume Number: 16 (2000)
Issue Number: 7
Column Tag: MacTech Online
By Jeff Clites <online@mactech.com>
Unless you've been living under a rock, you know by now that Mac OS X is just around the corner. At this point, every Mac developer should be preparing himself for this brand new operating system. Make no mistake — Apple has gone to great pains to make this transition as smooth as possible, and to ensure the widest possible range of backward compatibility, but Mac OS X is a whole new world. Developers should be extremely excited; I know I am. But it is, naturally, a bit unnerving to be faced with all this change — to go from being an expert to a beginner. The bright side (or, I should say, one of the many) is that learning new stuff is the fun part, and after you've gotten over the shock you'll find out that your job just became a whole lot easier, that it's a whole lot more fun, and that you're a whole lot more productive. The Carbon API is, refreshingly, more than just a compatibility shim on the Classic API — it's a real step forward. If you're a long-time Mac developer, you'll be glad to see that your tools are continuing to evolve, and not just change. Although you'll be able to continue developing in Carbon for quite a while, and will be able to take advantage of many of the operating system's new features by doing so, I would encourage you to take a serious look at the Cocoa API. It is completely different, but if you give it a fair chance, you're going to like it, and you'd be crazy not to use it for your new development. If you don't believe me, than just try to find anyone who was ever an OpenStep developer and didn't love it. You won't be able to. At the time of writing, I've just returned from this year's WWDC, and during most of the WebObjects sessions I was struck with just how many people, in the midst of voicing a complaint, took the time to point out just how much of a joy working with this technology is, and to thank the development team. Along with an operating system and a CEO, we've acquired a strong community from NeXT, and as we move forward you'll want to be a part of it, and to avail yourself of their expertise.
So what should you do to get "ready for X"? Step 1 is to learn either Objective C or Java. C and C++ programmers may be a bit irked that they need to learn a new language, but it will be less of a shock that you think, and well worth it. (And again, isn't learning a new tool supposed to be the fun part?) So which one should you use? That's easy — either. In fact, learn both, and see which you like best. As Mac developers we've always had a choice of languages: C, C++, Pascal, the BASICs, Perl — the list goes on. We had this range of choice because the Mac API was procedural, consisting of structures and functions, and so it was easy to access from just about any language — you just needed the right headers or wrappers. The Cocoa API is a framework, in the true sense of the word, and frameworks are inherently language-specific. So it's rather a miracle that we can use Cocoa from both Objective C and Java; they are just similar enough under the hood that Apple was able to arranged it so that we can use either. Cherish this choice—it's quite likely the only one we'll ever have. So learn both languages, and if you find that you love one of them and hate the other, you should still encourage Apple to support both, because choice is a Good Thing, and we'll all benefit from it in the long run.
As a first step, I would encourage you to read Apple's Object-Oriented Programming and the Objective-C Language, even if you don't plan to use Objective C, and especially if you are new to object-oriented programming. (You can find it online along with the rest of their developer documentation.) It's relatively short, and the introductory material is language neutral and gives an excellent explanation of what "OOP" is all about. If you're a C or C++ programmer, you'll probably find that you can pick up Objective C in a couple of hours, assuming you are already comfortable with object-oriented concepts. It's just a small syntax addition on top of C, and much less of a mouthful than C++. It does look a little funny at first, but after you get used to it, it becomes quite easy to read and to work with. (In case you're wondering, its basic syntax is "[object message]", or "[object message:parameter]", so you'll end up with usage which looks like "[dog fetch:stick]". This syntax is derived from the Smalltalk language, which is the "other" famous export of Xerox PARC.)
Object-Oriented Programming and the Objective-C Language
<http://developer.apple.com/techpubs/macosx/System/Documentation/Developer/Cocoa/ObjectiveC/ObjC.pdf>
Moving beyond the language issue, Apple has provided a large amount of documentation on their new operating system, and exactly where you should start will, of course, depend on what type of programming you actually do. But there is one general technology which you should be sure to familiarize yourself with: Unicode .
Unicode is not actually new to the Macintosh platform and has been supported long before Mac OS X, but it is used pervasively there and may be new to many Mac programmers. In case you haven't encountered it before, Unicode is an attempt to create one system which can encode all of the characters of all of the languages of the world. This is an ambitious goal, but it's necessary if first-class information processing is going to make it outside of the Western world. Without Unicode, different languages are forced to use different encodings, so that a byte which represents an "a" in one encoding might represent a Thai letter in another, and you have to have prior knowledge of the encoding in use if you want to make sense of the information. This is problematic, and only gets worse if you need to mix characters from disparate languages within one document. (On a very mundane scale, it also solves the problem that even if you think you are only working in ASCII, the Mac OS and Windows differ in their encoding of upper-ASCII characters, which can cause your curly quotes to turn into accented letters.) With Unicode, you will be able to faithfully transmit, process, and even display information in nearly all languages, even if you can't read it yourself. Cocoa uses Unicode internally for all if its string handling, and the ATSUI component of Carbon and Classic allow you to manipulate and display it there as well. The Unicode Standard itself is available in book form, and a much of the surrounding documentation is available on the Unicode web site, but this can be a bit overwhelming. (The Unicode book itself is quite large, although most of it is a listing of the glyphs for the characters.) In fact, you really won't need to know most of the details, because the system frameworks take care of them for you, but it will help to have a basic understanding of the concepts and limitations involved. A very useful source for this is the newly-published Unicode: A Primer (ISBN: 0-7645-4625-2), by Tony Graham, a member of the Unicode Consortium. I was happy to see that it explicitly mentions Unicode support in Mac OS 9 and Mac OS X Server.
The Unicode Home Page
<http://www.unicode.org/>
There are many more interesting technologies underpinning Mac OS X, and I plan to cover more of them in upcoming issues. Until then, get cracking!
