SCOUG Logo


Next Meeting: Sat, TBD
Meeting Directions


Be a Member
Join SCOUG

Navigation:


Help with Searching

20 Most Recent Documents
Search Archives
Index by date, title, author, category.


Features:

Mr. Know-It-All
Ink
Download!










SCOUG:

Home

Email Lists

SIGs (Internet, General Interest, Programming, Network, more..)

Online Chats

Business

Past Presentations

Credits

Submissions

Contact SCOUG

Copyright SCOUG



warp expowest
Pictures from Sept. 1999

The views expressed in articles on this site are those of their authors.

warptech
SCOUG was there!


Copyright 1998-2024, 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.

The Southern California OS/2 User Group
USA

SCOUG-Programming Mailing List Archives

Return to [ 06 | January | 2005 ]

<< Previous Message <<


Date: Thu, 6 Jan 2005 08:33:47 PST8
From: Zdenek Jizba <jizba@verizon.net >
Reply-To: scoug-programming@scoug.com
To: scoug-programming@scoug.com
Subject: SCOUG-Programming: A bit too much to byte

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.