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

Kenneth Downs wrote:
> erk wrote:
> > "Extended" isn't data.
>
> No? My customers are not mathematicians. To us ignorant rubes it is
data
> as surely as the price and item code are data. Given a choice
between a
> "theory" that provides no guidance for real needs, and a practice
that
> does, I say the practice is the better theory.

I didn't mean to imply anyone was a rube - it's data to users, but you're a developer. I was overly curt - I referred to stored facts (assumed true but only verifiable against the domain) as "data", and "derived values" as the result of applying functions to data.

Functions have a definition. Data don't - or more to the point, values don't (e.g. while I may define an EMPLOYEE relation with various attributes, the value ("Eric", "Kaun", "apparently-pompous") has no definition - it's just a fact you're asserting by placing it in the DB).

Sorry - I didn't make any of the above clear in my earlier post.

> > It's a function, or calculation.
>
> Then the meta-data must include its definition:
>
>
http://www.secdat.com/dev/atomic.html#bdfd5c37c61ad678db5a74004d3fc58e

Agreed.

> I am unsure of what real world experience you have had but when
anybody uses
> the terms "at will" I suspect that:
> a) They have never gone out of the classroom or worked on a complex
system
> b) They have never completed a life-cycle and had to live with the
> consequences of their design trade-offs, or
> c) They have been kept insulated from the cares of downstream users,

> d) They lack a certain humility that would allow them to detect any
of the
> above three elements in their experience

Well, your suspicions are unfortunately wrong. I've been a software developer (in industry, never academia) for 15 years. For half of that time I was business analyst / project manager / trainer as well. More recently I'm primarily a designer and coder (Java/J2EE), but spend around 15% of my time interacting with internal and external users. I have apps for banks, print companies, paint companies, and aluminum manufacturers in production, some on the web and some internal.

> All I can say is try with 750+ tables, 10,000+ domains, calculated
> prorations, calculated aggregrates (including fun ones like weighted
> averages). In fact, perhaps I can put you in touch with a shop I
know,
> they'd love to find out how to produce this stuff "at will".

You misinterpret what I said. Derived values are available at will, assuming of course you have a function definition. "At will" just meant the data needn't be stored and maintained.

> To be fair, I did imply heavily that it would be stored in a column,
what I
> should have made more clear is that it should be defined as if it
were a
> column, and it should be accessible via SELECT as if it were, keeping
in
> mind that implementation is always another story.

I agree.

> >> What interested me in the OP was my own question: what theory
> >> guides the definition, generation, and protection of automoated
data?
> >
> > I think there are many. Unfortunately, the interesting ones were
> > developed and discussed decades ago, before the demand for
programming
> > drove explosions of languages, "framework", and semi-trained
> > developers.
>
> Name two. I love a good read.

While they may not appear to directly address the "automated data" question, all of these orbit the "unification" model you desire. Some old, some new:
- Dijkstra's "A Discipline of Programming" (out of print but available at reasonable prices)
- John McCarthy's Lisp writings (a unification of data and programs done long ago) - and his work on semantics and overall, the science of computation
- Date's "An Introduction to Database Systems" (overlong but a good read, and theory presented in a way that can guide practice) - Daniel Jackson's work on Alloy (http://alloy.mit.edu/beta/ for 3.0 beta, http://alloy.mit.edu/ for 2.0)
- Luca Cardelli's work on type systems and objects (http://www.luca.demon.co.uk/)
- Meijer's work on the potential language formerly known as Xen (Microsoft research, although one can already see this going horribly wrong in omitting constraints)
- Anything on ML or Haskell (I don't have a strong preference)

I think Jan and Mikito and others can suggest a slew of these. Oh, wait, here's a good reference, at least to authors if not directly to papers in your area:
http://www.lcc.uma.es/~blas/apuntes/LP/Great%20Works%20in%20Programming%20Languages.htm

• Eric