Path: utzoo!utgpu!water!watmath!clyde!bellcore!rutgers!cmcl2!nrl-cmf!ames!amdahl!rtech!billc@rtech.UUCP
From: billc@rtech.UUCP (Bill Coffin)
Newsgroups: comp.databases
Subject: Re: SQL = 4GL ???
Message-ID: <2397@rtech.rtech.com>
Date: 23 Aug 88 22:44:07 GMT
Sender: news@rtech.rtech.com
Lines: 34

A lot of people have talked about what a 4GL should look like.  This is
valuable but omits some philosophical underpinnings.  Here is a
taxonomy that was suggested to me by a friend:

1GL -- hardware level.  patchcords, etc.

2GL -- symbolic.  Hides (abstracts) a lot of hardware dependencies.
	2GLs separate the hardware implementation from the architecture.

3GL -- algorithmic.  Differs from 2GL in that it allows programmers to
	write at the algorithmic level.  3GLs hide the architecure.
	However, 3GLs are still procedural -- the programmer tells the 
	computer HOW to do stuff.

4GL -- specification.  Differs (ideally) from a 3GL in that programmers
	specify what they want done, not how to do it.  That is, a
	true 4GL would be entirely non-procedural and non-algorithmic, 
	accepting high-level goal-oriented specifications as input and 
	producing complete applications as output.

However, I have never seen a "4GL" that didn't have some 3GL glue
to hold the 4GL parts together.  That is, the above definition is an
ideal, and it's hard to imagine how it could be fully implemented.
Most 4GLs I've seen are forms systems and forms editors with lots
of clever defaults and menu-driven configuration, but with procedural stuff
available for when the defaults don't make it.
So in this taxonomy, all current so-called 4GLs are really 3.5GLs.
(By the same argument, since C does a poor job of hiding architecture, 
C could really be called a 2.6GL.)

Surprisingly, QUEL is a 4GL in this taxonomy, since it is non-procedural.
So I guess this taxonomy lacks completeness criteria.

{sun,pyramid,mtxinu,amdahl}!rtech!billc, billc@rtech.uucp