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 ]

>> Next Message >>


Date: Thu, 6 Jan 2005 07:32:35 PST8
From: "Lynn H. Maxson" <lmaxson@pacbell.net >
Reply-To: scoug-programming@scoug.com
To: < "scoug-programming@scoug.com" > scoug-programming@scoug.com >
Subject: SCOUG-Programming: A bit too much to byte

Content Type: text/plain

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.

=====================================================

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".

=====================================================


>> Next 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.