![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Co... co...
May. 22nd, 2009 01:11 pmWork had those of us not going to China sent to a 'Big Nerd Ranch' this week, where we spent the whole week, nine hours a day, learning about Cocoa. Cocoa's apple's objective-C based app-kit, sort of like the microsoft foundation classes only different, because instead of windows using C++, it's on the macintosh and uses objective C.
For most of the week, we learned how you really *could* make simple applications quickly, as long as you somehow magically knew not only the APIs to call, but where to find the hooks buried in the nested dropdowns of the tab of the inspector of the object that you magically knew to pull from the library after first writing the class definition that would give it the behavior you needed.
Since we were mostly doing lab exercises out of a book, we did magically know. I think that was kind of the point of the course -- without that it'd be hopeless. The documnetation is all a reference that assumes you already know what you're doing and are maybe just confused about the types of the parameters or something.
Anyway, through the whole week it was also kind of terrifying how objective C or possibly apple's framework depending on where you draw the line loves to allocate millions of tiny objects that get released 'sometime'. Leaking the memory isn't the problem -- you can even turn on garbage collection or whatever. It's allocating all the objects that's sort of oh-my-fucking-god-you-can't-be-serious. Things you'd normally do with, say, pointer math, get done by allocating multiple objects. Add two numbers? That takes an allocation. Building an array of 10 integers? That takes something like two dozen allocations *that I know about*. All of this completely hidden from the programmer -- I think you probably get an exeption or something if it fails, or maybe it returns nil and your code just silently does nothing.
This design philosophy technically works, and even has some advantages, but.... well... now I know how one of our components that was following a similar philosophy managed to be a thousand times slower than the functional code it replaced.
There's also stupid cocoa tricks like serializing an NSColor. An NSColor is a fiendishly complex structure that holds, um, a color. Four numbers from 0 to 65536. 258 bytes after getting pushed through the archiver.
Oh, and the compiler is really stupid. Objective C replaces function calls with 'messages' which can be sent to any object... they just throw an exception at runtime if the target doesn't handle them. And you're usually using inheritance and overriding other messages anyway. So there was a lot of hair-pulling over typos that a sane compiler would have at *least* warned about but objective C thought were totally fine. In a couple cases, your app would even seem to work until hours and hours later when you were doing something else and suddenly realized that the array you'd been fucking around with had been silently allocated behind your back by the tableview because you'd forgotten to actually hook the table up to your controller.
On the very last day (this morning), I was working through some optional exercises related to animation, and happened to stumble across how to interact with C-based core-graphics code (interacting with other C code is just a matter of passing a 'this' 'pointer' explicitly). We were out of time before I actually got around to testing it, but it seemed simple enough in theory.
For most of the week, we learned how you really *could* make simple applications quickly, as long as you somehow magically knew not only the APIs to call, but where to find the hooks buried in the nested dropdowns of the tab of the inspector of the object that you magically knew to pull from the library after first writing the class definition that would give it the behavior you needed.
Since we were mostly doing lab exercises out of a book, we did magically know. I think that was kind of the point of the course -- without that it'd be hopeless. The documnetation is all a reference that assumes you already know what you're doing and are maybe just confused about the types of the parameters or something.
Anyway, through the whole week it was also kind of terrifying how objective C or possibly apple's framework depending on where you draw the line loves to allocate millions of tiny objects that get released 'sometime'. Leaking the memory isn't the problem -- you can even turn on garbage collection or whatever. It's allocating all the objects that's sort of oh-my-fucking-god-you-can't-be-serious. Things you'd normally do with, say, pointer math, get done by allocating multiple objects. Add two numbers? That takes an allocation. Building an array of 10 integers? That takes something like two dozen allocations *that I know about*. All of this completely hidden from the programmer -- I think you probably get an exeption or something if it fails, or maybe it returns nil and your code just silently does nothing.
This design philosophy technically works, and even has some advantages, but.... well... now I know how one of our components that was following a similar philosophy managed to be a thousand times slower than the functional code it replaced.
There's also stupid cocoa tricks like serializing an NSColor. An NSColor is a fiendishly complex structure that holds, um, a color. Four numbers from 0 to 65536. 258 bytes after getting pushed through the archiver.
Oh, and the compiler is really stupid. Objective C replaces function calls with 'messages' which can be sent to any object... they just throw an exception at runtime if the target doesn't handle them. And you're usually using inheritance and overriding other messages anyway. So there was a lot of hair-pulling over typos that a sane compiler would have at *least* warned about but objective C thought were totally fine. In a couple cases, your app would even seem to work until hours and hours later when you were doing something else and suddenly realized that the array you'd been fucking around with had been silently allocated behind your back by the tableview because you'd forgotten to actually hook the table up to your controller.
On the very last day (this morning), I was working through some optional exercises related to animation, and happened to stumble across how to interact with C-based core-graphics code (interacting with other C code is just a matter of passing a 'this' 'pointer' explicitly). We were out of time before I actually got around to testing it, but it seemed simple enough in theory.
