Re: An object-oriented network DBMS from relational DBMS point of view

From: Marshall <marshall.spight_at_gmail.com>
Date: 14 Mar 2007 18:18:00 -0700
Message-ID: <1173921480.946628.245600_at_l77g2000hsb.googlegroups.com>


On Mar 14, 4:44 am, "Dmitry Shuklin" <shuk..._at_bk.ru> wrote:
> On 13 อมา, 20:42, "Marshall" <marshall.spi..._at_gmail.com> wrote:
>
> > This is categorically false. There are no problems that can
> > be solved with pointers that cannot be solved without them.
>
> This is categorically true.

How so? Certainly arithmetic works just fine without pointers. Tony mentioned the lambda calculus, which also lacks pointers, as does the relational algebra. Some of these are even computationally complete.

Certainly it is true that there is no *computation* that requires pointers.

> All today successfull programming languages have pointers or
> references.

What is your definition of "successful?" Certainly there are popular languages with pointers; this by itself is not much of a testimonial, though. When I look at job boards in the USA I see more listings that mention SQL than I do that mention C++; does that mean SQL wins now? Does the installed base of Windows mean it is the most technically advanced operating system?

I do not dismiss popularity as a metric, but neither do I place much importance on it. Certainly it is important from a *business* perspective, however my field is not sales and marketing.

> Many of today successfull RDB projects have surrogate identifiers (=
> pointers emulation)

Surrogate identifiers, as I understand the term, are not pointers, nor are they pointer emulation.

To the extent that RDBMS products or standards *do* include pointers, this is a response to market realities rather than a technical need. There are many who mistakenly feel that pointers are somehow necessary, as this thread illustrates.

> > (Unless you are referring to very low level programming such
> > as device drivers. And really, it's not even strictly true there.)
>
> Ok, You are right here, I am started programming from writing drivers
> more than 15 year ago)))
> Let consider writing drivers as abstract task. You say that it will be
> almost impossible to write driver without references or pointers
> support. Is it?

Impossible is a strong word. But probably we don't even need it--if I had to write a device driver, I'd probably use C, and use pointers to boot. Right tool for the job and all. But that doesn't mean I think pointers are a good technique, or that C is a high level language. On the contrary, C is quite a low level language. Generally it is a good idea to work at as high a level as one can, which directly leads us to the conclusion that C should be avoided wherever possible.

> From other hand it will be easy to do with pointers. Ok? So system
> with pointers support is full and system without them is not full ;)

Again, a word like "full" isn't very helpful without some more specific context. I've already pointed out that pointers are unnecessary for complete computational models.

If the topic at hand is writing device drivers, then I have nothing much to say. However device drivers are a very specific niche within software development, and again, very low level. We should not measure software development by the standards of device drivers. In fact, it should be a strong goal to make as much of software development as unlike device drivers as possible.

> > > I don't see any complexity wich was appeared with pointers. But I see
> > > it when pointers gone.
>
> > Consider the plight of the C programmer, who cannot statically
> > tell the type of the thing pointed to by a pointer, nor whether
> > there is aliasing, nor whether it even points to actual memory.
>
> The world not stay in one point. Do you know about managed pointers?
> C# or Java for example.

Consider the plight of the Java programmer, who cannot statically tell whether a reference refers to an actual object or not (it may be null), nor whether there is any aliasing. He cannot preserve pointer semantics across more than one serialized stream, and generally doesn't know why. NullPointerException is a very common source of Java program premature termination, and yet this could be completely eliminated with better static analysis, or with simply removing pointers from the model completely.

Also, you did not address my point about complexity.

> > If you don't see any complexity with pointers, you need to learn
> > more about pointers.
>
> Are you sure that you don't need learn more about modern
> programming? ;)

On the contrary, I am constantly reading about modern programming, and wish to learn much, much more. However, if you think C# and Java represent "modern" programming, then clearly I'm way ahead of you.

I also note that you have sidestepped my point that pointers bring a complexity which is a significant source of bugs, and you profess to be unaware of that. This suggests you are not a good candidate to compare models.

> > Well, of course they can "do the same". You can do the
> > same with just cons cells and the lambda calculus. Or
> > just with Turing machines. Whether two systems can
> > do the same thing or not is generally a trivial question,
> > since pretty much all systems are computationally
> > equivalent.
>
> It is very interesting question. To solve it we should remember about
> Turchin and Meta-System Transition
> When one MT emulating another MT the Meta-System Transition is
> appearing. I say that I can do on my network DBMS all which RDMBS can
> without this meta-system transition. But vice-versa is not true. RDBMS
> can do all what can do my db only after MST.

I am unfamiliar with Turchin's work. I am more familiar with Church and Turing and those fellows. I again point out that the lambda calculus is as computationally powerful as it is possible to be, and does not contain pointers. Turing machines likewise.

> > You claim to be doing a
> > comparison of two types of systems but you apparently
> > don't know very much about either one!
>
> Ha Ha Ha,

You laugh, but you do nothing to dispel my points.

Marshall Received on Thu Mar 15 2007 - 02:18:00 CET

Original text of this message