I recently came to Objective-C/Cocoa after over two decades of developing C and C++ and for the past several years programming in large scale enterprise Java.
Here are my impressions to date. These are just my opinions. I could be wrong.
XCode: Its adequate for development but my productivity has dropped significantly since using it. I'm sure it will get better but the whole environment just seems like I've stepped back in time. They are in serious need of catch up with the rest of the industry. Its about the little things that make an IDE feel polished.
Syntax: I do not find the objective-C message passing syntax hard to understand but I do find it a bit cumbersome to work with. Having to go back and add [ while you code a line is a pain. Also the aligning of : on method calls is a pain when you change the name of a selector you have to go back and realign the :s again. Perhaps XCode will get with the program and start handling those things for me. Note: Yes XCode does help a little by allowing you to align with a simple tab. They could do more however. I hear that the next version balances the [] for you. A welcome addition. Keep it coming!
Interfaces: The @interface keyword is misnamed. It should have been @class since you are basically writing an implementation. Interfaces do NOT have instance variables. Actually you forward declare an interface with @class so this is even more evidence that something wasn't thought out very carefully.
Protocols: The @protocol should really be @interface and @protocol should just go away. A protocol is really what an interface is. Just a collection of methods and or properties with no implementation. Also it would allow you to code to just Interface rather than id<Protocol> which is just needless syntax.
One small nit for the compiler. Since all Obj-C objects are pointer based then why not just allow the Class var syntax? Why must I always supply the * when the only choice is a *? Again this is just needless syntax the compiler can infer. It does it with "id" it can do it with any Obj-C class. Another symptom of its un-pure origins of being grafted onto C.
Categories: A cute idea but in the wrong hands can be utterly deadly. Talk about being able to shoot yourself in the foot. I can just reopen a class at any time and change an existing method or add a new one. Please. Do I really have to go into all the reasons why this is bad?
Delegation: I've been using delegation in other languages for years. I use inheritance for strictly "is a" relationships. If all you are doing is changing the behavior/look/feel of an object then delegation is the preferred method.
Memory Management: I really thought we were past this. I mean really. Manual memory management is an endless source of bugs. Garbage collection has come to Cocoa finally but not across the board. The iPhone doesn't support it so again you are forced to code to the LCD and deal with memory management yourself. Again another way it feels like I've stepped back into the past.
Stack based objects: I've found myself using Obj-C++ rather than Obj-C to get access to stack based objects to hide alot of the manual memory management. I've made classes that deal with the retain/release cruft and automatically perform those within the scopes I choose. Not perfect but better than all the manual retain/release/autorelease cluttering up my code. It also makes the code more portable from the iPhone to the garbage collected environment of the desktop.
I am finding Obj-C++ far superior than Obj-C. I can utilize the best features from 3 languages rather than 2.
Cocoa: As a framework it is adequate. What it does it does fairly well but I find myself writing so much more code in this environment than in other environments. Perhaps this will improve with experience. The availability of 3rd party libraries is also next to non-existent when compared to other environments.
Portability: There are objective-c compilers available for other platforms if you can find them but nothing main stream. So in order to reuse your code on other platforms you end up writing most of your non-ui code in portable C or C++ and then writing only a thin interface layer in cocoa that puts up the UI and calls into the backend code so you lose all the benefits of coding in Cocoa/Obj-C. Whatever happened to Cocoa on other platforms?
I am still new to Cocoa and I'm sure some of my pain points will lesson as I learn workarounds or alternative ways of doing things but so far I must admit that I am not so impressed as all the hype would lead one to believe.
by Maven — Aug 13
Here are my impressions to date. These are just my opinions. I could be wrong.
XCode: Its adequate for development but my productivity has dropped significantly since using it. I'm sure it will get better but the whole environment just seems like I've stepped back in time. They are in serious need of catch up with the rest of the industry. Its about the little things that make an IDE feel polished.
Syntax: I do not find the objective-C message passing syntax hard to understand but I do find it a bit cumbersome to work with. Having to go back and add [ while you code a line is a pain. Also the aligning of : on method calls is a pain when you change the name of a selector you have to go back and realign the :s again. Perhaps XCode will get with the program and start handling those things for me. Note: Yes XCode does help a little by allowing you to align with a simple tab. They could do more however. I hear that the next version balances the [] for you. A welcome addition. Keep it coming!
Interfaces: The @interface keyword is misnamed. It should have been @class since you are basically writing an implementation. Interfaces do NOT have instance variables. Actually you forward declare an interface with @class so this is even more evidence that something wasn't thought out very carefully.
Protocols: The @protocol should really be @interface and @protocol should just go away. A protocol is really what an interface is. Just a collection of methods and or properties with no implementation. Also it would allow you to code to just Interface rather than id<Protocol> which is just needless syntax.
One small nit for the compiler. Since all Obj-C objects are pointer based then why not just allow the Class var syntax? Why must I always supply the * when the only choice is a *? Again this is just needless syntax the compiler can infer. It does it with "id" it can do it with any Obj-C class. Another symptom of its un-pure origins of being grafted onto C.
Categories: A cute idea but in the wrong hands can be utterly deadly. Talk about being able to shoot yourself in the foot. I can just reopen a class at any time and change an existing method or add a new one. Please. Do I really have to go into all the reasons why this is bad?
Delegation: I've been using delegation in other languages for years. I use inheritance for strictly "is a" relationships. If all you are doing is changing the behavior/look/feel of an object then delegation is the preferred method.
Memory Management: I really thought we were past this. I mean really. Manual memory management is an endless source of bugs. Garbage collection has come to Cocoa finally but not across the board. The iPhone doesn't support it so again you are forced to code to the LCD and deal with memory management yourself. Again another way it feels like I've stepped back into the past.
Stack based objects: I've found myself using Obj-C++ rather than Obj-C to get access to stack based objects to hide alot of the manual memory management. I've made classes that deal with the retain/release cruft and automatically perform those within the scopes I choose. Not perfect but better than all the manual retain/release/autorelease cluttering up my code. It also makes the code more portable from the iPhone to the garbage collected environment of the desktop.
I am finding Obj-C++ far superior than Obj-C. I can utilize the best features from 3 languages rather than 2.
Cocoa: As a framework it is adequate. What it does it does fairly well but I find myself writing so much more code in this environment than in other environments. Perhaps this will improve with experience. The availability of 3rd party libraries is also next to non-existent when compared to other environments.
Portability: There are objective-c compilers available for other platforms if you can find them but nothing main stream. So in order to reuse your code on other platforms you end up writing most of your non-ui code in portable C or C++ and then writing only a thin interface layer in cocoa that puts up the UI and calls into the backend code so you lose all the benefits of coding in Cocoa/Obj-C. Whatever happened to Cocoa on other platforms?
I am still new to Cocoa and I'm sure some of my pain points will lesson as I learn workarounds or alternative ways of doing things but so far I must admit that I am not so impressed as all the hype would lead one to believe.
Hopefully things will improve with time.