Re: Accessing function definitions
Re: Accessing function definitions
- Subject: Re: Accessing function definitions
- From: Laurence Harris <email@hidden>
- Date: Fri, 27 Oct 2006 01:13:58 -0400
On Oct 26, 2006, at 9:16 PM, Turtle Creek Software wrote:
Granted, we'd
like to see Apple loosen the purse strings and really bring it up to
the level of a top-notch, Mac-like development environment, but it is
what it is and they don't generate any revenue with it, so there you
go. I'm sure the engineers who work on it do the best they can given
their time constraints and resources.
Since Apple folks often view this list, I'd like to strongly disagree
with this notion that it's fine for XCode to be mediocre.
Sorry, you must not know me very well. ;-) I never meant to suggest
that it's fine for Xcode to be mediocre. agree 110% with what you're
saying. I've just seen this so long that I no longer have the energy
I used to have for getting worked up about it. I used to get fired up
on a regular basis, but it didn't make any difference and I'm
inclined to believe the root causes of these problems are outside the
control of at least many of the engineers. I honestly have no idea
who makes design decisions for Xcode, or if that person or persons
have ever used CW, or anything at all, really. I only know that it
feels awkward and clumsy for the way I use a development environment,
and not very Mac-like. I found Interface Builder to suffer from a
variety of productivity-killing bugs and limitations as well. Before
that it was ResEdit (bare bones and no real development for years)
and MPW (very powerful but also not Mac-like or intuitive).
Apple, one way or another, generates almost ALL of its future
Macintosh
revenues from XCode. Maybe not directly in the form of product sales,
but in future hardware sales that result from the software produced by
us developers.
The problem with this kind of argument is that there's no way to
quantify revenues lost to such factors. It's just like the early days
of Mac OS X when there were serious usability issues resulting from
missing features, bugs, and performance issues. How many copies of
Mac OS X and Mac did they miss an opportunity to sell because of
those issues? No one knows. OTOH, the bean counters can tell you to
the penny what it costs to hire another engineer or QA person. Plus,
it's short-term saving versus long-term investment. Pay X dollars to
hire an engineer now so some indirect and unquantifiable amount of
revenue can be generated later? Given this choice the bean counters
decide to save X dollars by not hiring additional people and *assume*
that any revenues lost in the future by that decision will be less
than what they saved.
Have a productive and easy-to-use programming environment, and you'll
get programmers spending time and producing innovative new software.
Have a clunky, difficult set of tools, and you'll gradually lose the
most creative programmers. They will find some other environment where
they can get results more quickly and less painfully.
Probably only to a limited extent. A lot of people will just deal
with the problems. In fact, based on discussions I used to have about
Interface Builder, Steve Mills' comment in a parallel thread pretty
much sums up what will happen: "I'm not saying that I now like it,
just that I forgot about [how] horrible this behavior really is."
People will get used to the problems. After a while they'll
affectionately refer to them as "quirks." They won't like them, but
after a while they'll forget how good it could be and just slog away
at their work. Since it won't change, this is a coping mechanism. The
alternative is to be frustrated all the time.
One group which may be more heavily affected is the up-and-coming
would-be programmers. These are the high school and college kids who
decide to try their hand at writing some Mac software. If they're
just getting started they may find it unintuitive and get discouraged
before they get into it far enough to enjoy it.
There have been some great development environments for the Mac, in
their time. I'd rate Think C/Think Pascal and CodeWarrior that way.
Apple's development tools (with the exception of HyperCard) have
generally been blah to meh in quality.
That's my assessment, and I haven't seen any indication of that
changing. They will be useable. They will have some powerful
features. They will frequently forego opportunities to be elegant and
follow the design of good Mac applications.
They have usually been just
strong enough to make the good stuff unprofitable, so it goes away.
I'ts really too bad. Apple seems good at developing great consumer
software, but not so much for developer tools.
They often feel to me as if they were develop by geeks for geeks, for
people who don't place a lot of value on a good user experience or a
good UI. As long as the applications are powerful and people can do
what they need to do with them, that's enough. Believe me, I wish
that weren't the case, but it's what I've seen for over 15 years. I
think the fundamental problem is that they see Mac developers as a
distinct species from Mac users. They think that because we're
developers we don't care about elegance or if the tools we use follow
the human interface guidelines that go into the design of those
applications you think are so nice. How do you file a bug in Radar
that says "I'm a Mac user who just happens to write Mac software for
a living?"
Larry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden