Re: Xquery might have some things right
Date: Tue, 23 Mar 2004 14:20:07 GMT
Message-ID: <rIX7c.62404$a12.2807_at_newssvr33.news.prodigy.com>
"Tony" <andrewst_at_onetel.net.uk> wrote in message
news:c0e3f26e.0403230201.7fb37da7_at_posting.google.com...
> dwolt_at_iserv.net (Dawn M. Wolthuis) wrote in message
news:<6db906b2.0403221645.1141ecf6_at_posting.google.com>...
> > "Eric Kaun" <ekaun_at_yahoo.com> wrote in message
news:<9JC7c.62219$lV6.25494_at_newssvr33.news.prodigy.com>...
> > > "Joe "Nuke Me Xemu" Foster" <joe_at_bftsi0.UUCP> wrote in message
> > > news:1079920954.616425_at_news-1.nethere.net...
> > > > "Mikito Harakiri" <mikharakiri_at_iahu.com> wrote in message
> > <news:3z32c.18$zW4.150_at_news.oracle.com>...
> > > >
> > > > > Imagine RemoteSystemA owner provided you with EDI, XML or others
> > ShmackML
> > > > > instead of remote database connection. Suppose all you need to
know is
> > how
> > > > > many purchase orders did the system processed last month. Does it
mean
> > you
> > > > > have to import *all* the orders to your system first?
> > > >
> > > > Of course not. The remote system is most likely Object-Oriented, so
> > > > you merely navigate, a/k/a chase pointers, to the orders
collections,
> > > > iterate through each and every order, and maintain a counter.
That's
> > > > N+K network round trips for N orders, where K is finite but
unbounded.
> > >
> > > How convenient. :-\
> >
> > What is the theory on which we base "our" disdain for navigation? Is
> > the only rationale performance?
No, it's just another manifestation of the (admittedly vague) what/how distinction. We should, at this point in the history of computing, be specifying WHAT we want, not how to get it. It's as if the (necessary) operational thinking that dominated the design of processors now dominates everything we do, rather than allowing us to return to "pure" logic, where we can actually achieve conceptual traction.
> > In other words, if there were a data
> > model where the implementation was zippy quick and navigation was a
> > strategy for getting there, then is there something else upsetting
> > about the navigation approach?
>
> It isn't a theoretical disdain. It is based on the fact that with
> navigation you have to specify how to get the result, not just what
> result you want. One of the strange things about many programmers is
> that they don't trust computers, and always prefer to do all the work
> themselves.
A huge problem. I'm less and less in favor of "flexibility" in language design for commercial / industrial systems, since this is so often abused to no one's benefit. Specifying an access path, as opposed to simple criteria for selection, makes a world of difference.
- Eric