Re: Cocoa/EOF for non-enterprise apps Re: proof of cocoa superiority?
Re: Cocoa/EOF for non-enterprise apps Re: proof of cocoa superiority?
- Subject: Re: Cocoa/EOF for non-enterprise apps Re: proof of cocoa superiority?
- From: Bill Bumgarner <email@hidden>
- Date: Tue, 12 Jun 2001 18:12:36 -0400
/* Deirdre's excellent stuff in c style comments */
>
Any developer who still thinks it is necessary to write SQL by hand
>
as a normal part of n-tier app development is wwwaaayyy behind the
>
times....
/*
* I am not convinced (and haven't done any serious testing) that EOF
* necessarily creates the most optimized join paths for any given database.
* Given that, hand-coded SQL may be a better choice for performance.
*/
Key phrase: "as a normal part". In most cases, there is little to no point
in incurring the development costs necessary to write and maintain custom SQL
because there are very cases-- as a part of normal development-- where writing
hand tuned/coded SQL is really necessary to gain the required amount (or even a
significant boost) in performance.
It gets back to the classic rule of thumb; don't optimize code unless it is
identified as a real live honest to God performance bottleneck!
We have found that the return on investment for writing a pile of custom SQL
isn't generally high enough to justify the effort. Not only is it hard-- few
developers are DBA level SQL authors and vice-versa-- but it incurs massive
maintenance costs down the road. Generally, it is easier and often yields
better results to focus optimization efforts on things like caching, pooling,
shared editing contexts, and appropriate levels of change notification.
>
However, that does not mean EOF is an appropriate solution for every
>
app out there. Specifically, for applications targeted at the
>
consumer market, it very likely is not appropriate to use EOF as a
>
solution for persistency. I.e. EOF is not a good replacement for
>
the traditional multi-document UI that a product like, say,
>
OmniGraffle, GraphicConverter, or Create. Nor it is appropriate to
>
apps that are seemingly database centric like, say, iTunes or the
>
Finder.
/*
* There are definitely places where I could argue even for commercial apps;
* several of the ones I've written *HAVE* had embedded sql. Hand-coded, mind
* you.
*/
Certainly; but not in general. In general, EOF does a fine job of
generating SQL. Most applications don't require that level of refinement to
actually improve product value in a large enough fashion to make it worth the
effort. In a lot of cases, the same amount of time/effort would have a much
greater return on investment by focusing on any of a number of other details!
>
Apple is aware that some kind of a generic persistency solution
>
completely different from EOF needs to be provided to the developer.
>
Ernie P. repeated this point at several sessions at WWDC.
/*
* And we STILL need EOF/ObjC on the client side -- ONLY ObjC.
*
* People forget about in-house database apps.
*/
Why do you need ObjC for this?
Java is perfectly viable for in house database apps. Works fine. A bit on
the memory hungry side, but memory is cheap, cheap, cheap. Writing and
maintaining EO adaptors is expensive, expensive, expensive. EOF is useless
without database adaptors and without full on committment from the database
vendors, there will not be first class-- has not been on PPC in a long, long
time-- EO adaptors save for-- maybe-- FrontBase and OpenBase (both very fine
products, but don't have quite the corporate impact as Oracle/Sybase). Even
then, there is a massive amount of back-and-forth to make sure the EOAdaptors
work across revisions to WO/Cocoa and vice-versa.
The reality is that even if Apple were to decide that EOF/ObjC was a direction
they wished to support and promote as the future of all things EOF, they would
still be beholden to the database vendors to ship native libraries. Even with
native libraries, someone still has to write the EO adaptors. Even once that
is done, there is the support issue and the very real potential of "not my
bug" syndrome as the client lib vendor and the adaptor vendor both try to not
take accountability for any given issue.
One big advantage to JDBC is that there is a certification process that--
broken though it is in a number of respects-- somewhat guarantees that a
compliant JDBC driver is really compliant. It isn't perfect, but it is a far
cry better than the situation we are in when we rely upon a vendor to even
acknowledge or support OS X.
Example: Upon first playing with WO 5.x, we were able to grab the latest JDBC
thin drivers from both Sybase and Oracle. They just worked (though there was
some wrestling w/the URL crap) even though neither vendor had ever touched WO
5.x in any manner that had been publicized. We have also had good luck with a
number of other vendors implementations.
>
EOF isn't really appropriate to environments where one is trying to
>
persist a directed graph of objects where both the graph's
>
connectivity and the object contents need to be relatively flexible.
/*
* Understood, but, for a PIM application (or a shared calendar), that wouldn't
* necessarily be the case.
*/
True; but why not Java? Actually-- for a PIM application or anything else
that is designed to be shared-- you would probably want to go with Java Client
or D2JC as they have an extreme amount of portability.
>
BTW: Stating that the "power of EOF for desktop apps" is not
>
currently available is inaccurate. Have you actually tried working
>
with the pure Java EOF in WO 5.x targeted to building Cocoa
>
applications?
/*
* I'll code for windows before I'll code for EOF/Java Client.
*
* Either way, it ain't happening.
*/
Have you actually tried Java/Cocoa development? Are you basing your opinions
on WO 4.5.x bridged development (not the same experience at all)?
Its just a stupid language against the same APIs.... what's the problem?
ObjC isn't the end-all, be-all language that a number of folks seem to want to
believe that it is. Neither is Java. Or Python, C#, VB, or CLOS or any other
language.
It all boils down to the APIs.
>
Obviously, a remaining issue is one of licensing and it will be
>
interesting to see how Apple addresses that issue. Let's hope it
>
is handled with a bit more finesse than some of the licensing events
>
in past history....
/* You mean like the clone licensing? */
That and other ExAMPLES come to mind....
b.bum