Re: XQuery (and XML) vs LISP

"Marshall Spight" <marshall.spight_at_gmail.com> wrote:

>Mark Johnson wrote:
>> "Marshall Spight" <marshall.spight_at_gmail.com> wrote:

>> >> Such examples that are shown are trivial. You don't pay
>> >> someone to do something that easy, that simple.
>> >> A real world requirement isn't anything like that.

>I understood you to be objecting to simple examples,
>and I assert that simple examples are the best way
>to illustrate concepts. Certainly they do not make
>real systems; their purpose is didactic, not practical.

Which is a basic principal of any apprenticeship. Unreal examples to prepare for productive application. I understand that. But it's also the common complaint with academics. There could be many reasons why the impractical never is made practical. But it is a complaint.

>That does not mean the concepts so illustrated are
>not practical, though.

I agree. Or it could even be the case that they know the utility, but for proprietary reasons, refuse to share that knowledge in their papers. It might be deduced by someone with background or some gamester's clue, if you will. But the simplest, accurate explanation must also allow for the possibility that such is presented because they did not pursue the matter, and that they leave any potential ulitity as an 'exercise for the reader'. Had they pursued it, perhaps they wouldn't have published, in short. There are too many papers out there, as it is.

>Consider the original K&R "C Programming Language."
>All the programs in it were quite small and limited.
>A simple hash table, for example. Yet the book is
>a classic.

I believe the Kernighan book was a text, in that era, as well, because it was considered the definitive text on the subject.

>In any event, let me be explicit in saying that I do not
>consider the typical employee/department examples used
>in SQL books to be pointless; on the contrary they are quite
>valuable.

I'd have to disagree. They represent that common complaint with academic papers. But you to your opinion. And me to mine.

>> >Of course. When you're writing a book about a technique, you
>> >show what it's good for, not what it's bad for.

>> Sounds more like promotion or salesmanship.

>What's wrong with that?

I said what was wrong with that in the very next sentence.

You only hear about what was wrong with last year's model when it comes time to sell next year's model.

>it by reading your mind. You promote something by showing
>what it's good for; any other choice is ineffective.

But it might be more responsible, and your civic duty.

>> >There are some things that SQL does extraordinarily well.

>> In fact, wasn't it one of Codd's rules that SQL be the means of
>> manipulation, rather than some other sort of code, in addition?

>Why did you excerpt my "There are some things" sentence
>and follow it with what you did? It seems a complete non
>sequitur.

Because:

>And as I said, I have no particular desire (nor ability) to discuss
>Codd.

Okay.

>> >I want it small; that will make it easier to understand.

>> But there's a problem with that. One of those is - scale. How does it
>> scale? Does it scale?

>It turns out that SQL scales quite well

But what about such a scheme as I suggested, which was the point?

>I want it small; that will make it easier to understand.

But there's a problem with that. One of those is - scale. How does it scale? Does it scale? The subject, here, is technical papers and presentations. And in addition, do the trivial academic examples conceal a fundamental problem with the approach? Does it work only narrowly and in the most simply contrived situation, even regardless of scale?

>> The subject, here, is technical papers and presentations.

>It is? When did it become so, just with this sentence?

. . .

>> And in addition, do the trivial academic examples
>> conceal a fundamental problem with the approach? Does it work only
>> narrowly and in the most simply contrived situation, even regardless
>> of scale?

>I don't understand the purpose of these questions. Are they rhetorical?
>It seems fairly clear that the answers to these questions is "no."

Well perhaps the answer is - yes - they do conceal a basic problem, they do not scale, they cannot handle another common set of data, etc.

>Do you have any experience with SQL?

Yes I do. I don't know how you imagined I was discussing SQL in referring to "trivial academic examples". I was instead referring to "trivial academic examples".

>> I was simply saying that relations tend to multiply, and so joins.

>Yes. Software tends to grow in complexity as we add new features
>and functionality, and capture more data.

>If we program in an OOPL, the number of classes goes up over time.
>If we program in an FPL, the number of functions goes up over time.
>This is a good thing.

Unless it simply piles confusion upon confusion, and does not allow for a simple cover and vector redirection to an improved recipe that incorporates a clearer understanding of the previous technology. It's not really comparable to this idea of normalization, itself, however.

>> You may think it's a sort of pointless question. I don't know. Just
>> throw in whatever 'sounds good', and call it an entity?

>Could it be that when you ask "what is a type" what
>you're really asking is, how do we define tables? (I say this
>because you mentioned the word "entity".)

I glad I did mention the word, "entity", even if not parethetically. Yes, I am referring to relations, and what goes in one, and not the other.

>> >Tables and joins aren't an expense to be minimized.
>> >Columns aren't something you want to be sure to have
>> >the fewest of, no more so than rows.

>> In other words, what if an attribute doesn't belong?

>Then you put it where it does belong.
>Am I to take it that you haven't done much data modelling?

How does data modelling answer:

>> An 'instantiated' class is created in one or more processes, before
>> anything else, let's say. Following the book question, what's the
>> scheme for that? A process might apply to the class, but also to
>> another class. But is the process properly part of the class
>> relations, or is a linked set of relations specifying class more
>> properly a thing that belongs with the process relations? Is there
>> some convention that's been used, for any particular reason? Maybe
>> this question has been trivially answered, and years ago. It's not
>> that one can't view class in terms of process, and vis-versa, from the
>> same data. And I understand it, that supposedly is a benefit of RM.
>> But why does what go where in the underlying relations? Does it
>> matter?

>I really had a hard time understanding this paragraph. It sounds like
>you're asking how table design is done, but I could be completely
>wrong.

I'm simply asking what goes where, why, and for any particular cause. Does it matter? Just slap together some 'things', and call it an, entity? And then what happens when the next book comes along, or the new technology that is being similarly represented as relations?

I just don't know. Maybe it seems a really pointless question?

>> >"Just think of the joins" is the same non-problem as
>> >"too many classes."

>> They're not comparable.

>I can't think of a difference. Can you?

I said they weren't comparable. That means I can't see any similarity.

I can definitely see a problem with having to run too many joins in a SQL query.

>> And are you suggesting that a SQL statement
>> consisting of many joins would not seem rather cumbersome, and even
>> prone to error for that?

>For me, calculus seems cumbersome and prone to error; is this
>a flaw of calculus, or a limitation of mine?

You will notice in some that scale, a measuring scale, is important in certain placeholders. Quantity of some type, some sort. But if you mean just attempting to represent a SQL statement mathematically, rather than mathematics in general, wouldn't that also be error prone the more verbose the formula becomes? You would be attempting not to block a few elements, and then a few more, as any coder, or mathematician, would do. You would be faced with the 'reams of paper' problem, instead.

>Again, it's not "excessive" if that's what's necessary to get
>the job done. Complicated problems often have complicated
>solutions.

Simple problems also often tend to consume far more time than imagined. That's because people don't foresee the difficulty in what they imagined was a simple problem. Sometimes, what seems complicated, by the mechanisms used, by the scheme in place, requires changing a single pointer, or something. I guess there's a difference between anticipatory classification or qualification, and the same in hindsight.

>> Rather, I was merely agreeing with you. Structure is transcendent of
>> any scheme. The scheme must represent that structure, or it represents
>> something else. I can't state it more clearly than that.

>Okay.

And then the question becomes, what IS that structure? Received on Sat Feb 18 2006 - 20:48:11 CET