understanding your tools

i've changed the subject as the relevance of this discussion to
8.0 seems a mite difficult to prove...

On Sat, 14 Aug 2004 18:04:52 -0400 Mike Mascari <mascarm(at)mascari(dot)com> wrote:
> Just to be an irritant, I'd argue that, at least w.r.t. GC, these
> are problems for the implementors. I'm not saying it isn't smart to
> work around language implementation defects, just as it has been
> recommended to people to use ORDER BY LIMIT 1 and, until recently,
> EXISTS instead of IN. However, the fundamental problem lies with the
> implementors, not with the programmer who should be thinking in
> terms of correctness, not visualizing the machinations of a JVM's GC
> internals...

easy to say. not a real practical point of view in practice, except maybe
for some more theoretically minded professorial types.

to take an example from the land of databases, i'm 1 month into a 6 month
contract writing java applications with an informix backend. the databases
are quite a bit larger than i've worked with in the past, so i'm learning quite
a bit about how to write queries and select indices.

it turns out that informix has the same exists vs. in issues that we all know
and love from prior versions of PostgreSQL, which a friend of mine who is
a first rate informix dba advised me of after i was pretty disappointed in the
behavior of my first attempts at a particular set of queries. in fact, the difference
is on the order of a factor of 6 to 8. now this is a query that needs to be
done interactively. i can sit there saying that it's the implementors problem,
or i can write code that returns results in 10 seconds instead of a minute.

i believe that if i asserted that the developers of informix were at fault, and
therefore it wasn't my problem, that it would be very likely that i might not
even make the full 6 months. as little things like eating and paying the
mortgage are important to me, i changed my INs/NOT INs to EXISTS/NOT
EXISTS.

richard
--
Richard Welty rwelty(at)averillpark(dot)net
Averill Park Networking 518-573-7592
Java, PHP, PostgreSQL, Unix, Linux, IP Network Engineering, Security