Re: Strong language about Cocoa and Qt.
Re: Strong language about Cocoa and Qt.
- Subject: Re: Strong language about Cocoa and Qt.
- From: Neil Earnshaw <email@hidden>
- Date: Tue, 1 Jul 2003 18:51:05 +0100
On Tuesday, July 1, 2003, at 03:30 AM, publiclook wrote:
What I don't understand is comments like the following:
...
"The custom preprocessor issue bothers me less than using
Objective-C." IMHO, this is getting out of hand. That is like saying
I would rather use a hammer to drive screws than learn how to use one
of those funny looking screw drivers.
If the change was that simple, no-one would have any problems with it.
There is very little risk or cost involved in switching from nails to
screws. The Cocoa/Obj-C switch carries a very high risk and investment
cost.
<analogy>
Switching to Cocoa/Obj-C is like ... trying to interest people in a new
wide gauge standard for railways engines.
'Look guys, this new standard allows you to corner faster, carry bigger
loads, give your passengers more room...' and so on. 'All the
passengers we've tested it on love it. It's "insanely great," everyone
can see that!'
Everyone agrees its a nice idea, but the track owners (corporations
with lots of WinTel infrastructure) are thinking 'It's going to cost us
a fortune to replace all our tracks, and who knows if anyone will make
the trains to run on the new lines. There's too much risk for an
investment that size.'
Meanwhile, the train makers (app developers) are looking around and
thinking 'No-one's using this new standard. We'd have to invest a huge
amount in designing new trains and pray that a large section of the
market have switched to the new track size when they come off the
production line. Of course, we'd have to keep supporting existing
customers on the old standard. That means we'd have to have to build a
whole production line to run in parallel with the existing
manufacturing line. There's too much risk in an investment that size.'
Chicken, egg? Egg, chicken? Who's going to take the first plunge? A
few little countries like Liechtenstein take the plunge. They quite
like the new system, but very few manufacturers are willing to bid for
rolling stock contracts.
Along come some clever guys with an interim solution(Qt). 'Look guys,
we've got this adapter kit that'll allow your existing manufacturing
line to be modified so it can produce path types of rolling stock.
Yeah, its a compromise, but it'll reduce your risk if you want to try
your luck in the new market without a really massive investment.'
Converts to the new standard wet themselves laughing,
OMG! It's such an abomination!
When someone asks the converts why people prefer to use the adapted
manufacturing technology, rather than invest in a whole new factory,
the vast majority of converts offer reasoned opinions. A few
fundamentalist converts maintain an off-putting air of superiority over
their 2% of the market.
I would suggest that most of the people on this list are trying to do
things miles above what that fellow is attempting, and are probably
much more sophisticated in outlook than even most commercial
developers. Most developers see their work as a job, not a calling or
a craft, and mainly want to get the job done quickly and with little
concern for aesthetics. In short they have little emotional
investment in their work, and I sense that most on this list have a
very different attitude, and should not waste a lot of time analyzing
that guy's psychology.
A fundamentalist never does more good than harm.
</analogy>
Cocoa is much harder to learn than Qt because:
1) Cocoa uses several design patterns that interact with each other in
complicated ways. Each pattern is simple to grasp on their own.
Delegates, responder chains, MVC, target/action, notifications,
reference counting and nibs, to name just a few, are not complicated
concepts. The complexity really hits you when you first try to build a
reasonably sophisticated application. You have to master the
interactions between concepts in n-dimensions at the same time.
Anguish et al list 14 design patterns. Qt is a much simpler beast, it
is merely three dimensional.
2) Cocoa does not support some of the patterns that potential converts
are experienced with. The most painful one for me was the loss of
multiple inheritance. Yes, there are ways around that issue, but they
all seem to involve a lot of mundane work on my part, rather than the
compiler's. For me, using Qt for the first time was like slipping on a
pair of comfortable old slippers. I was right at home. Cocoa keeps
fooling me into thinking that I've got a grasp on it. Then I add in
another dimension, e.g. decide to make my app Document-based, and the
whole thing collapses.
Basically, it's not the classes that are hard to understand, its the
interactions between them. What I wouldn't give for a sequence diagram
that shows what happens when a Document-based app is launched. Who
calls who and in what order? Simple things like that would make
learning Cocoa a much less frustrating experience.
Neil
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.