Re: Cocoa/EOF for non-enterprise apps Re: proof of cocoa
Re: Cocoa/EOF for non-enterprise apps Re: proof of cocoa
- Subject: Re: Cocoa/EOF for non-enterprise apps Re: proof of cocoa
- From: Deirdre Saoirse Moen <email@hidden>
- Date: Fri, 15 Jun 2001 12:31:35 -0700
On Friday, June 15, 2001, at 01:44 PM, Deirdre Saoirse Moen wrote:
At 11:51 PM -0400 6/14/01, Bill Bumgarner wrote:
To that end, EOF and EOF/ObjC are vital.
No, EOF is vital. ObjC is not.
So you disagree with Steve Jobs' statement:
"Objective-C is the native language of MacOS X."
To that end, doesn't it mean that having a tool available IN that
native language is important?
ObjC is the core of OSX. EOF is not a part of the core of OSX.
But it should be.
Repeat: EOF is *not* a core part of OSX. The success/failure of
the operating system does *not* hinge upon the presence of an ObjC
EOF.
But the success of the platform DOES.
Yes, and that maintenance is much more expensive than you seem to think.
I know how expensive maintenance is.
On the one hand, you have all of the efforts necessary to track the
changes to IB/Cocoa. But the big cost center is the adaptors. EOF
has had pathetic adaptor support on Macintosh hardware forever.
Fixing that is prohibitively expensive. Java/JDBC answers that
problem. It also provides a single code base that can be used for
a much larger market than just EOF/Cocoa-- Java Client and Direct 2
Java Client are pure Java/Swing tools that are extremely useful.
Obviously, they aren't core to Apple's business and there is some
risk-- minimal because Apple seems to view them as strategically
key-- of them getting the bullet.
Again, supposing EOF/ObjC talked to JDBC adapters. Then where's the
additional cost there?
And, as far as the database adapter issue goes, WRITE THE DATABASE
ADAPTERS FOR ObjC TO TALK JDBC. I said that before and you missed
it, thus the caps. It's just a protocol.
Sure, they COULD do that, but would anyone in the market take them
seriously. Lookee here-- we provide you an adaptor that goes from a
language that the market has bought in to and is technically NOT
THAT BAD to a language that very few people know/understand and is
only marginally better than Java.
I disagree that it's only marginally btter than Java. Java is nothing
but C++ with training wheels. And C++ isn't that great a language. If
I'm going to use a C++ like language, I want to use C++, not a
wannabe for sloppy programmers who can't think with pointers.
Sure-- that MIGHT make a small segment of the ex-NeXT crowd happy,
but so what? They are a minority. A vast segment of the market--
including a bunch of folks from the NeXT world-- are much happier
with the solution *as it is shipping*.
Given that people at WWDC were announcing end of life of products --
and I'm not talking Scott, I seriously doubt that's true.
And I'm not part of the ex-NeXT world myself: you seem to think that
y'alls all that counts. I *know* why the Mac market share in business
slipped. I noticed the shift in my client list.
You know, Slashdot runs on MySql. It has millions of rows and,
despite the beefy nature of the hardware, there's no way it could
load all info into memory. Are you thinking mysql, because of its
limited sql implementation, is a toy?
*sigh*
Did you actually read what I said? I wasn't talking about millions
of rows. The /. implementation solves a problem that is not
common. Not only that, but it isn't very well implemented anyway--
go read the perl code. 2.x is much better, but still pretty crappy.
I've rarely seen good perl code, but it does work.
Call me a pragmatist, but I'm of the opinion that code that works is
never "crappy." Code that appears elegant but doesn't work is
"crappy."
What I said was that MySQL-- or relational databases in general--
are *not an approriate tool* for a lot of the problems that folks
seem to want to use them for.
I think you're wrong. Have you ever written commercial apps that had
an embedded sql database (i.e. Faircom, Empress, etc.)? That shipped
as shrink-wrap or vertical markets? That shipped with other people's
products as an add-on?
I've done it over and over and over. The number of database problems
out there for which a small SQL solution is needed is quite immense.
The issue is not the size of the database necessarily, but rather the
complexity of the interrelationships of the data.
One commercial app I wrote had fourteen tables and one preference
table; the SQL solution was clearly the right one. I believe the
whole app was only a few megs; it shipped on a CD. It's not the only
commercial app I've written for which EOF/ObjC would be the logical
choice if I were porting it to MacOS X.
--
_Deirdre Stash-o-Matic:
http://weirdre.com http://deirdre.net
"Cannot run out of time.... Is infinite time. You... are finite....
Zathrus... is finite. This... is wrong tool!" -- Zathrus