Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!dev!dgis!jkrueger From: jkrueger@dgis.dtic.dla.mil (Jon) Newsgroups: comp.databases Subject: Re: 5GLs, as defined in Jessica Keyes' article Message-ID: <903@dgis.dtic.dla.mil> Date: 28 Jun 90 22:22:00 GMT References: <1192@abcom.ATT.COM> <37595@sequent.UUCP> Organization: Defense Technical Information Center (DTIC), Alexandria VA Lines: 90 cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: >And in answer to that, take this (naturally, there is some overlap in these, >but, then again, nothings perfect :-)-: The only validity to such terms is what major shifts we can agree on concerning the history so far. Thus >1GL - communication with machine in its terms (aka. machine language) is accurate; debatable whether tools to edit programs are allowed; clearly tools to generate programs are not. >2GL - machine communications in a more understandable manner - mnemonics > (aka. assembler) omits the innovation of symbolic locations and function entry names, on which function libraries were built, the first re-useable code. >3GL - description of a solution to a problem through the procedural methods > of achieving a solution in a manner a human would understand (human > describes inputs, procedures, and outputs). This was happening already with 2GLs. The 3GL innovation is data types, control structures, portable programs, portable function libraries. 3GL's made possible greater abstraction of inputs, outputs, procedures, but only to extent that ADTs are developed and used. Sadly, most 3GLs and their programmers took little care to do this; their 3GL code isn't much more abstract than its equivalent in assembler. >4GL - description of a solution to a problem by the characteristics of what > the proper output would look like and not through the procedure for > finding the information for the output (human defines inputs and > outputs with what is desired, but machine determines procedure). The trouble is that the GL's are terms assigned after the fact; 20/20 hindsight allows perspective not available when predicting the future. Thus we can get good consensus on 1GL, 2GL, 3GL, because we can look back and characterize what has already happened. We haven't got that kind of access to the future. What would Turing have predicted in the way of "third generation languages"? Would he have said that "fourth generation languages" would be user interface managers for database access? "4GL" and beyond are describing developments that haven't yet occurred, so their meaning isn't tied down yet. >5GL - description of a solution to a problem by the characteristics of what > makes up a good solution to the problem (human describes inputs and > what is desired, but machine determines procedure and best method > of output). >6GL - description of a problem that leads machine to conclude what is > required to be done, how to achieve it, and what is needed to > achieve it. These don't sound greatly different from your definition of 4GL. >7GL - at this stage, the machine begins reasoning for itself and making > conclusions based on early problems about what future problems will > need to be solved. I always figured that at some stage the machine would say "I'm sorry David, but I can't do that" :-) or at any rate would make caustic comments on the improper use of its resources. One of science fiction's many self-aware computers is named Mike (from "The Moon is a Harsh Mistress", Robert A. Heinlein). One day Mike notices that users are writing programs to figure odds on horse races. Mike compares the race results and discovers that they aren't winning much. He examines the betting "systems" they're using and concludes that none of them will show a consistent return, they're based too much on superstition and too little on analysis of results. He goes on to devise and test his own systems. It's a fun story and has some real lessons for technology forecasters. Computers already assist in detecting flaws of implementation. Perhaps the next step is ferreting out fundamental design flaws. Doug Lenat at MCC is trying to develop a common sense knowledge base. Someday the computer might consult this to help you avoid writing the archetypical expert system that determines which of the 4 types of spinal meningitis your '67 Chevy has (one of Doug's examples). Right now there ain't a CASE system alive that will try to stop you from doing this. The ability to analyze the real world before writing the program is still confined to humans (as of this writing -- check date on header :-)) -- Jon -- Jonathan Krueger jkrueger@dtic.dla.mil uunet!dgis!jkrueger Drop in next time you're in the tri-planet area!