Re: Data Redundancy

Marshall Spight wrote:
> dawn wrote:
> >
> > Or maybe with declarative constraints you have to a) figure out what
> > you want to happen (function) so you can b) translate that into the
> > correct declarative programming language statements (data) that your
> > constraint engine will use as input. However, with procedural
> > constraints you simply figure out what you want to happen (function)
> > and write it (function).
>
> Constraints aren't about something happening. If anything,
> they are about something not happening.

If nothing is happening with a declared constraint, then what's the purpose (that is rhetorical -- what I mean is: Of course something happens, verification, for example).

> Declarative languages
> don't have statements.

I thought you might not like that choice of words, so "declaration" then

> > It's a perspective thing, perhaps?
>
> It can always be said to be a perspective thing: there are
> perspectives that lead us to correct conclusions, and ones
> that don't. There are valid perspectives and invalid ones.
>
> Anyway, it's pretty clear that you're missing my points.

No, Marshall, in this case I do understand, but I disagree. On this one, perhaps you will permit me to be the teacher?

The issue of parameters and declarations compared to functions and process is age-old. We don't need to debate it any longer since it is a "two-sides of a coin" issue and I'm not trying to change you from data-centric to process-centric thinking, but get you to see that both are valid. Think of it as one of those foreground / background tests where you need to be able to move back and forth between them.

Throughout the entire process of developing sofware we decide what to form into input/output (data) and what to form into process (functions). A constraint in a SQL-DBMS is input to a process that does something, otherwise it is worthless. I often see software development as treating software as a giant F(x) = y function, Computer(input) = output (which, quite naturally, gets me into hot water in this forum). As an alternative to this input -> processing -> output perspective is what mAsterdam occasionally reminds me is a data-centric perspective such as: capture -> data -> presentation.

There is not something inherently better about either approach (your valid/invalid statement). There is something better about being able to see both.

Grasshopper? smiles. --dawn Received on Fri Feb 17 2006 - 17:50:38 CET