Boy, I've been really refraining myself from jumping into the fray
here. It's an interesting discussion which has been handled
respectfully, but it seems to me that we've reached the point of
diminishing returns on this. I think the lines have been drawn, and
most people have chosen one side of the line or the other and I don't
think there's much convincing going on.
About 2-3 years ago, we had a similar discussion on this list, which
got rather heated and it got kind of nasty (with some of the blame for
that clearly falling on me), but since that argument I've been
primarily a lurker here, and have become a little gunshy about issues
like this. Nonetheless, I feel a need to put in a few comments. Before
I do that, I'll throw my bias up front - I think Apple, for the most
part, is doing an excellent job on the documentation. There is room
for improvement in places, but given the enormity of the job and the
target audience, I think they're doing great. I rarely have problems I
can't get an answer to either in the documentation or, when that
fails, from one of the helpful people here or one of the blogs
maintained by one of the people here.
I think what we are seeing is a combination of cultural and
technological (or, perhaps, architectural) differences coming to the
surface thanks to the influx of new programmers to our platform.
Unlike many of the Cocoa developers on this list, I have one foot
squarely in the other world - a good chunk of my income comes from
large corporate (think Fortune 100) clients, and I work regularly in a
number of language and on a number of platforms including .Net and
Java. I think this gives me closer to an objective view of the
situation than most, though I clearly still have my biases.
In many ways, Cocoa/Obj-C is an oddity, and certainly the approaches
that Microsoft, Sun, and Apple have taken with their development tools
is different. Microsoft has architected .NET, especially (but not
only) Visual Basic, to lower the bar for learning the most common and
most basic tasks by hiding some of the complexity involved. They
market heavily to large corporate and governmental entities that you
don't need experienced programmers, you can just send someone out to
certification and they'll be able to write whatever you need. They
push the "ROI" of doing that, since a junior tech makes less than an
experienced programmer. I'm not making this up, their Enterprise
salesforce uses this type of argument excessively with large corporate
clients: Because .Net is eaiser, they argue, it's cheaper.
And it's true, that to design a very simple application in VB or C# is
phenomenally easy, but there are tradeoffs. They've changed the shape
of the curve, but not the amount of work it takes to become truly
proficient, and I've made a lot of money over the years cleaning up
(or rewriting) programs written by people with little or no experience
other than a certification class. No matter what salespeople will tell
you, you can't remove the requirement of experience to become a truly
competent programmer, but you can make a programmer who hasn't gained
that competence unaware of their ignorance. I would argue that that is
one side-effect of Microsoft's approach. That combined with the fact
that the sheer number of .Net programmers out there means that almost
any specific task you need to do has been done by somebody else, so
with some decent Google skills, you can avoid learning to do the hard
stuff for quite some time since you can probably find a blog post or
code sample somewhere instead of writing your own code.
With Cocoa, there's a bunch of hard stuff right up front that you
can't avoid. I found that it took a while to "get it" when I first
came to the platform. I was primarily a C, C++, and Java programmer,
and I very quickly understood the steps to do basic things, but I
didn't always understand why I was doing it. Then, after a few months
of pretty regular use, I had this "aha!" moment and it literally all
fell in place, my brain formed a gestalt from all the various pieces I
had been playing with. In that one moment, Cocoa went from being hard
to being the easiest platform I knew... it was like getting to the top
of a hill, and then getting to ride a bicycle down the other side.
It's a steeper mountain (learning curve), and it seems much harder
until you reach the top, but it's much easier as come down the other
side. Probably a silly metaphor, but it feels right to me.
Now, I need to say this, because people often misinterpret comments
like the ones I've just made: I'm NOT bashing .NET. I'm just stating
that the architects have taken a different approach in the
construction of the language and libraries, and that there are
consequences to that approach. There are phenomenal .Net programmers
out there. But, Cocoa is NOT .NET and it's NOT Java, and some of the
differences are very fundamental and abstract. You really need to
approach learning it with the mindset that you don't know anything -
you have to learn from the ground up, and in some cases unlearn what
you think you know. Don't assume you know anything other than the
fundaments of programming (loops, conditionals, variables, etc.). Do
not fall into the trap of assuming you know how to do something simply
because you may have done it in a different language.
After a year of using Cocoa regularly, come on back and let us know
your feelings about the differences in the platforms, because at that
point, you'll actually have a good basis for making the comparison.
And it's completely possible that you'll still prefer .Net or Java,
but at least you will have an informed opinion. Until you've taken the
time to really grok Cocoa - and it does take some time - you really
are judging based on criteria that may not be appropriate or valid.
Here's an example: Over the course of this discussion, people have
asked questions like "Why do you like Xcode when Visual Studio is
better?" Well, it's because Xcode is well-suited to programming in
Cocoa and Visual Studio is well-suited to programming in .Net. Some of
the things that are in VS but aren't in Xcode are things that you miss
because you are still thinking like a .Net programmer. Same goes for
Eclipse and Java. Not that there isn't room for improvement in Xcode,
but don't assume that because you used a feature in Eclipse or .Net
that it is "missing" in Xcode, it could very well be left out
intentionally. A "kitchen sink" approach is not always the best
approach, and I think that's something the Apple engineers really do
understand - Objective-C has been around for roughly 20 years and has
not experience the kind of bloat that C++ and Java have.
Give it a little time. In the meantime, if you have specific problems
and can't find a solution in the documentation or by googling, then
post a question here. I guarantee that you will get help if you are
moderately respectful and have done at least a minimal amount of
research on your own. People here are tremendously helpful (as I can
attest from first-hand experience), but they're not going to do your
work for you.
Jeff
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
