SCOUG-Programming Mailing List Archives
Return to [ 06 |
January |
2005 ]
<< Previous Message <<
Content Type: text/plain
Lynn H. Maxson wrote:
>Zdenek and Peter,
>
>I think we are in agreement here, if Peter actually understood
>my advocacy. In an earlier thread he posed the issue of
>natural language programming. So we seem to agree to want
>as close a match as possible between the descriptive
>language we use for the problem set and the prescriptive one
>for the solution set. At the outset that pretty much eliminates
>all programming languages except possibly APL, PL/I, and
>COBOL. You will note that these all initiated prior to 1970,
>actually 1065, some years before C and the "int"
>contamination it has inflicted on succeeding programming
>languages.
>
>Zdenek wants to say "what" he wants, leaving it up to the
>software (interpreter or compiler) to determine "how". This
>marks the distinction between fourth generation, "declarative"
>programming languages based on "logic programming" and the
>previous three generation (actual, symbolic assembly, and
>HLL), "imperative" based on "programming in logic"
>(programmer imperative).
>
>The distinction centers about the use of "assertions" in fourth
>generation and that of "assignment" in first, second, and third.
>A further distinction between the two exists. An assertion is
>either "false" or "true" and thus results in 0 ("false") or 1 or
>more "true" instances. An assignment is assumed "true" with
>a single instance result, an element or an aggregate (array or
>structure).
>
>Thus an assertion results in a "list" aggregate while an
>assignment in a "non-list" aggregate or element.
>
>In point of fact all computers use imperative instruction sets,
>accounting for why we base first, second, and third
>generation programming languages on use of the "assignment"
>statement. In each of them the logic of the "how" becomes
>the programmer's responsibility.
>
>In the shift to the assertion in fourth generation with its
>emphasis on the "what" the software has to transform this
>internally into the "how". While the application software
>programmer is now free of the "how" the tool software
>programmer is not.
>
>If "open source", however, maintains its purpose to allow any
>individual to "customize" an application, it means the
>application programmer at times becoming his own tool
>programmer. In doing so the distinction between tool and
>application disappear with the tool becoming just another
>application.
>
>This means the language must support both "assignment" and
>"assertion" statements. This means element and list and
>non-list aggregates (arrays and structures). Otherwise it
>means at least two languages. Why have two (or more)
>when one will do?
>
>Intel in its instruction reference manual for it processors
>conveniently list equivalent first, second, and third generation
>forms for all its instructions. That says that we can have a
>1:1 relatonship between "actual" and "HLL" statements. That
>means that effectively we can include "assembly" language in
>the HLL of our choice.
>
>Thus we can have a single programming language which in
>effect encompasses all four generations. As every
>programming language is a specification language that means
>we can have a specification language that encompasses all
>four generations. Moreover we can have our programming
>(specification) language, the language of our solution set,
>nearly match in its "assertions" and "assignments" the
>textbook, descriptive language of our problem set.
>
>Those "assertion" and "assignment" statements consist of
>data (elements and aggregates) and operators. If we take
>the data types and aggregates of PL/I and add to them the
>list aggregate of LISP and take the operators of APL we have
>a nearly identical match between expressions of the problem
>and solution sets.
>
>Now if we all agreed on using OpenOffice and we had access
>to a "public" APL font set, then we could demonstrate this
>match. We could also compare different syntax choices not
>only for expressions but for the other statement types. You
>could then judge for yourself the choices I made for SL/I
>(originally PL/E).
>
>The remaining grabber lies in how you specify a programming,
>i.e. specification, language. What language do you use? To
>me you use the same language. You make it capable of
>specifying itself. Thus it is capable of re-specifying itself, i.e.
>self-extensible.
>
>
>
>
I couldn't say it better!
>
>=====================================================
>
>To unsubscribe from this list, send an email message
>to "steward@scoug.com". In the body of the message,
>put the command "unsubscribe scoug-programming".
>
>For problems, contact the list owner at
>"rollin@scoug.com".
>
>=====================================================
>
>
>
>
>
=====================================================
To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-programming".
For problems, contact the list owner at
"rollin@scoug.com".
=====================================================
<< Previous Message <<
Return to [ 06 |
January |
2005 ]
The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA
Copyright 2001 the Southern California OS/2 User Group. ALL RIGHTS
RESERVED.
SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group.
OS/2, Workplace Shell, and IBM are registered trademarks of International
Business Machines Corporation.
All other trademarks remain the property of their respective owners.
|