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 10:51:59 -0400
Georg,
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?
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.
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).
For the horizontal desktop market, traditional database persistency
via an API like EOF/ObjC just doesn't matter. The products that have
had persistency in that kind of a market were the ones built on tools
like FileMaker which take a very different approach to that persistency
model. The best example of a product LIKE that from the NeXT community
would have been DataPhile.
For the horizontal market, the persistency needs are generally
centric to a multiple document model. That is, the user is thinking
"File->New Document". It is centric to a model where the user may pick
up a hunk of data and email it as a document... they may have five
documents, maybe ten. Per document-- per database-- they may be
working with 1000 records-- maybe 10,000.
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.
---
I'm looking forward to reading your paper regarding productivity
with ObjC. In my experience, productivity is largely governed by the
APIs against which one is developing as long as there is a certain level
of parity between languages.
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.
One of the most surprising reduction in costs and increases in
productivity comes from maintenance. I have found that Java codebases
have proven to be much easier to maintain over the long term because the
lack of categories and all the formal exception handling / type
declarations forces the developer to be a bit more linear in their
thinking-- annoying when writing the code, a god-send when maintaining
code you haven't looked at in six months.
For vertical or horizontal applications, performance is a
combination of "does it run fast enough" and "does it have the features
required by the customer". For the vertical market, we have found that
Java based WO 4.5.1 certainly can run fast enough-- we have a number of
solutions deployed on that platform with great success. We find that
the answer to the features issue comes much more naturally with Java
because we are able to reuse a myriad of relatively high quality, freely
available, third party APIs "out of the box".
And that is with an old JDK and a very ineffecient bridge.
Thankfully, under OS X the JDK is up to date and the bridge has been
completely rewritten and is about a zillion times more pleasant to deal
with. The "does it run fast enough" question doesn't seem to be an
isue....
(We long ago gave up on buzzword compliance or trying to make a
buck of the dot com market-- our clients are real businesses with real
needs and, as such, the software built must be quite real in features
and performance. Even the 4.5.1 bridged Java can fit the bill-- but it
comes much more naturally with 5.0. We stopped doing ObjC for web
development a while ago because it was *more work* than doing the same
in Java. )
---
I can certainly understand yours -- and others who are in the same
position -- frustration at having a product that is nearly ready, but
having Apple ship OS X lacking in the APIs necessary to successfully
ship your product.
That does suck. Totally sucks.
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.
NeXT was a largely developer/technology driven company. I.e. the
company made decisions about API support and development that was
generally motivated by what the developers wanted-- not always the third
party community, certainly. Conveniently, the target market for NeXT
products was typically also a bunch of techies who were fairly like
minded-- i.e. our customers generally understood that the API was key.
Ultimately, this meant that there was virtually no shrink wrap market
out there-- they only shipped, what, 50,000 pieces of black hardware and
an unknown quantity of white software into a market that was largely not
the kind to buy shrink wrap products...
Apple, on the other hand, is very much a market driven company.
Thankfully, they are a cult brand and that market is largely defined by
the coolness of the product design-- hardware and software-- that they
ship. Fortunately, Apple has been somewhat successful-- obviously, not
anywhere near the borg-like success of Microsoft-- with this formula and
the shrink wrap authors coming out of the NeXT community to ship product
in the Apple space have an actual MARKET for the first time ever (I
talked with Andrew Stone during the week after March 24th-- he was,
perhaps, the happiest person I have ever encountered).
As such, Apple will continue to make decisions and set directions
to increase revenue-- even when those decisions are not necessarily the
best technical decisions or when those decisions directly counter
previous direction that may have been set.
As much as a small but vocal group of developers have been
criticizing Apple for their decisions, the reality is that their profits
have been increasing, their market share has been increasing, and they
have been landing some major deals in the education market. I.e. they
are generally doing something right.
That there is fallout along the way-- APIs shot in the head, Apple
making mistakes in handling certain transitions, etc..-- is inevitable.
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....
...then where would we be?
b.bum
On Thursday, June 14, 2001, at 05:21 AM, Georg Tuparev wrote:
bbum,
Is it really so difficult for you to understand that there is life
behind Oracle & Sybase? We all know your technical knowledge, but your
inability to understand the world of horizontal desktop oriented
markets is really pathetic!
Just an example of one of our projects (put on hold because Apple's
decision to kill EOF/ObjC) - a CBT Editor/Player. I would like to sell
it with cheap embedded database (FrontBase is an obvious choice for
us). And I'm not going to switch to Java, because it is just too
expensive for me - it reduces the productivity of my developers, we
have to throw away sources written and maintained for years, and go to
the market later and sell our product for more money in order to cover
the reduced productivity of the team. These are all reasons that matter
a lot - all of them can lead to a success or failure of a product.
I'm with you if you are talking about consultancy web-centric projects
where buzzwords matter more then efficiency - the client will pay
anyway (or file for chapter 11), but please try to understand that this
is vertical market, and a shrinking one.
Just my $0.02
gt
p.s. This should really move to 'talk', but oh well, I'm giving bad
example myself...
On Thursday, June 14, 2001, at 12:10 AM, Bill Bumgarner wrote:
Example: Because of the JDBC specification and the rabid Java
market [rabid because you'd have to be insane to buy into some of the
crap some folks are selling within the market], Sybase and Oracle are
both compelled to create and release fully compliant JDBC drivers that
closely follow the latest releases of their data servers. The same
holds true for just about every other database vendor in the
industry-- they make real sales as a result of having JDBC drivers
and, as such, have a real motivation to implement said drivers.
Georg Tuparev
Tuparev Technologies
Klipper 13
1186 VR Amstelveen
The Netherlands
Mobile: +31-6-55798196