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: Bill Bumgarner <email@hidden>
- Date: Fri, 15 Jun 2001 14:58:21 -0400
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.
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.
Believe me, I understand how complex a task this is. But having
someone to maintain the EOF/ObjC stuff that's what, 1-2 people? Given
that Apple has several hundred job reqs open, that's nothing.
Having been familiar with the development of EOF from the dbkit 1.0
days and prior-- as well as being familiar with the processes required
to ship something as large as WebObjects or an OS-- I think you are
grossly underestimating the resources necessary to maintain EOF/ObjC,
or the cost to Apple for releasing and supporting such a product.
No, I'm not. We're talking *maintenance* not initial coding. You do a
lot of initial coding, do you forget that maintenance is a small
fraction over a long period?
Yes, and that maintenance is much more expensive than you seem to
think. 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.
There is also two additional cost centers that are huge: the first
is maintaining parity between the ObjC version and the Java version of
the APIs. A huge pain in the duff and quite a bit different than
exporting ObjC APIs to Java as Cocoa does.
OK, so an additional 1-2 people perhaps.
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.
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*.
A great example from the freeware market is the incredible
overuse of MySQL as a database. Everyone uses mysql for everything
from addressbooks to mp3 players. Yet none of these apps need the
extra complexity of managing an MySQL installation-- in most cases,
it is a performance hit to use MySQL.
But it's a damn sight more relational than filemaker. At least it's
using the right tool.
That wasn't the point. It isn't using the right tool; the right
tool would be to simply load the entire dataset into memory,
manipulate it, write it back out... or use a btree/ctree
implementation. Relational is not always the answer!
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.
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 did not say that MySQL is a toy.
If you prefer Java, fine. However, there are many of us who don't and
never will. Please respect that.
I respect that completely. Personally, I prefer to program in Python
or ObjC because of a combination of convenience and syntax. However, I
have had to recognize that convenience and pretty code does not
necessarily maximize productivity.
But the bottom line is that Java-- like ObjC, SmallTalk, and the
myriad of other languages out there-- is just another language. The
power is in the API.
For me, what language I spend my time in is more important to me than
the toolkit I use. Let's just say we both have strong feelings about
quality-of-life and our emphases are different. For me, the Cocoa
toolkit is not strong enough to overcome my dislike of working in Java
and I personally would never write web stuff in Java (PHP yes, Java
no). On the other hand, I enjoy ObjC.
For you, you like the Cocoa/WO enough that the language isn't an issue.
Cool by me.
b.bum