Well, this is really old news by now. I wanted to post something about it earlier, but never seemed to find the time.
Apparently there was a mixup at MacTech magazine, and my two-part article on developing productivity applications was printed out of order. Part II came out in February's issue. I'm not sure whether Part I will follow in March.
However, there is an upside to this. The good folks at MacTech have released both articles in their entirety onto the web. So, I encourage you to check them out:
Part I: http://www.mactech.com/articles/mactech/Vol.25/25.03/iPhoneProductivityApplicationsPart1/
Part II: http://www.mactech.com/articles/mactech/Vol.25/25.02/iPhoneProductivityApplicationsPart2/
I'm also currently working on a third iPhone article, this time focusing on immersive apps, images and Quartz 2d.
-Rich-
Wednesday, February 25, 2009
Wednesday, February 4, 2009
Things that bug me about Objective-C (and iPhone development)
Ok, before I get started, don't get me wrong. Objective-C is still one of my favorite programming languages. But, as I continue to use it, I can't help but feel that it has some rough edges.
First, it has the same essential flaw as Java. It's not a pure Object-oriented language. There is this dichotomy between things that are objects and things that are not. For example, you cannot put a raw int or a c-style array into an NSArray--not without wrapping it first.
In some ways, this gives us a lot of power. We can drop down and write lower-level code when the performance demands require it. And, when working on a limited device (like the iPhone), those demands can be frequent. But I feel it's a bad design choice. It encourages mixing C and Objective-C, and I think the two programming styles are best kept separate.
I guess the biggest problem with Objective-C is really just C. Anytime I have to use C code, I loose many of the strengths and benefits of using Objective-C. I also expose myself to pointer and array-overrun errors. These are often the hardest to debug, since they may appear as mysterious errors in unrelated parts of the application.
And then we get to the iPhone. I love Xcode and I love the iPhone, but sometimes the two just don't play well together. Yes, debugger, I'm looking at you. I mean, really. What's up with the breakpoints? Sometimes they work. Sometimes they don't. Sometimes I can trick them into working again by cleaning all targets and rebuilding. Other times I have to reboot the computer. One time I could only fix the problem by reinstalling Xcode.
OK, that's it. Enough complaining for one day.
-Rich-
First, it has the same essential flaw as Java. It's not a pure Object-oriented language. There is this dichotomy between things that are objects and things that are not. For example, you cannot put a raw int or a c-style array into an NSArray--not without wrapping it first.
In some ways, this gives us a lot of power. We can drop down and write lower-level code when the performance demands require it. And, when working on a limited device (like the iPhone), those demands can be frequent. But I feel it's a bad design choice. It encourages mixing C and Objective-C, and I think the two programming styles are best kept separate.
I guess the biggest problem with Objective-C is really just C. Anytime I have to use C code, I loose many of the strengths and benefits of using Objective-C. I also expose myself to pointer and array-overrun errors. These are often the hardest to debug, since they may appear as mysterious errors in unrelated parts of the application.
And then we get to the iPhone. I love Xcode and I love the iPhone, but sometimes the two just don't play well together. Yes, debugger, I'm looking at you. I mean, really. What's up with the breakpoints? Sometimes they work. Sometimes they don't. Sometimes I can trick them into working again by cleaning all targets and rebuilding. Other times I have to reboot the computer. One time I could only fix the problem by reinstalling Xcode.
OK, that's it. Enough complaining for one day.
-Rich-
Subscribe to:
Posts (Atom)
