Re: Pizza Example

"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message news:c5egh1$d3l$1_at_news.netins.net...
> "Eric Kaun" <ekaun_at_yahoo.com> wrote in message
> news:HLyec.53517$CH6.17237_at_newssvr16.news.prodigy.com...
>
> > Of course it's amenable, just much less so. It's its lack of symmetry
and
> > consistency that poses a problem. By nesting values inside values (and
> then
> > a further layer inside that, I believe), you complicate the algebras,
> > closure, and optimizations. Relational is much simpler, hence its power.
>
> Possibly conceptually simpler as a mathematical model, but in real life it
> does not seem to be simpler at all. The end-user sees it as symmetric
once
> the vocabulary is in place for that to be the case.
>
> LIST STUDENTS COURSES WITH COURSE_NAME LIKE "A..."
> might list the students and all of their courses with a name starting with
A
>
> LIST COURSES STUDENTS WITH STUDENT_NAME LIKE "A..."
> might list the courses and all of their students with a name starting with
A
>
> It is not symmetric when the vocabularly has not been put in place for it
to
> be so, for example, if the student name (which would obviously not be the
> stored foreign key for the student and is not physically stored in the
> COURSES file) is not placed in the vocabularly of the COURSES
> file/graph/tree/function.

I see. It just seems like you're simulating symmetrical access (e.g. relational joins) by mapping a hierarchical structure into a pseudo-relational view. Is creating this vocabulary necessary for any linkages, regardless of "nesting level"?

> > On a related note, things like objects add a great deal of complexity in
> the
> > pursuit of "intuitive" modeling techniques; specifically hierarchies,
> > graphs, and a persistent (no pun intended) confusion between variables
and
> > values. That additional complexity always comes at a cost, and it's
> > unfortunate that people are so uncomfortable with symbolic logic and
> related
> > disciplines that they bite into much more complexity than they would
> > otherwise have to, simply because the "operational" (procedural)
approach
> > appears intuitive.
>
> It doesn't just "appear" intuitive -- it typically IS more
> intuitive. --dawn

Maybe, but I still wouldn't base a computational model on intuition. After all, the aim of symbolic logic (and Leibniz's Dream) is to automate reasoning through sheer symbol manipulation - precisely what formal means (pertaining only to form - symbolic representation). So we're at something of a crossroads - we either proceed in a direction that continues to make intuitive sense (and if it's to end users, I'd place little stock in this), or we proceed down a path of greater automation.

I don't see the two converging, just as none of the "higher-level" languages have ever succeeded (or WILL ever succeed) in making end-users into programmers. We may as well bite the bullet and use effective means for automating reasoning, which is the reason (no pun intended) that we invented the lil' buggers...

> P.S. I've been mulling over Date's write-up on the issue of whether a
class
> can "be" a relation. The argument against it seems to come down to ...
"If
> you were to create a class that defines a relation type, then you would no
> longer be consistently following the relational model". I suspect I'll
have
> some questions or opinions on that matter soon.

Since you're so good at it, how about starting another thread? I have some things to say on this, and it's a neat discussion, but I'd rather you launched it...

• erk

P.S. Thanks for lots of good topics... we may disagree, but I always find it interesting and informative. Received on Tue Apr 13 2004 - 01:48:18 CEST