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: Thu, 14 Jun 2001 23:51:12 -0400
On Thursday, June 14, 2001, at 04:07 PM, Deirdre Saoirse Moen wrote:
Is it really difficult for you and a bunch of others to
understand that Apple maybe didn't decide to KILL EOF/ObjC? .... that
EOF/ObjC isn't even on the radar in terms of the issues that Apple is
dealing with in their efforts to augment and extend the Macintosh
markets?
Maybe you need to realize that there's something really important that
Apple hasn't gotten:
It has jerked around developers for years. Other companies don't do
that with the order of magnitude that Apple does.
Well... yes, Apple did go on the OS wild goose chase for, what, 10 years?
But I don't necessarily think they have jerked developers around any
worse than, say, Microsoft. The transition from SunOS to Solaris
wasn't too fun, either.
Apple is a for profit company building hardware that is largely
aimed at the consumer and education markets. Apple does not have a
history of building systems for the enterprise market. Apple is in the
middle of-- well, coming out of the middle of-- changing EVERYTHING
about the way that Mac OS worked.
Apple has a stated goal of 100% market share (5 down, 95 to go). With
that goal in mind, they are going to have to cater to the business
customer's needs. And that includes a lot of small, vertical-market
stuff that EOF/ObjC would be great in.
Sure. And so will EOF/Java. For a lot of that small, vertical market
stuff, the solutions haven't yet been implemented.... if there isn't a
legacy codebase coming out of the NeXT realm, then ObjC/EOF isn't an
issue except to those people that are language bigots. An awful lot of
the developers out there will use Java/EOF/Cocoa and be damned happy
about it.
I'd like to see every dentist, every yarn store, every bank, etc. using
vertical market apps on Macs. Wouldn't you?
Sure. And nothing about OS X or WO5 or EOF/Java/Cocoa/JC/D2JC as it
is shipping today stands in the way of that.
To that end, EOF and EOF/ObjC are vital.
No, EOF is vital. ObjC is not.
Right now, the most CRITICAL task on Apple's plate is to transition
the Macintosh community and mindshare to a very new way of thinking.
I.e. to transition THAT WHICH KEEPS THE COMPANY ALIVE off of an OS
that largely hasn't changed in 10 years onto a completely new OS that
is about 10x more complicated (and 20x more powerful).
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.
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.
The second is larger-- the cost of maintaining and perpetuating the
database adaptors is huge. Beyond huge, in some cases it may not even
be possible. The database vendors aren't really terribly excited about
creating adaptors-- or even client libraries for OS X-- for a product
that does not scream that vendor's name everytime the adaptor is used.
It would be prohibitively expensive for Apple to try and maintain said
adaptors-- and that assumes they would even have the client libs in the
first place.
EOF has not had a history of having either a broad range of database
compatibility, nor has it ever had really up to date database adaptors...
...until Java/JDBC.
I.e. it doesn't call for the power of a relational data store!
Very likely, the data could be stored via a simple hashing algorithm--
berkeley DB from the Unix world, FairCom's c-tree product, etc... --
or even simply stored as a big hunk o' data that is read all at once
into a set of arrays.
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!
Java is just another language. Once fluent within it, I have
found that my productivity has actually *increased* because the
compiler is catching a lot of assumptions and stupid mistakes. And as
annoying as the formal exception declaration and all the type casting
is, both have often caught errors that would have led to very
confusing behavior under ObjC.
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.
But I am also sympathetic to the position Apple is in.
Unfortunately, maintaining the ObjC/EOF APIs does not have an ROI that
can justify the resources necessary to do so-- not insignificant
resources. They made a very hard decision.
How do you know it doesn't have the ROI?
I don't, but I'm pretty confident in my wild ass guess that there isn't
enough revenue in the ObjC/EOF market to justify expending the
significant quantity of resources necessary to maintain and perpetuate
the product. I'm also fairly confident that a significant portion of
the development community is going to be just as happy or happier on
Java/EOF and, as such, they would need to be pulled from the ROI
equation.
That there is fallout along the way-- APIs shot in the head,
Apple making mistakes in handling certain transitions, etc..-- is
inevitable.
No, it has been more painful than it needs to be.
Yup; and it has been less painful than it could have been. Hind sight
works that way.
In a slightly different world, Apple would have bought Be (and
subsequently tanked while mired in a big pile of multithreaded C++
code) and NeXT would have disappeared....
As a former Be engineer, I think it would be best if I just bite my
tongue on that one. :)
:-)
b.bum