Re: All hail Neo!
Date: Thu, 27 Apr 2006 03:38:22 GMT
Message-ID: <O0X3g.17127$vy1.4507_at_news-server.bigpond.net.au>
Bob Badour wrote:
> Frank Hamersley wrote:
>> Bob Badour wrote: >>> Frank Hamersley wrote: >>>> Bob Badour wrote: >>>>> Frank Hamersley wrote: >>>>>> Bob Badour wrote: >>>>>>> Frank Hamersley wrote: >>>>>>>> Bob Badour wrote: >>>>>>>>> Frank Hamersley wrote: >>>>>>>>>> Bob Badour wrote: >>
[..]
>> >> Preempting some of your various replies below you seem to be getting >> fatigued of this topic. Regardless, for me the RM is the theory and >> SQL is the practice. Sure the latter "contains" some or all the >> former but using this distinction adequately provides terms or >> reference for me as "where we are" against "where we want to be". I >> don't think I can help you much more than that.
>
> It's rather presumptuous of you to think I need any help.
Very true - it was presumptuous - but I am not here to necessarily to change your thinking, more to enhance mine. From your previous reply I had developed a concern you were about to disengage and wanted to move on from the theory/practice hurdle if it were to be an impediment.
> SQL is rather
> flawed theory based on multisets or bags and 3-vl, sort of. Ignoring the
> principle of cautious design, those who first created SQL made arbitrary
> and unecessary decisions that altered the theory dramatically from where
> it started in the RM.
Perhaps that is the genesis ... however my interest lies more in the future state of affairs (80/20 of course).
> To say that SQL is not theory is just plain wrong. And to suggest that
> the impractical consequences of those arbitrary decisions makes SQL
> somehow practical is perverse.
Misinterp - I simply state SQL contains the "easy" parts of the theory and happily admit it has shortcomings as a result. The mention of this distinction is purely for establishing nomenclature - there is no debate to be had.
>> [..] >> >>> Missing information is messy and we have no theory at all for >>> addressing it. Adding it to the RM in no way reduces the elegance, >>> symmetry or compellingness of the RM. >> >> Rubbish - IMO the whole is less for the adding the messy bit without >> resolving it to meet the ES+C criteria. Sure the other parts are just >> as ES+C as they were before when taken in isolation. This is akin to >> the mess that existed in the prediction of planetary orbits prior to >> Newtons apple.
>
> More nonsensical handwaving. Since you don't have anything substantive
> to offer, you will be joining the self-aggrandizing ignorants at the
> bottom of the killfile.
As I predicted - cu round like a rissole! Seeing this post I was going to retract (the luxury of offline replies) but it can stand!
>>> Either one can use the E,S&C to tackle the difficult problem, or one >>> can pretend the problem doesn't exist. >> >> This sounds overtly minimalist on your part. If I read it correctly >> on the one hand you state there is no theory to support missing info >> and then you propose to solve the issue solely with the theory at hand >> whilst dismissing all other possibilities - to toss in a barb that >> seem as ostrich like as it gets.
>
> Pretending that null solves the problem of missing information is as
> ostrich-like as it gets. "Problem? What problem? We have null."
Did I say that? Take the blue one Bob, avoid the reds!
> Except that null only exacerbates the problem while creating myriad new
> problems. You have said nothing that addresses this fact--a fact well
> documented over the past 20 years.
What is there to say ... your sentence contains a tautology? As I have said before "ante up" - you want to call nulls bluff so do it! As for me I have no silver bullet but feel compelled to call a dud as it is viz my D+D D comments.
>>> It reduces the expressiveness of the language and hides people's >>> errors from them. Can you imagine a compiler that refused to reject >>> any program or issue any warning? >> >> Nup - unless the optimizer deduced the erroneous code was unreachable! >> That of course would be pointlessness^2.
>
> Yes, a language that allows one only to describe unreachable code would
> be rather pointless. But not quite as pointless as your response.
FWIR eradicating redundant statements was one of the early HLL compiler optimisations. In respect of syntax errors it is fallacious however it was only meant to illustrate a counterpoint. BTW wheres the speeling mistake?
>>>>> Whether nulls exist in the RM today is a topic of some controversy. >>>> >>>> Sure is - in biological terms noting that the bastard child SQL >>>> inherits only half its genome from the known parent (RM) then the >>>> question is - is it a meiotic mutation or a pre-existing recessive >>>> allele now homozygous and perhaps deleterious? >>> >>> Nonsensical handwaving. >> >> Is this code for I don't understand or simply can't be bothered?
>
> It says exactly what it says. Your 'contributions' are almost entirely
> void of substantive content. SQL is not a product of sexual
> reproduction. If you are confused on that point, you have much more
> serious problems than I am starting to believe.
Bob - you don't have an alter ego called Eliza do you? She had no wit or expressiveness either!
>>>> Yep - although there probably no debate to be had once the various >>>> and varying starting points are determined. >>> >>> More nonsensical handwaving. You have succeeded in one thing with >>> your evasiveness: you have demonstrated your lack of intellectual >>> honesty and integrity. >> >> More fatigue?
>
> No, just a realistic evaluation of your worth as a participant here.
Fair enough.
>>>> OK. Obviously useful for the theorist to explore stuff (apols to >>>> Alexi). >>> >>> Obviously useful for the practitioner to explore as well. If the >>> practitioner never considers where the pitfalls lie, he will only >>> discover them from the bottom of the pit. >> >> Sure - and these pits are often filled with tar! What I was alluding >> to is a practitioner accepting the theory can avoid exploring the pits >> by sticking to the provided map. Of course it is a worthy goal for >> all practitioners to understand as well as apply best practice.
>
> More nonsensical handwaving. We were not discussing a single theory but
> comparing formalisms. A practitioner, who is unable to choose notations
> and evaluate formalisms, or who is unwilling to think, has no real
> business in computing.
Come in number 66 ... are you in trouble number 99? (A pointless waste of electrons but cheap at twice the price nonetheless).
>>>> So {1} and {1} are not distinct when conceptually imagined in an OO
>>>> instance frame of mind?
>>>
>>> An OO instance is a variable. Thus the values of the two variables
>>> are indistinct even if the variables themselves are distinct and
>>> distinguishable by physical location.
>>
>> No drama here.
>
> But what is the physical location of a variable in a distributed database.
Que? Smells like trolling based on past experience in CDT.
[..]
>>> And since all of programming is about formalism, I suggest null has >>> no effective role to play in any aspect of programming. >> >> Very sloppy words! I would say intellectual honesty arises when you >> are prepared to say something like "since all of programming *theory* >> is about formalism, I suggest null has no effective role to play ..."
>
> I stand by my words. Programming is applied mathematics even if most of
> the so-called programmers in the world are too stupid and too ignorant
> to even conceive of such a thing.
Too narrow for me but whatever turns your dial is OK with me.
> A program itself is a proof of some theory. Sadly, most programs written
> prove the wrong theory.
As market forces so often determine to be the case.
>> Of course I would be interested to see you ante up and describe a >> fundamental and complete solution rather than simply taking your bat >> and ball home.
>
> The relational model without any additional adornment suffices as well
> as any other formalism for handling missing information. The relational
> model is already well-described. If you want to propose a solution for
> missing information, the onus lies on you to prove the worth of the
> proposal relative to the original model.
Hmm I thought you said there is no theory for missing information. How then does the RM theory suffice?
> Null reduces expressibility, limits opportunities for query rewriting,
> yields incorrect results, is poorly understood by many experienced
> practitioners not to mention casual users, violates the information
> principle, and in the case of SQL is inconsistent. I reject it by any
> number of objective criteria.
This is not the debate - I want you to explain how to do it without null. If your explanation is ES+C you will have a most willing disciple in me.
> Illusions of power are just that: illusions. Handling missing
> information is not easy and requires careful thought in every instance.
>
> Sure it saves time to ignore the problem and pretend that some arbitrary
> feature took care of it. But when has sloth ever excused negligence or
> recklessness?
OK - case by case is always feasible. I am then left wondering why D+D expended any effort at all in promoting a general solution?
>>>>> Are you familiar with Date's various _Writings..._ books? He and >>>>> Darwen and others have demonstrated that null causes great damage. >>>> >>>> I don't need them to postulate it as I've seen it first hand. My >>>> opinion of Date mainly and Darwen to a much lesser extent (more by >>>> association than real research) is that whilst they have taken a pot >>>> shot at a low flying albatross, they haven't come up with anything >>>> even close to better. >>> >>> I disagree. They have correctly identified that missing information >>> as of yet has no theory to address it. >> >> That is a trivial conclusion! Where's the beef? You don't need to be >> a luminary to get this far - do you?
>
> That's a preamble not a conclusion. Duh.
You raised it - Doh!
>>> While I disagree with some of their ad hoc attempts to address it >>> differently than null, I suggest the RM -- without any special >>> feature for missing information -- already handles it as well as we >>> can until someone establishes a valid theory addressing missing >>> information.
<Second proof reading>
Ah so - I think I now understand our disconnect. This being CDT I was
looking for a general ES+C solution. You on the other hand state there
is no theory but do not accept the polluting of the RM with null
insisting that case by case treatment should be enforced by SQL until
the gap in the theory is resolved.
Do you think this latter eventuality will ever arise as there does not seem any impetus for the mathematicians to pollute the archetypal theory of sets with the missing set?
The rest of the post is left for posterity - consider it jousting for sport. </Second proof reading>
>>> Null takes a bad situation and makes it worse. It does harm. Removing >>> it improves our lot. >> >> I'm all eyes! I'm happy to consign null to oblivion if you give me a >> _credible_ solution which means it must meet ES+C to accommodate my >> limited analytical abilities.
>
> I already have: the relational model. It handles missing information as
> well as or better than any other formalism at this time.
Please cite examples - then I can go read and get some work done to boot.
>>>> Given the lesser evil option I expect to rely on skilled >>>> practitioners to mitigate the risk of that damage arising. Sadly >>>> they don't grow on trees! >>> >>> All the more reason to make simple queries easier to express >>> correctly so casual users do not have to waste the time of skilled >>> practitioners for very common, mundane queries. >> >> I can relate to that - but I for one don't see your mundane queries as >> in the problem domain. Viable practitioners can design RM compliant >> systems using SQL if required. The real issue is solving the >> difficult queries - something which D+D skate glibly over as I pointed >> out.
>
> You seem to object to describing data using more simple sentences and
> fewer complex sentences where the sentences are predicates.
>
> Can you offer an example of a difficult query and describe how
> decomposing the relations as presented on that slide will make the query
> too difficult for a skilled practitioner?
Why do I need to do that? Darwen himself foreshadowed it in the footnote. BTW I thought the holy grail was for unskilled practitioners to become adepts.
>>>>> Nulls attempt to address missing information but do so with no >>>>> basis in theory. I suggest that the null elixir only offers the >>>>> illusion of power: >>>>> http://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD898.html >>>> >>>> I understand your view. For the record mine is that null is no >>>> elixir - more like Cod Liver Oil and there ain't no illusions when >>>> swallowing that stuff. >>> >>> If one takes the average age of a group of people where some of the >>> ages are unknown, then the average is unknown. With a relational >>> dbms, I can model the ages so that it returns the correct result, >>> unknown. >> >> I can cope with that - I would have no problem being forced to write >> >> "select avg(age) from table where age is not null" >> >> to get the crappy statistic that it is if the user demanded it. But I >> thought you wanted to eradicate the nulls period?
>
> I agree it is no problem to write the query to get the average ages
> where the age is known. Using null, how does one write the query to get
> the correct result, ie. the average is unknown ?
select case when count(*) = count(age)
then avg(age)
else null
end as avgage
from table
PS that attribute name really irks! Anyone else feel the same way?
> Null reduces expressibility. It is an elixir that prevents one from
> expressing inconvenient truths, but those truths do not go away. Always
> getting a finite numeric answer is merely an illusion of power.
I may be drunk but you're certainly smoking something illicit!
>>> When the user gets the result, the user has to ponder what that means >>> and how to proceed. If the user discovers that back in the old days >>> nobody bothered to record birthdates, the meaning is different than >>> if the ages are unknown because some of the people are fetuses as of >>> yet unborn. >> >> You are taking on too much methinks - if a mug user wants to buy >> birthday presents for fetii why should the RM be saddled with saving >> him from his own stupidity. Better IMO to focus on those who want to >> be saved.
>
> Where did I say anyone was buying mugs?
Worth a sigh or just being cute? Nah! Sigh.
> Your straw man is pointless;
They are your fetuses!
> stick to what I said. I have postulated two users issuing similar
> queries in very different circumstances where the correct answer to an
> average is unknown.
See above lesson on skinning cats.
> Using null, how does one express the query such that it gives the true
> and correct result that the average is unknown?
ibid
>>> Null is less expressible than the RM because it obviates the >>> possibility of returning the correct result. The result it returns is >>> incorrect and in the cases mentioned above is not even approximately >>> correct, but the user has no alert to the problem. >> >> Unskilled users yes
>
> Unskilled users. Skilled but hurried users. Skilled but fallible users.
> In other words: the universal set of users.
All true - bring on the general ES+C solution.
> Compile-time error messages are better than run-time error messages are
> better than no error messages with obviously incorrect results are
> better than no error messages with wrong but seemingly correct results.
> In the example given, null moves the error all the way down the list to
> "wrong but seemingly correct results".
True. BTW my penchant is for defense in depth and not to rely on only one of these canaries hence my direction on AVG().
>>> If that is not an illusion of power, I don't know what is. As a >>> solution for the problem of missing information, null is an elixir. >>> Since your earlier evasiveness has revealed your lack of intellectual >>> honesty, I will dismiss your denials as groundless. >> >> Ah well we all have crosses to bear - suffice to say there are no >> illusions on my part.
>
> Suffice to say I have demonstrated otherwise.
To yourself at least.
>>>> That is how I would characterise "D". On the theory side I am in a >>>> prolonged contemplation on the missing dimension in SQL (as compared >>>> to the RM) which is the temporal capability. I have made what I >>>> consider to be some progress but it is premature to discuss publicly >>>> lest I end up wearing lots of egg, suffice to say the null thang has >>>> a parallel in temporal matters. BTW I don't rate Date & Darwens >>>> offering on this either, nor FWIW much of the Snodgrass et al stuff >>>> that preceded them. >>> >>> Yes, well, get back to us when you have something substantive to >>> offer that won't leave egg on your face. >> >> No problem. In the meantime I am happy for you to advance something >> more than a simple change to the behaviour of avg().
>
> You are an idiot. Plonk.
OK - time to move on - nothing to see here folks (perhaps)!
Cheers, Frank. Received on Thu Apr 27 2006 - 05:38:22 CEST