Re: Objects and Relations

From: Marshall <>
Date: 1 Feb 2007 00:01:48 -0800
Message-ID: <>

On Jan 31, 6:13 pm, "David BL" <> wrote:
> On Feb 1, 12:24 am, Bob Badour <> 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.

Radical? Yes.

I have the utmost respect for C++. It was the premiere language of the 1990s, and a huge step ahead of C. However I hope never to have to use it again.

> 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

Original text of this message