Re: Date's First Great Blunder
Date: Thu, 15 Apr 2004 19:19:46 GMT
Message-ID: <mfBfc.2$Z%3.1_at_newssvr16.news.prodigy.com>
"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message
news:c5me33$24v$1_at_news.netins.net...
> "Eric Kaun" <ekaun_at_yahoo.com> wrote in message
> news:%syfc.637$Gl7.141_at_newssvr15.news.prodigy.com...
> > "Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message
> > news:c5k8mo$umd$1_at_news.netins.net...
> > > "Eric Kaun" <ekaun_at_yahoo.com> wrote in message
> > > news:xZgfc.268$Ha4.262_at_newssvr16.news.prodigy.com...
> > > > "Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message
> > > > news:c5jopp$hdq$1_at_news.netins.net...
> <snip>
> And isn't declarative just specifying the parms for some proprietary
> database's procedural code to apply?
Assuming that statement is right, that's still a big difference. The runtime executes one machine-code processor-specific instruction at a time (basically), which is what CPUs do. But that looks nothing like the source code (though today they tend to have more in common than they should), and the source code looks nothing like the specification, which looks nothing like the user manual.
Think about it this way: the user manual, if accurate and detailed, "looks like" the external appearance of the system at runtime. But the machine code being executed looks nothing like that.
A true specification describes, abstractly but accurately and precisely, the effects of the system. "Declarative code" describes the result, not how to get there. The procedural part is in the engine that processes the declarations, not in the declarations themselves. Among other things, this allows the engine to optimize (much as compilers these days can apply more optimizations better than most assembly programmers), and even to optimize based on runtime characteristics (e.g. how the system is being used), like Oracle can optimize its access paths based on stats generated from the actual queries run. Little of that is possible with procedural code, where the programmer has to specify not only what to do but how to do it.
> I do think that different languages
> have different advantages and disadvantages, so I'm not language-agnostic,
> but I don't see anything decidedly different whether I spec constraints in
> one language or another.
I'd be surprised if you spec constraints at all - you code, like most of us, but where is the spec? The code is not the spec. The spec is probably in your head as you're coding, but not making it explicit means it's easy to forget about it and violate it in your code.
> If one is metadata, so is the other.
Not true. Think of a SQL query vs. a COBOL program accessing ISAM data.
> And for software developers who are writing database-independent code, the
> constraints often need to be pushed to the underlying databases from some
> other repository with some other language (often proprietary to the
software
> developer). So a rules database for all constraints makes sense. Then if
a
> "service" is able to maintain the data and apply these rules, then using
the
> DBMS for storing and managing such constraints seems like unnecessary
double
> work (sorry for going off on this tangent)
I think it's a useful and related one. Yes, I agree, a "rules database" is what's needed. Why you've separated that from the DBMS I don't know... I wish I could use the relations defined in my DBMS directly in my code! Or rather, specify the constraints somewhere and have them published everywhere they're relevant. I think the problem is that languages aren't relational enough - I can imagine a lot of cloying for/while/if tests that are basically to select objects matching some criteria, and that an in-memory SELECT would accomplish it much more simply.
- erk