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 10:44:50 -0700
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?
If Apple shipped a little in Dylan, a little in Eiffel, a little in
C++, a lot in C, a little in Java and not much in ObjC, we'd all
laugh. But here's an example of where, right when MacOS X ships, a
key part of Steve's statement is false.
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?
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.
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?
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.
Hey, at least we agree on Python. :)
--
_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