Reading these boards, I've seen the subject of Cocoa vs Carbon, and the relative paucity of native Cocoa apps vs Carbonized apps, raised quite a few times.
"Why," the questioners ask, "don't more developers write pure Cocoa applications?"
Back when I was just a guy with a PC, I'd wondered about this myself. I'd done a reasonable amount of coding with Win32 and MFC and generally liked developing for the platform, although I found much of the UI coding to be clunky and tiresome (which are the same words I'd used to describe writing UI code for X/Motif five years earlier).
So, when I bought a PowerMac in February, I dived headfiirst into Objective-C and Cocoa. I was delighted by the language, and equally pleased at the way the Cocoa UI frameworks took so much off the work off the programmer's hands.
I picked up all the books on Cocoa programming I could find (3 - two good, one bad), I read the introduction to Objective-C and Cocoa on Apple's website.
Then I noticed something odd. On my bookshelves I had various "general" books on Win32, MFC and .NET coding - stuff like the Charles Petzold books. I also had some MCSA self-paced coursework tutorial texts. Finally, I had two extremely big sets of manuals - five volumes of Visual C++ documentation covering the language itself, the run-time, the MFC (2 volumes worth), and the standard template library. I also had an additional five volumes providing similar documentation for Win32 as a whole, including a book on the Common Controls, one on GDI, one on the base system functions and so on. Both of these sets were expensive - $150 list, $92 from somewhere like Bookpool and took up a good eighteen inches of shelf space each.
They were not bedtime reading, they were not always accurate, but they were there. The combination of stuff like Programming Windows With MFC and Programming Windows with these reference libraries were invaluable. Anything you needed to know was in there, quite often with examples. While Microsoft don't seem to have published a similar mammoth library for .NET, take a look at the shelves in Barnes and Noble - books on every .NET related subject you can think of. I'm currently reading the .NET IL Assembler book, just for fun.
Now, looking over at the new Mac section of my bookshelf I see two O'Reilly titles and Aaron Hillegaas' "Cocoa Programming For Mac OS X". Two of the three books are good ("Learning Cocoa" isn't). However, they're all rather slim counterparts to stuff like Programming Windows With MFC, and they're all (as you'd expect) quite focused on the GUI side of the Cocoa frameworks.
What I also see is a huge blank space where any sort of reference materials should be. Aha, it's online, I discover. I go online, muttering unhappily (I like online documentation as a supplement to a Real Book, not as a replacement for it) and find the relevant documentation on Apple's developer site.
Helpfully, they've separated the information into the Application and Foundation frameworks. Unhelpfully, the lists of Classes, Protocols, etc, are sorted alphabetically, which is an interesting idea when every class name starts with 'NS'.
I then spent half an hour trying to find the exact information I needed, literally by randomly threading through the documentation until I hit the information I was looking for. On a couple of occasions (this may have been fixed since) I found missing info (literally methods that something along the lines of "To Be Written" as their description).
So there's one possible reason for the slow rate of migration to Cocoa - once you're past the stuff the available books cover, you're thrown in at the deep-end with nothing but online documentation that's of variable quality and that isn't in an organizational framework (pun no intended) more sophisticated than that of man pages.
I don't think it's a coincidence that the places that *are* churning out good Cocoa software are those with roots in the NeXT era. From what I can see, references titles of the sort Cocoa lacks did used to be available for NextStep at one point.
Until Apple takes documentation seriously (and I do see this as their responsibility, it's their OS after all) Cocoa isn't going anywhere fast. I'll admit that I'm making progress - I've got half a dozen little projects at various stages of development, most of the "get familiar with the platform, not actually of much use to anybody" variety. It's ironic that while tools like Interface Builder make it possible to produce an almost fully functional interface while writing almost no application code in next to no time at all, once you get past the GUI you tend to get bogged down trying to get what you previously considered the easy bit of the code finished.
I'll admit that some of this is my own fault - I've got a pretty good Unix background and could use the BSD layer to do the rest- but I'm determined to do it properly, using the Cocoa classes provided.
Argh, sorry, just venting. I think it was running across a reference to my long-lost copy of De Re Atari this morning that did it. Now *that* was documentation.
"Why," the questioners ask, "don't more developers write pure Cocoa applications?"
Back when I was just a guy with a PC, I'd wondered about this myself. I'd done a reasonable amount of coding with Win32 and MFC and generally liked developing for the platform, although I found much of the UI coding to be clunky and tiresome (which are the same words I'd used to describe writing UI code for X/Motif five years earlier).
So, when I bought a PowerMac in February, I dived headfiirst into Objective-C and Cocoa. I was delighted by the language, and equally pleased at the way the Cocoa UI frameworks took so much off the work off the programmer's hands.
I picked up all the books on Cocoa programming I could find (3 - two good, one bad), I read the introduction to Objective-C and Cocoa on Apple's website.
Then I noticed something odd. On my bookshelves I had various "general" books on Win32, MFC and .NET coding - stuff like the Charles Petzold books. I also had some MCSA self-paced coursework tutorial texts. Finally, I had two extremely big sets of manuals - five volumes of Visual C++ documentation covering the language itself, the run-time, the MFC (2 volumes worth), and the standard template library. I also had an additional five volumes providing similar documentation for Win32 as a whole, including a book on the Common Controls, one on GDI, one on the base system functions and so on. Both of these sets were expensive - $150 list, $92 from somewhere like Bookpool and took up a good eighteen inches of shelf space each.
They were not bedtime reading, they were not always accurate, but they were there. The combination of stuff like Programming Windows With MFC and Programming Windows with these reference libraries were invaluable. Anything you needed to know was in there, quite often with examples. While Microsoft don't seem to have published a similar mammoth library for .NET, take a look at the shelves in Barnes and Noble - books on every .NET related subject you can think of. I'm currently reading the .NET IL Assembler book, just for fun.
Now, looking over at the new Mac section of my bookshelf I see two O'Reilly titles and Aaron Hillegaas' "Cocoa Programming For Mac OS X". Two of the three books are good ("Learning Cocoa" isn't). However, they're all rather slim counterparts to stuff like Programming Windows With MFC, and they're all (as you'd expect) quite focused on the GUI side of the Cocoa frameworks.
What I also see is a huge blank space where any sort of reference materials should be. Aha, it's online, I discover. I go online, muttering unhappily (I like online documentation as a supplement to a Real Book, not as a replacement for it) and find the relevant documentation on Apple's developer site.
Helpfully, they've separated the information into the Application and Foundation frameworks. Unhelpfully, the lists of Classes, Protocols, etc, are sorted alphabetically, which is an interesting idea when every class name starts with 'NS'.
I then spent half an hour trying to find the exact information I needed, literally by randomly threading through the documentation until I hit the information I was looking for. On a couple of occasions (this may have been fixed since) I found missing info (literally methods that something along the lines of "To Be Written" as their description).
So there's one possible reason for the slow rate of migration to Cocoa - once you're past the stuff the available books cover, you're thrown in at the deep-end with nothing but online documentation that's of variable quality and that isn't in an organizational framework (pun no intended) more sophisticated than that of man pages.
I don't think it's a coincidence that the places that *are* churning out good Cocoa software are those with roots in the NeXT era. From what I can see, references titles of the sort Cocoa lacks did used to be available for NextStep at one point.
Until Apple takes documentation seriously (and I do see this as their responsibility, it's their OS after all) Cocoa isn't going anywhere fast. I'll admit that I'm making progress - I've got half a dozen little projects at various stages of development, most of the "get familiar with the platform, not actually of much use to anybody" variety. It's ironic that while tools like Interface Builder make it possible to produce an almost fully functional interface while writing almost no application code in next to no time at all, once you get past the GUI you tend to get bogged down trying to get what you previously considered the easy bit of the code finished.
I'll admit that some of this is my own fault - I've got a pretty good Unix background and could use the BSD layer to do the rest- but I'm determined to do it properly, using the Cocoa classes provided.
Argh, sorry, just venting. I think it was running across a reference to my long-lost copy of De Re Atari this morning that did it. Now *that* was documentation.
