What Do People Find Challenging About Cocoa?
I sent out a general request on Twitter, asking what specifically the biggest obstacle was when you first started learning Cocoa. Out of the roughly 118 responses I got back, no one topic completely dominated.This obviously isn't a strictly scientific study. I had to glean intent from some of the responses, and didn't include anything that came up less than twice. Also, I counted many responses for two categories. So if someone said "Objective-C was confusing at first, coming from a Java background", that would be counted as both "Objective-C" and "Used to Java and C++".
Objective-C: 19%
A lot of the votes here were broken down into other sections as well, so this is sort of an umbrella category. Many specifically cited how things were different from Java or C++ on Windows. The syntax itself was frequently mentioned, as was reference counting to manage memory.
Overall, this is the least surprising result since the Objective-C syntax is the single biggest difference from most other programming environments. If you asked PHP programmers what they found odd about learning Rails, Ruby would certainly be one the most common answers.
Worth noting, though, that very few said that they still hold a poor opinion of the language. It was just the initial introduction that was rough.
I Didn't Know ANSI C: 12%
Veteran programers may be surprised by this, but this is actually pretty close to what I expected. I've run into countless people in the last few years who had just started to learn Cocoa and had never even flipped the first page of K&R.
In the NextStep era, the big deal was convincing people to switch from pure C to higher-level objects, but now things have flipped. A lot of people coming to Cocoa today are used to web scripting languages, and have often never even used malloc before. Cocoa may be the sole reason they have any contact with gcc.
Cocoa is Really Big: 11%
Even just sticking to AppKit, UIKit, and Foundation, Cocoa is quite big. There are hundreds of classes in the core frameworks, and more than 80 entries in Leopard's /System/Library/Frameworks/ directory. That count doesn't even include the clusters of API buried in umbrella frameworks.
It can take quite a while to learn what's available to you, and then from there learn the pros and cons of each API so that you know when to use which one. This the is meat of what "learning Cocoa" actually is.
Memory Management: 10%
Relatively low on the list. This was mostly people who had come from Java or a scripting language and suddenly had to deal with reference counting — knowing how to use retain, release, and autorelease correctly.
Interface Builder and NIBs/XIBs: 10%
If you're used to seeing all of your program literally in code, Interface Builder and NIB/XIB files can be a bit jarring. The biggest complaint was that it feels like "magic" because you dont't know what Interface Builder is actually doing. Some said using Cocoa Bindings in Interface Builder enhanced the feeling of not being completely in control of what's going on.
Personally, I was immediately sold on the idea of using a visual layout tool to get all of the basic infrastructure up, and thrilled that I didn't have to type all of that out by hand each time. I admit I've never really understood the resistance to Interface Builder, but clearly not everyone feels that way at first. Just as with Objective-C, though, most said that now know their way around Interface Builder.
I Was Used to Java or C++: 10%
No big mystery here. Cocoa has pretty different view of life than Java and C++. You can learn the Objective-C syntax in a week, but you still might be trying to find the Cocoa equivalent of a particular class, and trying to still do things in the Java or C++ way. It takes a while to get familiar with not just the what of Cocoa but the why and how.
Delegates: 8%
I was surprised how many people specifically called out delegates as a stumbling block in learning Cocoa. The overall feedback was that it wasn't always clear how delegates fit into the big picture or when you should use them.
I think this might just be learning part of of bigger Cocoa philosophy: waiting for the framework to prompt you for data rather than actively going out and setting values on things. My guess is delegate callbacks seem more natural to Rails folks, but it's apparently not as common in other frameworks.
Overall Cocoa Model: 8%
These were the cases where the individual bits and pieces made some sense, but it wasn't clear how everything fits together. I see a lot of variations on the question "how do I pass information from one class to another?"
Cocoa has a few key techniques are used over and over again throughout nearly all of the frameworks, and once you learn those, the curve flattens out. But until then, it may seem like you're just doing a series of random things that seem to have no overall meaning. If so, take heart — you're in good company. Very bright, experienced programmers feel this way at first.
I Didn't Know Object-Oriented Programming: 8%
I think this is one of the biggest shifts since NextStep. Decades ago, this would have been much higher on the list. The interpretation of object-oriented patterns varies between languages, but nearly all popular languages today feature classes and objects in some way. It's rare to see strictly procedural programming patterns for desktop or web programming.
Learning How Documentation is Structured: 5%
Some did express a learning curve in reading the official documentation, but there seemed to be a general feeling that it has improved a lot over time.
Cocoa Bindings: 5%
A few specifically called out challenges with learning how Cocoa Bindings or Key-Value Coding and Key-Value Observing work, some specifically cited the overlap in "magic" with Interface Builder.
Xcode: 3%
Very few complaints about the learning curve in using Xcode to build projects. For the most part, people seem to get it.
What Do People Find Challenging About Cocoa?
Posted May 16, 2009 — 51 comments below
Posted May 16, 2009 — 51 comments below
Guy — May 16, 09 6736
Obviously, the systems and frameworks don't have much to do with each other - but still, if I'm familiar with .Net and know a lot about it already - just having somewhere to type in a word I know from that world that can give me something related to that in the Cocoa world would be a huge help.
Thoughts anyone?
Steve Weller — May 16, 09 6737
A similar survey asking what people found easiest about learning Cocoa would be very interesting too.
lakshmivyas — May 16, 09 6738
When I wanted to do a little bit more, it started taking me more time & research than I anticipated. A lot of material available through Google(many thanks to you as well, Scott) helps with getting started on Cocoa. However, both the API and the available supporting documents do not make the transition from developing play apps to real apps(from using magic to creating magic) easier.
Jesse — May 16, 09 6739
Sometimes I wish Xcode could support JAVA IDE style inline API reference pop-ups. Having to flip to the documentation and back again can be quite irritating. Having instant access to a reference can really speed up learning the individual class interfaces and just streamlines the workflow in general. Also, having a firm grasp of design patterns (and how they are modified in Objective-C land) is also a must.
Kevin Walzer — May 16, 09 6740
Mike Rundle — May 16, 09 6741
Scott Stevenson — May 16, 09 6744
It's easy to miss, but Xcode has Help > Show Research Assistant.
Philippe — May 16, 09 6745
It's my experience that if you show this along with -awakeFromNib, people get it much faster.
Scott — May 16, 09 6746
I would love to read a tutorial that outlines a problem that a developer wants to solve, and then walks the reader through the various ways they might want to structure the project to accomplish his solution to that problem. The tutorial could explore several different directions at various stages of the project and explain the pro's and con's of each path. I think learning why this project was designed the way it was (vs. some of the other ways it could have been implemented) would be incredibly valuable to people teaching themselves Cocoa.
Nice to see you are still posting here too. I'm not much on twitter, and I find your insights invaluable. Thanks for all you have done/still continue to do for the Cocoa community.
Chris L — May 16, 09 6747
Jerry Fan — May 16, 09 6748
I've also noticed a trend among more experienced Cocoa developers is the practice of 'avoiding sub-classing'. I'm not experienced enough to fully grasp why this is the case, but it seems to be the result of a rather primitive IDE (XCode), compared to a product like Visual Studio or Eclipse.
Can someone fill me in?
Lukhnos — May 16, 09 6749
@Jerry The practice is not avoiding subclassing. It is utilizing the delegate pattern wherever you can. That's how Cocoa projects tend to have a "flatter" class hierarchy than their equivalents in other languages. It doesn't have too much to do with the IDE.
Craig Demyanovich — May 16, 09 6750
Kenneth Barber — May 16, 09 6751
A. The IDE took a bit of getting used to.
B. The objective-c runtime and its dynamic nature had me intrigued, confused, and worried all at the same time. I thought of all of the things I could do with it and how easy somethings are in the language. I thought a little too much about it. My productivity dropped quite a bit as a started looking at the whole thing academically. It took me 6 months to bounce back although I am still prone to relapse.
C. Cocoa is yet another large api I have to come to grips with. This means yet another round of "which way is the best way to do ???". This has been the most time consuming part of learn to develop for either Cocoa or Cocoa Touch.
I code professional in C/C++ and C# using various libraries and IDEs. Going back and forth between them is sometimes frustrating. I must be getting old....
Adrian — May 16, 09 6752
Joshua Pennington — May 16, 09 6753
Michael Buckley — May 16, 09 6754
Objective-C's largest strength is arguably its dynamism, and in most cases, delegates allow for greater dynamism. Class hierarchies have rigid structures, which can cause problems in complex systems. Delegates, on the other hand, are flexible, and can even be changed at runtime. There are many tools in other languages to deal with these kinds of problems (e.g. multiple inheritance) which become unnecessary when using delegates.
Taz — May 16, 09 6755
Cocoa Kid — May 17, 09 6756
Richard — May 17, 09 6757
ssp — May 17, 09 6758
My impression is that documentation has improved a little since (but still is far from good), so that may have become easier. On the other hand additional non-trivial 'magic' technologies like Bindings or Core Data have been introduced which can be very powerful but which will make first steps much harder. I always find those the most problematic these days as they very easily leave you in situations in which you don't fully understand what's going on but would need to have that understanding to get the behaviour you want. And getting the behaviour you want will likely require more code than not using those advanced technologies (which smells a bit of FAIL if you ask me). An example may be something which should essentially a trivial one-click affair as setting up a combo box with bindings.
I also keep wondering how much easier Cocoa could seem if XCode's documentation browser weren't a POS that seems to be designed to make navigating documentation as hard as possible. The research assistant seems like a nice idea, but are you really using it? I found it to be so poorly implemented that XCode can't keep up with my typing.
Martin Pilkington — May 17, 09 6759
The idea with Cocoa is that you should be able to use existing classes to create new ones rather than subclassing. There are some classes intended to be subclassed a lot (NSObject, NSView, NSWindowController etc) but for the most part you are encouraged to use existing classes.
The other plus of this is you end up with fewer, but more powerful classes. Whereas Java has JButton, JToggleButton, JRadioButton, JCheckBox, Cocoa just has NSButton which does all of these.
@Taz: I suspect delegates can be confusing because they're not used particularly consistently. When designing an Objective-C class, how do you know when you should you use a delegate, a data source (which is a specialized delegate), or a notification? There's no particular rhyme or reason to their use within AppKit itself
Actually they are very consistent. When designing a class it's easy to decide what you need. A data source is when you need to supply data to populate a view. The "hard" thing is delegates vs notifications but it is a simple answer. Delegates are 1 to 1 relationships, notifications are 1 to many. If you want multiple objects to know about an event then use notifications. If you only want one object to know about it, or want something returned then use a delegate.,
Benjamin Dobson — May 17, 09 6760
Ulai Beekam — May 17, 09 6761
I already knew some C, C++, Java, PHP, HTML when I started learning Cocoa about a year ago. I had studied those other languages only for the sake of fooling around, and had never worked on any real projects (save for a website I did for someone). So again, it had only been playing around doing random, but mostly useless, things out of interest since I was like 13 years old.
When I came to Cocoa a year ago it was different. I had a real Mac application in mind that I wanted to do. That was a different experience than before. I therefore, picked up a copy of Hillegass' book, read the first 20 chapters, then read some Apple docs to more solidify my knowledge.
At this point I can answer your (uninteresting but valid nonetheless) question: The biggest hurdles to learning Cocoa, I found, were indeed a mixture of this normal stuff everybody is mentioning around here, like "different Obj-C syntax", "seems like magic", "bindings", "Nib files", "Xcode", etc. etc. But why does this question even need to be asked and answered at all?
First of all, when you learn something new, you come across new things�that's just the way it is. Second, if you read about it often enough (I had to read some chapters in Hillegass many times over to understand them), you will get it in the end. So is it just me or am I missing something? Because to me it seems a bit trivial that people will have troubles with certain things, but are bound to get them in the end. I'm sure you even guessed many of the replies you received, before even receiving them, Scott.
---------------
The biggest hurdle to overcome is to actually finish and release your first application. The very last challenge in the end of Hillegass' book, "Write a Cocoa application and get someone (not yourself) to use it", it by far the hardest exercise in the book. And this is after supposedly having learnt Cocoa!
So the question you should rather be asking is: After learning the basics of Cocoa�which you will do after a few months by just reading and practicing the material often enough�what are/were your biggest stumbling blocks for working on your first real application?
This question can lead to much more interesting answers, I think. So can you do another Twitter post asking that question instead, and write a similar blog post about the answers you got? :)
Anyway, I conclude by giving six answers/thoughts to this question for myself:
1) Finding that Apple's docs have their limitations, and that you have to constantly Google/Cocoabuilder/Cocoadev things up to figure out how to do things.
2) Get around occasional bugs (believe it or not, they are there) you come across in Cocoa.
3) Spending a month writing something that you ended up not using at all. Even if you ended up learning a lot, it still was an obstacle in getting the app released on time :)
4) Finding out that you forgot what you read months ago and had to read it again. This time, though, you know where to look. Also you more solidify your knowledge because you are instantly using what you are reading.
5) Not knowing what makes Cocoa so great. Since one has not written any real applications in any other framework, one has nothing to compare oneself to, and cannot really understand why everybody is saying Cocoa is so great. One is just using it because one wants to write some Mac app :) (In fact, can someone answer this? Is Cocoa really that great compared to say .NET in Windows?)
6) A general feeling that one is taking too long time to code a seemingly simple app :( In the sense that if I showed a relative the current state of my app and told him how long it has taken me, he wouldn't be too impressed. (Any words of reassurance would be appreciated here.)
jon — May 17, 09 6762
for instance, simply taking the example project "miniBrowser" that exists on your Development directory, and changing it to use Garbage collection in the build settings, no other changes, that simple change, will produce a browser that doesn't load all of the page at "www.ebay.com"...
why is it? because of some conflict in an unbelievably complex interaction between parts of the system...
they need to find these things and get them figured out FAST, as it is, i put in this bug report, but i don't expect to hear anything for years about it... (like another bug report i put in last year, with no word) that is infuriating...
and i'm a brand new Cocoa user. I am figuring out everything, except the most complex, but my biggest stumbling blocks are copying code directly from some example that should do something, and it doesn't do it through no fault of my own, the fault being complex bugs in how one part of the system acts with another part, it is amazing how often i've found this...
i can give even more examples of this very thing if you wish...
Todd — May 17, 09 6763
1. Objective-C and having to go back and deal with header files. Come on, now
2. The nuances of UI widgets and interface builder. This was very different from Swing, Winforms, gtk and frankly everything else known. Of course the simple GUIs with handful of elements was very ease to pickup, but once I started needing multiple tabs, custom controls and advanced coordination between element...whoa.
3. Lack of 3rd party cocoa libraries. Without these I had to write stuff from scratch...ugh
4. No datagrid for displaying/sorting/filter database data.
devnull — May 17, 09 6764
Great question and I would agree it's Objective-C I think with 2.0 it becomes more approachable. Watching the free Stanford Podcasts for iPhone development gives you a better understanding.
XCode and Legacy code is straight forward http://macateeny.blogspot.com/2007/08/xcode-running-3d-opengl-classics-there.html
Enjoyed the post /devnull
Todd — May 18, 09 6768
In XCode/IB it seems that you do the exact opposite, in that you write the code that you want to happen first and then connect it back to the GUI.
I'm sure part of this is that I am rusty, in that I have been doing mostly SQL and scripting for the past few years, but it definitely takes some getting used to.
Philippe — May 18, 09 6769
You can do MVC with Visual Studio. And you can put all your business logic in your IBActions. But my experience has been that VS makes it all too easy to do the wrong thing, which quickly leads to an unmaintainable mess of an application.
Kenneth Barber — May 18, 09 6770
In fact the MFC coupled with some COM/ActiveX and WIN32 knowledge was pretty powerful and there is still lots of legacy dev work out there for it.
Zach — May 18, 09 6771
Paul Collins — May 18, 09 6773
Then, in the controller header file, declare IBObject ivars for the GUI objects I need access to from code, and the IBAction methods I want to call from the GUI. Wire them up in IB, then write the actual methods in the .m file. There's a little bit of back and forth, but now that IB auto-updates from .h file changes, its easy.
When I (long ago) learned Cocoa, learning good memory management was the main early hurdle. Oh, and figuring out how to design my 2nd app after CurrencyConverter. Then I got to learn gdb so I could attach to and debug a root process (still have trouble getting Xcode running as root (using sudo open)).
P.S. @Todd(1st): might as well embrace headers, they are here to stay, and get comfy with cmd-option-up-arrow.
Davide — May 19, 09 6776
I'm studying Cocoa right now, and I don't see any big obstacle to pass at all! I came from Delphi (unfortunately there is not yet Delphi for Macs, only freepascal & Lazarus) and of course it's a new world for me, but even if different I see a lot of analogies with Object Pascal.
Just for the records, I'm not a professional programmer, I do it just for little requests, personal needs and passions for macs!.
Davide
Preston — May 27, 09 6781
The resistance has to do with not understanding what Interface Builder is creating in a Nib file since it doesn't generate code as one might expect.
Steve — May 28, 09 6782
MySchizoBuddy — May 28, 09 6783
Dave Jewell — Jun 03, 09 6800
All these tools have a well-integrated visual layout designer. Did I emphasise well-integrated? Yes, because IB ....errr.... isn't. It just about plays ball with Xcode, but there is a world of difference between (say) Delphi's polished IDE on the one hand, and the Jekyll / Hyde combination of Xcode / IB on the other.
In C#, if I want to resize a control, I just do it instantly there and then - I don't need to call up another app to do the job. If I want to add a button and have some code execute when I click the button, I just drag the button onto a form, double-click the button, and there I am writing the code in the code editor. I love Cocoa as a framework, but the Xcode / IB partnership can trace its history back to Nextstep - and it shows. And don't get me started on all the weird and wonderful idiosyncrasies in IB. It's time IB was put out to pasture, and Xcode had an integrated, extensible layout designer of its own.
Dave
TerranceOXP — Jun 15, 09 6811
Bill Coleman — Jun 17, 09 6812
1) Objective-C. I think the biggest problem with Objective-C is that it is an odd mix of old ANSI C and Smalltalk features. There's not a lot of internal consistency between the two -- it's not a very "pure" language like Smalltalk or Java. It's certainly a whole lot simpler than C++, and developers ought not to have too much trouble with it, other than the unusual syntax for sending messages. I certainly understood the language ages ago.
2) Cocoa Frameworks. There's a whole lot to these frameworks. While it's not difficult to get a basic understanding of certain components, it's hard to wrap your brain around all the facilities embedded in Cocoa. Some components are very powerful and not very obvious (eg Key-Value Coding / Observing, Binding, CoreData). Developers trying to learn Cocoa face an enormous learning cliff to scale, because there's just a tremendous amount of material. The Hillegass book is the best I've seen.
3) Proper Technique. Even after you think you understand Cocoa, or are even able to write useful programs with it, there's always the issue of proper technique. This includes such subtleties as when to use a custom classes versus the standard classes, when to use delegates and which object is the right target of those delegation calls, when is it appropriate to use binding versus the old-fashioned push/pull from controls, when you could really benefit from Key-Value Coding / Observing, etc. There's an old saying on the CocoaDev list that if you having to do a lot of work to get something done with Cocoa, you are probably doing it wrong.
This last bit comes easy to the old hands at Cocoa, and is the hardest for them to express. To a newcomer, it looks like "magic" because it wasn't obvious why they made that choice. It may be a level of understanding of the frameworks that only comes through long practice.
John Joyce — Jun 20, 09 6815
Their only problem should be retain/release and using semicolons again.
C programmers, not experts, just a little exposure, will certainly get it.
Combination of Rails and C background? Almost home free except Rails docs are miles beyond just about anything else out there.
MacRuby shows this combination meaning a lot.
Coming from C++ or Java? You're definitely in a new land. Basic C++ is not so terribly different from C, but the STL is a lot more terse than Cocoa and the terms for things are certainly worlds apart at times.
Delegates. Yes. These can be mysterious at first. For lots of people. Not more than understanding "callbacks" in C or C++ or any other C-like language. This is where some sort of experience with a good framework / API will benefit people. PHP is often used Ad Hoc without frameworks. Not the best path to come from. Java... so different in terms of conventions from everything else (other than the basic C-like syntax) that this causes some stumbling.
Delegates are more conceptually clear if you've worked with other frameworks that are well thought out. Just saying...
Python? You'll do as well as Ruby folks for sure.
Doing Audio/Video/Graphics?? Well, if you came from a strong C++ or C background with that, you'll fit right in in that realm.
dev — Jul 03, 09 6823
XCode right? Is cocoa the other language to develop mac application?
goosesensor — Jul 31, 09 6842
xCode is a program that organizes your source files and a GUI for the GCC compiler (it's called an IDE, Integrated Development Environment)
Objecticve-C is an OOP language that is the mechanical means by which frameworks are used - it's the glue.
Cocoa is the set of frameworks that are your pre-made resources for doing stuff.
I suppose you could re-write your favorite procedural C program with Obj-C, using all the same frameworks and functions as before, but just organizing it in an OOP pattern.
Maven — Aug 13, 09 6847
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.
RobInNZ — Aug 24, 09 6853
One of the earlier posters echo's my major issue, in that there is no real guidance on best practise of how to lay out and structure a larger app in terms of classes, data objects etc.
EG I understand the basics behind OOP, but most of the examples you find on the net are usually related to conceptual ideas (eg a Car has a X doors, a certain size of engine, etc) as opposed to concrete programatic examples of a problem to be solved and the approach someone has taken, and why.
Memory management is certainly another issue, and one that I still havent really gotten my head around properly. And the interaction between IB / Xcode is a little confusing at times, especially when you are trying to figure out how to hook up bindings etc.
And bindings / coredata seem to work well when it does EXACTLY what you want, but when it doesnt, it becomes a bit of a confusing quagmire to figure out how to make it do what you want.
An example of this would be that I have an array of doubles (laptimes) that I want to do an average for. Bindings gives you the ability to do a @array.avg in IB, but I want to round that average to 3 decimal points (to prove milliseconds). Adding a number formatter to the label in IB causes an exception, and I dont seem to be able to make the display format field in IB do anything either.
And finally, yes, the size of the Cocoa frameworks, as well as seeming duplications of behaviour across multiple classes in the framework (eg only very slight differences).
Mitoman — Sep 14, 09 6865
Objective C is not a language thats easy to learn, such as Java or C#, even for a senior developer it still requires some adoption time.
Thats just my 2 cent
SomeDude — Sep 23, 09 6880
http://homepage.mac.com/aglee/downloads/appkido.html
Jon H — Sep 30, 09 6922
Yet somehow, STL code, (and C++ in general especially with templates) in the wild often looks to me like an ugly, confused, wordy, jumble of line noise, compared to Objective-C code.
Maybe you can do a lot more with a given language token, but those tokens bring with them a lot of cruft.
Jon H — Sep 30, 09 6923
That's what I hate about Windows editors. They're so restrictive. "You'll put the code HERE." What if I don't want it there?
I'm not a fan of UI builders that generate source code. And of course IB lets you wire objects together directly, obtaining useful behavior without any stops in source code at all.
Emo — Jan 05, 10 7074
Michael — Feb 16, 10 7459
Systems I have wrote space invaders with no problem:
C64 - 6502 assembly - around a month
Amiga - 68000 Assembly - about 3 months
Macintosh (System 6) - Quickdraw 1 week using Think C
UNIX - text curses lib - 3 days
Cocoa, I have found the documentation a complete nightmare. The documentation explains so little of what it is doing. The auto-magicness of Interface Builder, What does this stuff actually do?
hlborg — Feb 19, 10 7611