Forgot your password?
Cyhist Apr 22 1997 A
Document Actions
Date: Tue, 22 Apr 1997 23:41:18 +0100
Reply-To: "CYHIST Community Memory: Discussion list on the History of
Cyberspace" <CYHIST@MAELSTROM.STJOHNS.EDU> Sender: "CYHIST Community Memory: Discussion list on the History of
Cyberspace" <CYHIST@MAELSTROM.STJOHNS.EDU> From: Rainer Fischbach <rf@SCHWABEN.DE>
Subject: 4th generation languages
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
______________________________________________________________________
Community Memory: Discussion List on the History of Cyberspace ______________________________________________________________________
There is no uniform set of criteria that differentiates generations of programming languages. The succeeding generations reflect an evolution of criteria no less than one of languages:
The difference between machine code and assembler -- as well a any other kind of programming language -- is primarily one of the involved alphabets (comprising letters, digits and special characters vs. only 0s and 1s). Machine code too is symbolic -- a nonsymbolic language is a contradictio in adjecto. A language in the formal meaning is any set of strings over some alphabet -- whatever the alphabet is.
Perception of tresholds varies with time: When Fortran and Algol were introduced, the facility valued most by their users was algebraic expressions -- a rather declarative feature, that made work easier a lot compared to assembler programming. Today, we usually overlook this critical difference when realizing the specifics of 3rd generation languages in the ability to group statements and data into procedures and records, arrays, etc. or according to predefined patterns like in >structered statements<, although that happened -- at least to a weaker degree -- already with macro assemblers. OOP clearly is in the 3rd generation basket, as it only brings in a new pattern of grouping data and statements. Forth too makes no difference.
The process was clearly driven by language design. Computer architecture followed rather hesitatingly. E. g. the way base and index address registers worked in CDCs 6000 and Cyber CPU architecture and instruction set -- which btw was rather RISC-like -- was tuned to rapid iteration through arrays by Fortran do-loops. Seymour Crays later architectures just extended on that theme. In the 60s and 70s only view computer manufacturers offered hardware support for the so-called high level (= 3rd generation) language facilities like nested blocks and procedure calls (considered this way, Fortran was not really 3rd generation). Burroughs did it, but didn't make it. Motorolas 68K architecture was the first of my remembrance -- is there someone who knows better? -- to do it on a microprocessor.
Language oriented CPU architecture doesn't seem to have won these days. E. g. the RISC chips have outperformed 68K chips and Lisp machines. Will Java chips make it? At least like the X86 did: not by performing but by selling? Is there someone who remembers Western Digitals p-machine? Was awful fast those days, besides facilitating a saner software architecture, but didn't win either.
Due to the lack of a fixed, stable set of criteria, there will always be argument about what should be considered next generation -- and, of course the marketiers will be around and take part in it. As far as I remember 4th generation languages were to be declarative rather than imperative -- programming should mean to specify _what_ the result should look like, not to prescribe _how_ it is to be computed. At least this was the interpretation of the term on which the debate settled in the mid-80s, which does not exclude someone else having tried to give it a different meaning, e. g. the Forth guys. We already have some kind of declarativeness in most higher programming languages (besides e. g. Forth) since algebraic expressions came in with Fortran and Algol, although not dominating the structure of the languages on the global level.
In my memory, it was the RDBMS and SQL industry which during the early 80s brought up the idea that declarative vs. imperative should be the criterium of the 4th generation (probably, someone else used the term before). Along with it they tried to push once again the idea of MIS (= management information systems). 4th generation languages should empower executives to do data processing on their own, by fomulating declarative queries ... sounds ridiculous today.
Albeit it serves the marketing goals of an industry, declarative vs. imperative is no unreasonable proposition. Of course there are more 4th generation languages: Prolog, Goedel, SML, Miranda, etc., and with more right because these are Turing complete whereas SQL is not. From a software engineering view, declarative programming has strong virtues: no side effects, more concise and human understandable code, more amenable to parallel execution...
Application specific or problem oriented vs. general is not a reasonable contribution to the present argument, neither is interpreted vs. compiled. All languages can be compiled _and_ interpreted. There are procedural application specific languages and declarative ones: Postscript is clearly imperative, Metafont has some interesting declarative features, but nonetheless remains mainly imperative. Declarative languages are hidden at the bottom of many modern CAD tools, though the user is not aware of dynamically declaring and solving constraints while arranging and manipulating model elements.
Strictly speaking, problem orientation is not a feature of languages. Problem orientation is a matter of intent. But one can use a problem oriented language to solve a problem that lends itself to the same kind of model on which the language was build. Remember some guys who used Metafont to solve equations. Probably one could use a graphics language for matrix calculations etc.
Regards
Rainer
------------------------------------------------------------------------
Rainer Fischbach \\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_ Fon +49 7478 91133 Consulting \\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_ Fax +49 7478 91134
Wachendorf \\_\\_\\_\\_\\_\\_\\_ Mobil +49 171 4141570
Hirtenbruennle 25 \\_\\_\\_\\_ Email Rainer.Fischbach@schwaben.de D-72181 Starzach \\_\\_\\_\\_ http://www.schwaben.de/home/fischbach F. R. Germany \\_\\_\\_\\_\\_\\_ http://www.ba-stuttgart.de/~rf
------------------------------------------------------------------------
______________________________________________________________________
Reply-To: "CYHIST Community Memory: Discussion list on the History of
Cyberspace" <CYHIST@MAELSTROM.STJOHNS.EDU> Sender: "CYHIST Community Memory: Discussion list on the History of
Cyberspace" <CYHIST@MAELSTROM.STJOHNS.EDU> From: Rainer Fischbach <rf@SCHWABEN.DE>
Subject: 4th generation languages
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
______________________________________________________________________
Community Memory: Discussion List on the History of Cyberspace ______________________________________________________________________
There is no uniform set of criteria that differentiates generations of programming languages. The succeeding generations reflect an evolution of criteria no less than one of languages:
The difference between machine code and assembler -- as well a any other kind of programming language -- is primarily one of the involved alphabets (comprising letters, digits and special characters vs. only 0s and 1s). Machine code too is symbolic -- a nonsymbolic language is a contradictio in adjecto. A language in the formal meaning is any set of strings over some alphabet -- whatever the alphabet is.
Perception of tresholds varies with time: When Fortran and Algol were introduced, the facility valued most by their users was algebraic expressions -- a rather declarative feature, that made work easier a lot compared to assembler programming. Today, we usually overlook this critical difference when realizing the specifics of 3rd generation languages in the ability to group statements and data into procedures and records, arrays, etc. or according to predefined patterns like in >structered statements<, although that happened -- at least to a weaker degree -- already with macro assemblers. OOP clearly is in the 3rd generation basket, as it only brings in a new pattern of grouping data and statements. Forth too makes no difference.
The process was clearly driven by language design. Computer architecture followed rather hesitatingly. E. g. the way base and index address registers worked in CDCs 6000 and Cyber CPU architecture and instruction set -- which btw was rather RISC-like -- was tuned to rapid iteration through arrays by Fortran do-loops. Seymour Crays later architectures just extended on that theme. In the 60s and 70s only view computer manufacturers offered hardware support for the so-called high level (= 3rd generation) language facilities like nested blocks and procedure calls (considered this way, Fortran was not really 3rd generation). Burroughs did it, but didn't make it. Motorolas 68K architecture was the first of my remembrance -- is there someone who knows better? -- to do it on a microprocessor.
Language oriented CPU architecture doesn't seem to have won these days. E. g. the RISC chips have outperformed 68K chips and Lisp machines. Will Java chips make it? At least like the X86 did: not by performing but by selling? Is there someone who remembers Western Digitals p-machine? Was awful fast those days, besides facilitating a saner software architecture, but didn't win either.
Due to the lack of a fixed, stable set of criteria, there will always be argument about what should be considered next generation -- and, of course the marketiers will be around and take part in it. As far as I remember 4th generation languages were to be declarative rather than imperative -- programming should mean to specify _what_ the result should look like, not to prescribe _how_ it is to be computed. At least this was the interpretation of the term on which the debate settled in the mid-80s, which does not exclude someone else having tried to give it a different meaning, e. g. the Forth guys. We already have some kind of declarativeness in most higher programming languages (besides e. g. Forth) since algebraic expressions came in with Fortran and Algol, although not dominating the structure of the languages on the global level.
In my memory, it was the RDBMS and SQL industry which during the early 80s brought up the idea that declarative vs. imperative should be the criterium of the 4th generation (probably, someone else used the term before). Along with it they tried to push once again the idea of MIS (= management information systems). 4th generation languages should empower executives to do data processing on their own, by fomulating declarative queries ... sounds ridiculous today.
Albeit it serves the marketing goals of an industry, declarative vs. imperative is no unreasonable proposition. Of course there are more 4th generation languages: Prolog, Goedel, SML, Miranda, etc., and with more right because these are Turing complete whereas SQL is not. From a software engineering view, declarative programming has strong virtues: no side effects, more concise and human understandable code, more amenable to parallel execution...
Application specific or problem oriented vs. general is not a reasonable contribution to the present argument, neither is interpreted vs. compiled. All languages can be compiled _and_ interpreted. There are procedural application specific languages and declarative ones: Postscript is clearly imperative, Metafont has some interesting declarative features, but nonetheless remains mainly imperative. Declarative languages are hidden at the bottom of many modern CAD tools, though the user is not aware of dynamically declaring and solving constraints while arranging and manipulating model elements.
Strictly speaking, problem orientation is not a feature of languages. Problem orientation is a matter of intent. But one can use a problem oriented language to solve a problem that lends itself to the same kind of model on which the language was build. Remember some guys who used Metafont to solve equations. Probably one could use a graphics language for matrix calculations etc.
Regards
Rainer
------------------------------------------------------------------------
Rainer Fischbach \\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_ Fon +49 7478 91133 Consulting \\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_ Fax +49 7478 91134
Wachendorf \\_\\_\\_\\_\\_\\_\\_ Mobil +49 171 4141570
Hirtenbruennle 25 \\_\\_\\_\\_ Email Rainer.Fischbach@schwaben.de D-72181 Starzach \\_\\_\\_\\_ http://www.schwaben.de/home/fischbach F. R. Germany \\_\\_\\_\\_\\_\\_ http://www.ba-stuttgart.de/~rf
------------------------------------------------------------------------
______________________________________________________________________
