Re: the relational model of data objects *and* program objects

"Kenneth Downs" <knode.wants.this_at_see.sigblock> wrote in message news:dne5j2-tic.ln1_at_pluto.downsfam.net...
> David Cressey wrote:
>
> >
> > "Kenneth Downs" <knode.wants.this_at_see.sigblock> wrote in message
> > news:60l3j2-g8s.ln1_at_pluto.downsfam.net...
> >
> >
> >> This is why the One True Data Dictionary must exist outside of all of
> > them,
> >> and be used to implement all of them. If the spec is both
> >> machine-readable and human-readable, mores the better.
> >
> > PMFJI. This may have been covered already elsewhere in the discussion.
> > If so, my apologies.
> >
> >
> > I'm playing around with the idea of a programming language that combines
> > the functionality of traditional programming,
> > library function invocation, and data exchange with database servers
> > and/or
> > user interface servers. In this concept,
> > SQL becomes the OUTPUT of a compiler, instead of the input to a
compiler.
> >
> > That is, you have a language in which code "makes sense", and is
> > unified.
> > The compiler figures out which things should be coded to run on, say, a
> > Java Virtual Machine, which things should be resolved by library
function
> > calls, and which things should be recoded as SQL style exchanges with
> > external servers.
> >
> > I know this isn't exactly the direction you are going in. But maybe
> > there's a useful synthesis.
>
> This is not the implementation direction I've gone in, but it is very
close
> to the original intent, something that knows where to put things based on
a
> holistic specification.
>
> I would have to ask what you mean by "language". Ours is purely
> declarative, meaning it is actually data dressed up for readability. It
is
> a "language" only if CSS is a language.

This question goes deeper than I'm prepared to answer, as of yet. But let me comment on it, even if I don't answer it.

The question of whether code "describes an intended result" or "prescribes a method that yields an intended result" has actually been around a long time. Fifty years ago, FORTRAN assignment statements were thought of as being "declarations of arithmetic formulas" rather than "programming instructions about what to do." So people who prescribed actions in terms of machine instructions (numeric or symbolic) were thought of as "programming", and people who wrote FORTRAN were thought of as "doing something other than programming."

Time went by, and FORTRAN programming became accepted as such. Same for lots of other languages. The language you describe seems sort of "goal oriented" if I read you right. That's probably a good thing, but by no means simple.

On another subject, it's no accident that you've pinned the data dictionary as the root of all description. I remember that twenty years ago, the "VAX Information Architecture" placed the "Common Data Dictionary" at the center of all things, and NOT the database metadata. I didn't grok that at the time, but now it makes sense. (Too bad the CDD was so slow!) Received on Fri Apr 15 2005 - 23:27:02 CEST