On May 22, 2008, at 1:23 PM, Hamish Allan wrote:
On Thu, May 22, 2008 at 5:02 PM, Andy Lee <[EMAIL PROTECTED]> wrote:
I think we have a disconnect as to what you meant by "lowering the
barriers"
-- hence my reference to that particular phrase.
I'd like to point out that the "barrier" to which my post referred to
was that of *commitment* to the Cocoa design philosophy, and the
specific side-effect I didn't mind was gentle growth of the platform:
Thanks for the clarification. I agree there is a sort of
psychological hurdle that has to be overcome: one has to accept that
Cocoa will require learning a lot of fundamentals, and learning to
think differently about some things (like the dangers of dynamic
messaging). But I think it's best if we make that hurdle as easy to
overcome as possible, instead of assuming it's at exactly the right
height now.
On Mon, May 19, 2008 at 9:04 PM, Hamish Allan <[EMAIL PROTECTED]>
wrote:
On Mon, May 19, 2008 at 6:03 AM, Peter Duniho <[EMAIL PROTECTED]>
wrote:
And as long as you guys keep insisting that there's nothing wrong
with the
environment, and that people "just need to get used to it" and
"then they'll
love it", you're not going to get the kind of developer excitement
needed to
ensure the kind of developer support required to get the Mac
really into the
mainstream. At a minimum, market growth is going to happen a LOT
more
slowly than it could otherwise.
I don't see that as a particularly bad thing. I don't want to see my
platform of choice suddenly awash with apps written by people who
don't want to take the time to understand the whole picture.
I don't want to see a lot of crappy apps, period, even if they're
written by people who *do* take the time. But how much time *is* "the
time"? Do I only trust programmers who take six months to become
productive? Two months? Forty-seven days?
My feeling (and this is just an opinion) is that we as a community
should try to make "the time" as little as possible. For example,
consider this excellent list of topics that Erik Buck posted on
another thread:
"two stage allocation and initialization, designated initializers,
memory management, selectors, dynamic messaging, accessors, the
responder chain, delegates, target/action, data sources, archiving &
unarchiving (e.g. freeze dried objects in .nib files), the view
hierarchy, key and main windows, and above all the Model View
Controller pattern"
If I could utter a magic explanation that would enable anyone to
understand that list of topics in five seconds, I would utter it.
That would give them more time to study the HIG. If they ignore the
HIG, or if they're just unlucky enough to be horrible app designers
even within the HIG, then let the marketplace -- the famed high
expectations of the Mac community -- sort them out. Because there
will be much, much better alternatives written by people who do know
how to write good apps.
Of course, there is no such magic explanation. People have to do
their homework, at a pace that's right for them. But I have no fear
of the market being flooded by programmers who didn't do their Cocoa
homework. For one thing, their apps will either crash all the time or
leak memory like a sieve.
I guess the documentation could arguably be made better by continually
repeating the mantra that the conceptual documents need to be read and
understood; but, isn't that what this mailing list is for? ;)
That and telling people the iPhone SDK is under NDA. ;)
--Andy
_______________________________________________
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]
