Re: Objects and Relations
Date: 1 Feb 2007 00:01:48 -0800
On Jan 31, 6:13 pm, "David BL" <davi..._at_iinet.net.au> wrote:
> On Feb 1, 12:24 am, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
> Note that a StringRange can alias any contiguous substring occurring
> within a larger string, making the code more flexible than it would
> otherwise initially appear. If string processing functions
> parameterise on the range type itself (and not merely the underlying
> char type) then you achieve excellent decoupling between algorithm and
> physical representation.
Kinda. The problem is that the memory model prohibits full decoupling. In C++ memory allocation is in the hands of the programmer, and with a technique such as StringRange, one has to co-manage the lifetime of the StringRange objects and the underlying buffers.
And in general, this and related things means that much of the job of a C++ programmer is down in the domain of the language itself, and not in the application domain where it belongs.
As a programmer, I don't want to be doing lifecycle management. Of anything! Not memory, file handles, sockets, or any other damn thing that the user of my software has never heard of. Nor do I really want to be spending any more time than necessary thinking about algorithms. I want to think about specifications. And that's hard enough! I can't even do as good a job of specifying as I want; I still get bugs of intention. As far as I'm concerned time spent on anything else is just time wasted because my tools suck.
> Perhaps even one of the super-linear algorithms. Eg Boyer-Moore is
> O(n/m) on average. But is it realistic?
This is a particular case of the general issue I mentioned in another post: special purpose code vs. general purpose code.
> An advantage of a low level language like C++ is that you have control
> over the algorithm. The relational approach *forces* you to depend
> on the skill and investment of the compiler writers. This is a double
> edged sword.
> That being said, I'm very interested in seeing whether more
> declarative approaches can compete with hand crafted implementations
> in low level languages.
Well, let's get that out of the way right now: they can't. Not in narrow domains. Not if by "compete" you mean "perform as well."
> Ideally I would like to be able to specify
> most things at a high level declaratively and let the system choose
> implementations/algorithms except where I choose to "override" because
> of performance requirements.
Yes, *this* is the promise.
> Unfortunately an override ability seems
> incompatible with completely separating logical and physical, as in RM/
> RA. Is that right?
No, not at all!
Consider the following scenario:
Application software has DBMS query embedded which
is not performing adequately.
DBA analyzes query via explain; determines an index would improve order of running time.
DBA adds index.
Application software is now fast.
This is not even a particularly advanced scenario, compared to what is possible. For example, one could imagine being able to swap out the implementation of a table's underlying store. One could imagine a runtime system that could detect the optimal store type, and the optimal set of indexes. Etc.
Again, however, this sort of thinking requires a high level computational model, and I'm afraid that our existing low-level languages such as C++ do not meet the minimum requirements. Java is only a modest step up.
Marshall Received on Thu Feb 01 2007 - 09:01:48 CET