Re: Specifying all biz rules in relational data

From: mAsterdam <mAsterdam_at_vrijdag.org>
Date: Sun, 19 Sep 2004 03:15:47 +0200
Message-ID: <414cddcb$0$43451$e4fe514c@news.xs4all.nl>

robert wrote:

> Kenneth Downs wrote:
>

>>My own experience and inclination has always propelled me towards code
>>generators and database generators, leading to my current project, which is
>>a complete application generator.

>
> well, code generators (specifically so named) began with COBOL in the
> 1970's. since expired. the 80's and 90's gave us 4-GLs. also expired.
> XML is au courant. will also probably expire. of course, VB continues
> to promise programming without coding. YMMV.

Ah! Fresh tones in this jam :-)

>>One of the philosophical cornerstones of all such projects is that the
>>application can be specified entirely in some defined format. 

>
> which ends of being a language the users (nee: coders) must learn.

Part of which may be graphical.

>>In my case the DD is itself a set of normalized 
>>(though for reasons not discussed here its persistent storage
>>is not necessarily in a DB Server product).  
>>
>>I wonder what the participants in this newsgroup feel about that
>>proposition, that being that a database application can have its entire
>>behavior defined by scalar values that can themselves be organized into
>>relational tables.

>
> was attempted about the same time codd invented the RM. it's called
> Prolog. has ended up a dead end (branch?) in the family tree of
> languages. a few fanatics like it. it is declarative. and it is a
> self modifying execution engine. neither is necessarily good. but it
> does sound like where you're headed.

I do not consider myself a fanatic (oh well, which fanatic does, so that doesn't say very much). More convincing?: Nobody ever accused me of fanaticism (yet).

I like prolog. I toyed with it in the '70s and early 80's. I wish it would me more widespread because it is really good at what it's good at: match-searching (backtracking, depth-first) complex problem-space trees.

What you can express in prolog, you can express very intuitively. Check swi-prolog (or another one) - play with it. It still carries a lot of things to learn for most.

Dead? That would be a pity with the current state of knowledge. But I'm optimistic. I dont't think it is dead. Check the usenet group.

Yes this French/Scottish idea is the champion of the declarative programming approach,
no, self modification doesn't bring the magic romantics hoped for. Neither does the approach of hand-tuplifying (databasing) code.

But I do agree whith you on the sound of the OP. That's where he is heading.

>>The practical use of the idea is simple.  Out of the DD, via the generator,
>>are the three things that must be synchronized:
>>
>>->  The docs
>>->  The app code (for me, that's pure UI, no biz rules)
>>->  The db (all tables, constraints, triggers, views, etc.)
>>
>>There are other tricks too, most notably that an upgrade is the same thing
>>as a fresh install.  The generator is actually a differences engine,
>>comparing existing DB structures to specifications, and
>>adding/changing/dropping as needed.  This means there is no separate code
>>for an upgrade versus a new install.

>
> given that no one (so far as i know), has yet been able to devise
> a universal cross language translator or even compiler (modulo C), it
> sounds like more effort than it's worth.

Here we do not agree. The project just take a little (<== yep, cynical understatement) more time than some of us thought.

A good friend of mine was heavily involved in a dream-explanation therapy expert using prolog in the early 80's. I used to challenge him to device an artificial jamming musician. He agreed with me that the AI community should be able to do that before entering the realm of dreams - but I'm digressing :-)

>>The universal objection to such systems seems to be that they are crippled
>>by whatever the author has chosen to support in the DD/generator. 
>>Underlying this objection is Godel's False Bastard Theorem of Software
>>Development: "Given any set of tools for using relational data, there
>>exists a situation that can be modeled with relational data but cannot be
>>implemented with those tools."  In the realm of data modeling, it seems
>>that we can break that assumption with brute force. 

>
> don't quite know what Godel or Bastards have to do with it, but
> raising the GL necessarily hides (aggregates in specified ways) lower

GL? Generation Language ?? General Level of abstraction ??

> level capabilities. there are known issues both with the RM and real
> world implementations: projection-join anomaly and updateable views,
> to name just two. so, the RM can't model everything, and even if it
> could, a tool which aggregates its semantics loses some part of that
> semantics.

Yep. Some of the loss will be deliberate in any such aggregating effort, though.

> in a later part of this thread is the notion that the "language of
> the month" could be swapped out (COBOL for Lisp, let's say) at the
> whim of, well, the owner of this Magic Bullet. who would know whether
> the generated system was still correct? how would anyone know, save
> by exhaustive enumeration of every path through the code? not to
> mention that the folks who have to use the Magic Bullet generated code
> become instantly redundant; replaced by experts in the "language
> of the month". i suppose that coders are as expendable as cogs in a
> machine, but the Magic Bullet Co. might find their ability to staff
> inhibited by this.

Yet, change does happen. Early COBOL by
assembly programmers who had to make the switch wasn't nice, but they learned,
eventually.

>>Then of course we have the work of Mr. Celko, that gives us a large set of
>>solutions to known problems.  The problem for those who have read the
>>literature becomes learning to recognize the problem types.

>
> you've taken a course in differential equations? there are a known
> set of solution methods (no, i don't remember them; way too many
> years ago). a solvable equation (not all expressible are solvable)
> is generally amenable to only one solution method.
>

>>Is it going too far to say that if we 
>>could learn to recognize the problem types,

>
> let's start by acting like lowly biologists: define the types.
> you need the taxonomy first.

Yes! ... a taxonomy (hierarchy) of types might just prove to restrictive, though ... but let's give it a try anyway.

>>then we could reliably model anything by either:
>>
>>-> Recognizing a simple problem as a recognized type, or
>>-> Casting an apparently "unique" problem into a form that is recognized.
>>
>>In other words, the claim is that there are no unknown problems, only
>>unrecognized forms.  If this is true, then it follows that a finite set of
>>tools in a DD/generator could generate a solution for any problem that can
>>be modeled in relational data.
>>
>>Just curious as to what people think.

Received on Sat Sep 18 2004 - 20:15:47 CDT