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: email@hidden
- Date: Wed, 13 Jun 2001 08:33:37 -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.
Ahhh... a SQL discussion.
I have to agree with Deirdre on the point here - I find it's almost ALWAYS
better to write SQL by hand than to use an automated tool, but part of that
is the nature of what I do. The applications I work on deal with millions
of rows of data, so a minor inefficiency can cause real headaches (like
people not getting paid).
I have to say that I _HAVE_ seen some complex SQL statments that took quite
a while to write but, again, that's in the nature of the work I do. For
most purposes, writing SQL is very straightforward and not hard. SQL is
pretty simple when you get down to it, and an experienced developer should
be able to pick up the most often-used stuff pretty quickly.
>
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.
This shouldn't surprise anybody. Hardcoding SQL is okay if you're sure it
won't need to change and can't be reused, but outside of a classroom
environment, how often is that giong to be true. This practice is very much
like storing text in resources (a la OS 9) or in localizable property files
(a la OS X). Storing SQL text in a database is commonly (but not
exclusively) used in my industry.
>
>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?
Certainly does. I've worked on projects for which the original statement is
true, but I've worked on many, many more where that statement is laughably
untrue. It's actually a little insulting that someone would suggest that
those of us who want EOF/Cocoa don't know what our own needs are.
Even though I may end up looking like a bad guy again (seems to be
something I'm good at), I have to make a statement that one or two people
are bound to take offense to: Judging the needs of all Cocoa developers
based on your own experience or the past needs of Macintosh developers is
small minded. While I don't want the platform to lose what it has been, I,
for one, would love to see it live up to the potential that its NeXT
heritage gives it - which is to be a powerhouse in the mid-market and
enterprise application space. While I think desktop application writers,
web apps, and hobbyist developers should all get what they need to do their
jobs, Apple shouldn't remove, or stop supporting pre-existing functionality
that is useful to and desired by developers who wish to expand the Mac's
sphere of influence. I'm not suggesting that Apple focus new development
efforts toward the enterprise, just that it not remove existing items like
EOF; maintaining an existing product or codeline is considerably less
expensive and less work than rewriting if the original design is sound and
the implementation was done well. So, if OS X is a success and Apple begins
to penetrate the enterprise and mid-market space, they will have to start
over, or rely on third parties to bring this functionality back.
Frankly, if they would just give the basic functionality (give us
palettes), I'm more than happy to maintain those adapters I need. Database
vendors usually don't make HUGE changes from release - they sometimes add
some features, change syntax to more closely match standards (primarily
things like outer joins), etc.