Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

From: Marshall <>
Date: 2 Jun 2006 07:28:59 -0700
Message-ID: <>

Dmitry A. Kazakov wrote:
> On 1 Jun 2006 14:41:07 -0700, Mikito Harakiri wrote:
> [ What I really don't understand, is why DB guys so stick to their sacral
> data. ...]

In general, it is because they have tried both ways and found the data oriented way to be dramatically superior. That's the answer in my case, anyway.

> > This is an interesting objection. While the question if the two
> > functions are equivalent is certainly important from relational engine
> > perspective (otherwise how would you do optimization?), it remains to
> > demonstrate that the end-user migh ask this question as well.
> Ooch, how do you know what will be asked?

Since he made no claim about what would be asked, your response in a non-sequitur.

> The formalism shall either forbid
> the very question, or else give a reasonable answer to. If functions are
> comparable they must be.

It isn't always the formalism that is doing the forbidding. Some things are undecidable, period; a formalism that can handle the halting problem cannot exist. This doesn't mean the formalism "forbids" it.

Anyway, this question about the equivalence of functions is a red herring. Function literals can be compared, trivially; comparing the semantic equivalence of functions is undecidable. That makes how to deal with this question obvious: you support the first and not the second.

> I don't care, because it is quite obvious that even if you get things
> described as relations, that would not get you a reasonable implementation
> of. You can neither effectively translate it to existing machine languages,
> nor create a relational hardware (here I mean things like quantum
> computing). The notation itself is very heavy for mortals.

Each of these three sentences is false.

> Relations don't fit well. They have too low abstraction level.

> RM fanatics might claim that C/C++ does not deserve any attention, being a
> crap. I don't like it either, but it is not a serious argument. Software
> written in C/C++ works [sometimes (:-))], that's reality to face. Why it
> works, how it does, when it will stop working, how a better language should
> look like?

Those are big questions. And by the way, I don't claim C++ shouldn't be studied; it should. Partly as a negative example, partly for the generic type system.

Marshall Received on Fri Jun 02 2006 - 16:28:59 CEST

Original text of this message