🚀 go-pugleaf

From article <39964@aero.ARPA>, by abbott@aero.ARPA (Russell J. Abbott):
>   I'm interested in experiences with and opinions about application
>   generators.

>   ... following properties.

>      1. It encapsulates the semantics of a particular application domain  
>         or computational paradigm.

I wrote a large fraction of a commercial "Applications Generator" which
is mercifully becoming more rare now that the company has finaly finished
dying.  "Application Generator" is, first and last, a marketing word.  As
such it means precicely what the user (of the phrase) want it to mean,
nothing more and nothing less.

The distinguishing characteristic, as I see it, is that an AG attempts
to provide a framework in which only the "interesting" aspects of the
application are programmable and everything else is provided by the
system.  The marketeers will tell you that you don't have to do any
programming at all, you just fill in some screens or whatever and "poof!"
you've got an application.  In fact it is a language, often with bizarre
concrete syntax, with a limited domain of discourse.

It is the choice of programmable versus built-in features that distinguish
one AG from another.  If you've never used one, let me tell you that
if you pick the wrong one for the task at hand you will be one miserable
camper.  "Wrong" means that it fails to match your requirements in an
area that is not programmable.

This difficulty is inevitable in a AG as I've defined the term, since
if everything is programmable it is not an AG but some other kind of
animal, perhaps a library, a development environment, or a program
template.

I believe that there is a non-null class of problems for which AG/4GL
is the solution of choice, but I think that the methodolgy with which
they are employed is flawed.  Since a 4GL is inherently application
domain specific what is needed is a way to use many of them in one
project.  The practitioners and vendors today tend to be very partisan
when cooperation and interoperability would seem to be a more productive
course.

Utopian example:  say we have a 4GL that is really great at describing
database consistency constraints and update policies.  Say somebody
else has one that is unbeatable at user interaction dialogues, a third
vendor one that does reports and "posting"...  Using modern implementation
techniques, particularly server/client protocol (ala X), these could
easily be made to work together.

The situation we have now is that every vendor is selling a single
verticaly integrated (includes all layers) package instead of a
component.  This would be OK if they designed it as a family of
languages for different purposes but each vendor has his own concept
of what the One True Way to think about application design is, and
his language supports only that one way.  My latest example is with
an SQL based AG - everything is a query to them.  Well, not everything
in my application is a query, but to make it fit their model I have
to turn it into one.  Sigh.

That's my two cents worth.  This is a topic that I have devoted a great
deal of time to, though little in the last year or two.  I'd be happy to
discuss it further here.
-- 
Steve Nuchia	    | [...] but the machine would probably be allowed no mercy.
uunet!nuchat!steve  | In other words then, if a machine is expected to be
(713) 334 6720	    | infallible, it cannot be intelligent.  - Alan Turing, 1947