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: Deirdre Saoirse Moen <email@hidden>
- Date: Tue, 12 Jun 2001 15:32:11 -0700
We have found that the return on investment for writing a pile of custom SQL
isn't generally high enough to justify the effort.
Frankly, I've done a lot of SQL development and I haven't run across
even a complex sql statement (not even the "torture the grad student"
ones my prof throws at me) that take very long to write.
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.
This might surprise you, but I keep all my sql statements IN the
database. Therefore they're maintainable without having to modify and
recompile an app.
/*
* 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.
Actually, about 1/3 of the stuff I've done in the last 10 years has.
Just because your development and mine don't overlap much doesn't
mean that my needs aren't real. ;)
For my current project, we won't be able to use faircom or any of the
others, so I'm writing the SQL parser from scratch. Yes, really.
Fortunately, I have implemented a small SQL parser before.
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!
Depends a great deal on the project, wouldn't you admit?
For network-based apps like web stuff, the network latency is the
biggest bottleneck.
OTOH, I've worked in shops where the database server was I/O bound
and running at an average of 97% of I/O capacity feeding directly to
a T-3.
For local-based apps, the database I/O is the biggest bottleneck
after the user.
>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?
I'm not MIS, I don't do them. But I want a *choice* of language when
I implement things. Otherwise, it's going to be PHP.
Java is perfectly viable for in house database apps. Works fine. A bit on
the memory hungry side
No kidding:
282 java 0.0% 10:50.63 25 176 109 564K 184K 600K 182M
182 megs of VM? Jeez.
, 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.
Well, then another way of doing it is to write database adapters to
known middleware interfaces (ODBC, JDBC).
Besides, if one's writing custom apps, one can write a custom
flat-file adapter. Much easier than doing the entire implementation.
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.
So why not open a job req for that?
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)?
No, I'm not. I've done Cocoa/Java apps (as a test). In general, I
dislike Java. I prefer late-bound OO languages.
Frankly, I probably code more in Python than anything else.
Its just a stupid language against the same APIs.... what's the problem?
If I'm going to code in Java, I'm going to do it because the strength
of the tool (cross-platform) is the correct strength I need.
So I'm not going to limit myself to coding something that can only be
RUN on one platform. Period.
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.
I spend a lot of time in a language and I want to use tools that I
enjoy. Quality of life is very important to me, and *toolkits* (I
refuse to use Microsoftian-TLAs) are one component of that.
--
_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