Subj : Re: Polymorphism sucks [Was: Paradigms which way to go?]
To   : comp.programming,comp.object
From : topmind
Date : Mon Aug 08 2005 11:42 pm

I am splitting my replies into 2 or more sections because
this thread has grown too big.

Chris Sonnack wrote:
> topmind writes:
>
> >> 	They're still tree-like,
> >> 	They're still very hierarchical.
> >
> > "Semi", maybe. "Very", no.
>
> We've been going around this mulberry bush too long, and I'm sick of it.
> Let's just assume the next posts will all be a variation of "yes it
> is", "no it isn't" and agree to disagree.  I find breaking a task down
> into outline form productive, obviously a lot of people do, you don't,
> end of story.

I also use "mental trees" when breaking down tasks for analysis, but it
is highly draft-mode. When it comes to actual implementation, one
factors and rerranges such that the treeness shrinks as it grows into
production.

>
>
> >> Obviously.  Classes have code+data.  They are "active" or "intelligent".
> >> Records are just data.  No code, no activeness, no intelligence.
> >
> > The brain is merely a bunch of "weighting factors" between nodes and
> > links where there does not happen to be signals running through a given
> > part of it. The brain must be a piece of junk then, eh? The brian is
> > mostly "just data".
>
> The brain is much more than its interconnections.  The brain ALSO has
> the mechanism that makes it active--specifically the chemistry of the
> synapses.  In a sense, the brain is like a class: it has the data and
> code that operates on that data.

I suppose any paradigm can model a general brain. I don't see anything
about it that is inherently OO over others. One can just as easily,
perhaps more easily, view it as a many-to-many table of weighting
factors.

>
>
> >> If your "binary digit analogy" is supposed to illustrate that programmers
> >> don't need to be concerned with 1s and 0s, it's incorrect.  Programmers
> >> very definately benefit from understanding the 1s and 0s.  In some cases,
> >> it's *necessary* to solve or understand a problem.
> >
> > I don't know if "necessary" is the case, because there are things such
> > as fuzzy logic.
>
> Do you think fuzzy logic is implemented without binary?


Our computers currently use binary, but 3-ary and 4-ary
modles are certainly possible and some quantum theorists
suspect that future chips may use multiple states instead
of just 2. They are interchangable; each can emulate the
other.


>
> Regardless, some problems--and I had a couple specific ones in mind when
> I wrote the above--are/were only solvable by grokking the 1s and 0s.

Only? I suppose every dog has its day.

>
> > However, we still use boolean algebra for boolean expressions I have
> > to agree. But still this is because we find boolean alg useful,
> > NOT because our chips may be based on it. (4-state chips are under
> > research, I would note).
>
> Multi-state logic is built on binary logic.  Learn basic information
> theory.  It ALL can be broken down to 1s and 0s.  Every, um, BIT of it.
>

Learn about Turing-Complete, emulation, and substitutability.
They can be built on n-ary state systems and they are all
interchangable. Today's hardware is not necessarily tomorrow's.

I lot of production RDBMS use 3-value logic because of those
damned Null's, I would note. (Personally, I would like to
see Null tossed or reduced.)

>
> >> Fail to understand [trees] at your cost, not your benefit.
> >
> > Same with sets.
>
> Absolutely.  (Are you implicitly agreeing trees are as important as
> sets to a well-rounded programmer?)

Yes. Trees for the small and demos, sets for real projects.

>
>
> >>>> Think you can write an SQL query to return a subset of
> >>>> the records in that table?   Of COURSE you can.
> >>>
> >>> If it has one table, it is still relational.
>
> (This, as stated, is *absolutely* incorrect, BTW.)

Prove it. Relational does NOT need multiple
tables. "Relational" does NOT mean "linking".
Look it up.

>
> >> ?!?!  Are you quite sure about that?
> >>
> >> What do the fields relate to?
> >> Where's your FKs and relationships?
> >> Where's your one-to-many or many-to-many?
> >
> > All these can be done with a single table. For example, a "parentID"
> > reference can be a foreign key to the same table.
>
> You could, although I'm not sure you'd end up with a purely relational
> database that way (I'll have to think about that one).  I am pretty
> sure it would only work under very specific data requirements.
>
> Regardless, in the case I had in mind, it wasn't.  The question remains:
> given a flat-table (non-relational) database, can you still write an
> SQL query.  Answer: of course you can.  SQL is JUST a query language.

What exactly is a "flat" table?

>
> >> Where's your data normalization?
> >
> > I am not sure normalization is a requirement for "relational".
>
> For the pure (mathematical) definition, I'm pretty sure it's one of
> the central, defining features!
>
> http://en.wikipedia.org/wiki/Database_normalization


I dispute that. Poorly-factored Boolean algebra is *still*
Boolean algebra, for example.


>
> (Interesting reading, that.  I hadn't realized there was a fifth and
> sixth normal form.)

They are often not very practical, and in some cases seem
to increase redundancy.

>
> > However, there are different ways to interpret "duplication" for
> > empty cells. Empty cells do not have to take up physical space,
> > especially in "dynamic relational".
>
> Empty cells?  Where did that come from?  Are you talking about NULL
> fields?  Row duplication??  What???

This is getting into a long, drawn out debate about the
nature of relational. Here is something related:

http://www.c2.com/cgi/wiki?TupleDefinitionDiscussion

>
> >> Let me ask this: how do *you* define "relational database"??
> >
> > Note that "relational" does not mean cross-references between multiple
> > tables, contrary to popular belief. "Relational" actually is a
> > mathematical term for "table". The term does NOT mean inter-connected.
>
> http://en.wikipedia.org/wiki/Relational_model
>
> It starts out, "The fundamental assumption of the relational model is
> that all data are represented as mathematical relations,..."
>                                               ^^^^^^^^^
> Sounds interconnected to me.

Well, it is misleading. The same link also says:

"A table is an accepted visual representation of a relation; a tuple is
similar to the concept of row."

>
>
> >> No, it's a data storage concept.  There are many reasons why the
> >> physical storage location might change.
> >
> > Huh? Please clarify.
>
> Migration, rollups, new systems, OS changes, format changes, etc., etc.

Yes, but ideally we abstract away from those. For example, we may
create an ODBC name for a database reference. Even if the machine
is moved, that same name can still point to the same one.
(In the real world sometimes things need to be split for
performance or jurisdiction reasons. But this is true
of everything.)

>
> >> Let me see if I can make this as simple as possible..... there's really
> >> NO difference between having a file in "BobsProject" directory verses
> >> it having a "BobsProject" attribute in a database.
> >
> > Yes there is. Tree leafs are uniquely indexed by their path.
>
> Exactly as any record is uniquely indexed by its key(s).

But keys are fragile. That is why it is often best to have
"dumb" keys that don't carry any meaning.

>
> > If you yank or change a segment in the path, you bust an existing "key".
>
> Yep.
>
> > And if there was no difference, then why not go with sets?
>
> File systems have more flexibility than databases.

Fooey! You already agreed that paths were fragile, being
hard-to-change.

>
> Consider this: what happens when several of my files *ARE* databases.
> Big ones.

I am not sure what you are getting at. That is a DB implementation
detail. A DB can be implemented with Tinkertoys (Harvard
project?) if one wants to wait long enuf for the results.

http://www.cob.sfasu.edu/sbradley/tinkertoy.html


>
> Or consider this: in a FS, I can define a folder as publically shared,
> read-only, and any file I drop in there is available to those I've
> shared the folder to.  I can casually share and unshare files just
> by moving them in and out of the folder.

I see no reason why a relational system cannot have the same
kind of thing. However, usually you will find that security
is not hierarchical as it scales. This is why we have things
such as Access Control Lists, which are essentially many-to-many
tables.

>
> >> If "BobsProject" becomes obsolete and leaves the system, I'll still fail
> >> to find the directory or file.  With a browser, at least I can poke
> >> around to see if I find something helpful.  With search dialog, I'm
> >> left tryingt to think of other search parameters.
> >
> > I am not sure what you mean here.
>
> The UK was "BobsProject". Bob left. Someone changed the UK, but I don't
> know the new one.  In a normal filesystem I could poke around in the
> general area where project files were stored and very likely find it
> (I know this, because I've done it).
>
> With a database, you can only hope there's an attribute still attached
> that might turn it up in a query.  Maybe so, maybe not.  Maybe when
> Fred took over, he changed the attributes just slightly due to his own
> personal preferences.

Just because you are not adept at non-tree searches does not mean
the rest of us are also not. I have lost stuff in trees many times.
The solution was to do non-tree searches (start-to-end)
to hunt for attributes.

A relational system would make it easier to put meta-data tags
on something with less worrying about other tags or whether
our classification approach is on the "right track".

Sets also have "near", it is just a multi-dimensional "near".
Trees are stuck in 2D.

[end of part 1]

-T-

.