abbott@aero.ARPA (Russell J. Abbott) (10/24/88)
I'm interested in experiences with and opinions about application
generators.
I define an application generator as a computer program that has the
following properties.
1. It encapsulates the semantics of a particular application domain
or computational paradigm.
2. It provides a way for "programmers" to tailor, i.e., program,
the encapsulated knowledge for the use of "end users." In other
words it defines both "programming" and "end user" roles.
I'd like to take a broad view of application generators and include, for
example, spreadsheet systems as application generators. Spreadsheet
systems encapsulate a limited version of the computational paradigm of
constrained arrays of values. They are used to generate applications
when "a programmer" encodes, for example, an organizational structure
(i.e., a set of constraints), which is used by "an end user" who enters
specific data values. (Of course the programmer and end user may be the
same individual, but they need not be.)
I realize that such a broad view allows one to consider general purpose
programming languages as application generators as well as perhaps any
interactive system. My real interest, though, is in application
generators that provide programming leverage in powerful and interesting
ways, and it is experiences with these sorts of systems that I'm
soliciting comments about
I believe that this topic merits open discussion, so I request that
comments be posted so that others can join in the discussion.
Thanks,
-- Russ Abbott
steve@nuchat.UUCP (Steve Nuchia) (10/26/88)
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
johnson@p.cs.uiuc.edu (11/03/88)
/* Written 5:05 am Oct 22, 1988 by eliot@phoenix.Princeton.EDU in p.cs.uiuc.edu:comp.lang.misc */ In article <6154@june.cs.washington.edu> pardo@cs.washington.edu (David Keppel) writes: |jack@cs.glasgow.ac.uk (Jack Campin) writes: |]dlbaer@mozart.UUCP (Dennis L. Baer ) wrote: Stuff about SPL, which was followed by ... |]:-) You mean I can't use complex numbers to index an iteration? :-) |]:-) For shame! This language obviously still needs some work... :-) | |Oh, you think that you have problems. Gee, I can't use structures and |datatypes as array inidicies. That's a real problem for me. That's not nearly as great as my problem. I need a FOR loop that uses Japanese art-films for its indices. Maybe I should switch to SPL? /* End of text from p.cs.uiuc.edu:comp.lang.misc */ Smalltalk lets you use Japanese art-films for indices if you want (Dictionary indices, not Array indices), though you will have to define a class to represent Japanese art-films. Any kind of object can be an index of a Dictionary. Most object-oriented languages let you define iterators that you can use to iterate over collections, though Smalltalk iterators are easier to use than most. Iterators that do the same thing as a FOR loop usually do not generate indices to an array but generate the elements in the collection directly. I know that the comment about Japanese art-films was probably a joke, but I couldn't resist plugging my favorite language.
stachour@umn-cs.CS.UMN.EDU (Paul Stachour) (11/08/88)
In article <82100005@p.cs.uiuc.edu> johnson@p.cs.uiuc.edu writes: > >That's not nearly as great as my problem. I need a FOR loop that uses >Japanese art-films for its indices. Maybe I should switch to SPL? >/* End of text from p.cs.uiuc.edu:comp.lang.misc */ I've often found the need to do arbitrary indexing as well. When the type-of-item you need to use is not 'natural' to your programming language, then maybe you need to map it into something that is. May I suggest using the one of the "map" family of components for Ada that are distributed by Grady Booch (Wizard Software, 835 S. Moore St., Lakewood, Colorado 80226). And since it is in Ada, the mapping is protected (by Ada private types) against other modules messing with your mapping indicies! [I prefer to do things in a way where other people's accidental buggy code does not make mine {good or buggy} malfunction.] ...Paul -- Paul D. Stachour, Adjunct Professor, University of Minnesota USPost: 4-192 EE/CompSci Bldg, Univ of Minn, Minneapolis, Minn. 55455 Internet: stachour@umn-cs.cs.umn.edu Telephone: (612)-782-7135