The joys of cocoa and Objective C programming
In earlier blogs, I must have complained about the lack of apple support because figuring out how to talk to a USB device seemed so hard. But now I think it is amazing that I was able to use some apple code without any understanding of the structure of the code, and talk to my data both synchronously and asynchronously in USB mode. (I did not tackle the HID side of the story yet).
This is not the first time I have “lifted” some piece of code, assembler code, C functions, etc, because that code does the job, without worrying too much about how I could write that bit of code myself.
But this time, I backed off from the light stone project and I am taking the time to learn Cocoa and Objective C. Ail Ail Ail. MAMA MIA! This is not at all like learning a programming language. It is like learning a high level language like Matlab, Sas, except that it is NOT user friendly, it is programmer friendly, maybe. I have been trying to figure out why learning this “language” blocks me.
A simple example from chapter 14 from Hillegass’s book. This example is supposed to dazzle us with the ease with which we can create a graphic window and draw on it. This ease is achieved by having all the work of creating windows all done for us by functions already written by apple.
But unlike a program like Matlab which hides the bells and whistles from beginners, Cocoa requires you to grab 20 different threads and weave them together. For someone like me who functions on understanding and not on memory, this is very taxing. Not unlike a cooking recipee, except you don’t choose where the ingredients are kept. grab a project from the “File” menu, create a new class from the class menu on “main menu.nib” then grab an icon from “cocoa containers” and drag it on “window”, find the “info” option on the “tools” menu on the “interface builder” … On and on! And I am supposed to remember all this for all the different kinds of interface??? Yak.
The other thing that blocks me is the arbitrariness of the code which is nicely swept under the carpet in the book. Page 224 instructs us to enter the code
– (void)drawRect:(NSRect)rect
{
NSRect bounds = [self bounds];
[[NSColor redColor] set];
[NSBezierPath fillRect:bounds];
}
Voila, no explanation as to what this code does, how it is structured, why this particular code.
The miracle tool on the mac is AppKiDo 0.94. In the kindom of the blind, it is the stick that may just save you from axphyxiation and death from despair.
Type in the method “bounds”, and you find it belongs to NSview. It returns the windows size and coordinates.
type in the method “redColor”, and you find it is a class method which belongs to NSVview.
it is a class method because it is not applied on an instance.
OK so you have an RGB code, what does “set” do? Too many possibilities, better to go to the window, click on NSObject, click on NSColor look under all classes methods and all instances methods, and there is “set”, under instance methods. So apparently redColor applies to a class, but returns an instance, and so “set” is and instance method that says use this color for future drawing. Clear as Mud this beautiful code, no?
NSBezierPath is a class, so fillRect is a class method. it fills the rectangle with the above color. Note that NSArray is another class under NSobject. Now with NSArray, you created an instance of the class with alloc and init, before you used it. Why in this case, we would act on a class to draw in a window instance. Well that is the arbitrariness I am talking about.
At the level of the programmers, it is all very clear and beautiful and grammatical, and built with simple rules all developers can use to build these beautiful programs the user craves for her/his new Mac OSX platform. But at the level of the beginning user, it is all a medley of contradictory invocations best learned by memory. How can such a language replace basic C? YAK.
anne
October 30, 2005 @ 1:53 pm
I am an engineer, at some point or other as a student twenty years ago, I used most of the languages of the time, C, basic, Perl, Fortran, APL. To me they all have a very similar structure, just surface differences, like different spelling basically.
I have heard about object programming for a long time, but I was told to leave C++ well alone. Now with objective C, and maybe Java next year, I am getting into more modern languageswhich are much harder to learn, but can achieve more sophisticated display/control of the computer.
Thanks for posting, I was interested to see the websites/forums you have collected.
Bob
November 5, 2005 @ 3:20 pm
It’s a shame you’ve come so late to object oriented languages. As it is a totally different way of structuring your code. It might be wise to do some light reading on the conceptual framework as you could more readily understand the cocoa scheme. As with other large frameworks the code base will take a long time to become really familiar. It’s the price for so much usable code with the complication of new a new language. Apple also has some training DVDs I believe.
anne
November 5, 2005 @ 3:59 pm
I read Ruby was an object oriented program much easier to learn. I may learn that after objective C. If I can do all I need to do, it does not matter that it is not Java. I saw a little snipet comparing Java hello world to Rubi hello world. Rubi was a delight, Java a nightmare.
michael
November 6, 2005 @ 7:15 am
I had exactly the same problem when i first endevoured to get into the wonderful world of programming; browsing through the apple site and seeing that i can develop all the applications i could ever dream of with xcode and obj-c. after installing xcode unto my mac i was completely dis-illusioned and gave up after a few days. leaving it for a few months i did some research and decided to start a bit smaller, with python. after learning the basics of programming itself, i got bored. a friend helped me convert all teh knowledge i had gained from python into c++, found an ancient copy of the idiots guide to c++. started a few months ago, 3/4 of the way through the book. anyway… long story short, obj-c is definetly not easy and definetly not for beginners
Dave
November 6, 2005 @ 12:58 pm
Anne,
If you’re getting stuck on the syntax, you’re getting too far ahead of yourself. Make sure you master the stuff in the earlier chapters (and read Apple’s online doc on “intro to Obj-C”) first. Learning Obj-C takes a day or two, learning all of the Cocoa APIs takes a lifetime, but it’s rare that you’re going to need _all_ of them, and that’s what option double click is for- you have a dictionary built into XCode, don’t be afraid to use it and don’t be surprised when beginning that you don’t know everything.
I found the code snippet you’re talking about clear as crystal.
The more you use Cocoa, the more you’ll realize that things are not put together in an arbitrary way.
Erik
February 15, 2006 @ 9:21 pm
It is interesting to read beginners take on Objective-C. And I can understand both the ones that say Objective-C is hard and the ones who say it is easy and buitiful.
When I was not as experienced programmer, I had a look at Objective-C. I already knew C++ (but still not enough to understand that I really didn’t understand the language fully 🙂 ). Objective-C then looked alien, ugly and incomperhensible to me. I didn’t understand why people said it was easy to learn. It seemed like such a much bigger step than C++. Since C++ kept the C syntax when dealing with classes and methods.
It is not until much later like now that I wonder how I could ever have thought Objective-C was so difficult. Now I find it easy and beautiful. And I think most of the reason for this is that I had played around with Smalltalk in the meantime.
So Anne, thrust me, when you got more into OO thinking. The ObjC way of doing things will not seem as strange as now. They will in fact seem natural.
With regards to NSBezierPath, it isn’t so strange what why a class method is used for fillRect. Because why would you want to make an instance to fill a rect? What should that instance represent? When calling bezierPath makes more sense to return an instance though. Because the instance can represent a bezier path that can be extented with method calls or combined with other paths etc.
So for anybody who wants to get into ObjC, maybe to like me. Play around a little bit with Smalltalk first. I think ObjC way of thinking will come more natural then.
anne
February 19, 2006 @ 3:02 pm
After a few months learning other things, mysql, ruby, ruby on rails, opengl, I look back on objective C and what I remember are all the in your face technical details a beginner was supposed to understand, garbage collection, class versus instance method, maintaining an h file… I am so much happier with ruby. I haven’t had to deal with any of that, and I am learning to program in OOP ways, building classes, methods, passing objects… And yes, I think that when I am really comfortable with ruby, it won’t be too bad to take on Objective’s C, I will have mastered all the fun part, and I will be able to learn the housecleaning bit if I need to, just gritting my teeth a bit.