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

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Thu, 15 Mar 2007 01:31:26 GMT
Message-ID: <Ol1Kh.10589$PV3.107063@ursa-nb00s0.nbnet.nb.ca>

Marshall wrote:

> 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.

I disagree. No market ever existed for them, and the market never took them up. Self-aggrandizing ignorants pushed them into the standard because they were stupid enough to believe their own bullshit.

>>>(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.

Device drivers are not programming -- they are plumbing. The hardware dictates everything.

  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.

Start with a simple structure like a relation that is both necessary and sufficient. Adding another structure, such as a pointer, increases complexity without any compensating benefit.

>>>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.

Self-aggrandizing ignorants have no desire to learn. If they remain ignorant, they can continue to deny awareness.

>>>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.
Received on Wed Mar 14 2007 - 20:31:26 CDT