SCOUG-Programming Mailing List Archives

<< Previous Message << >> Next Message >>

Date:	Mon, 22 May 2006 13:11:49 -0700
From:	"Lynn H. Maxson" <lmaxson@pacbell.net >
Reply-To:	scoug-programming@scoug.com
To:	"SCOUG Programming SIG" <scoug-programming@scoug.com >
Subject:	SCOUG-Programming: Moving right along

Content Type: text/plain

Currently VOICE members are voting on a proposal to
purchase the rights to the OS/2 version of PMMail. It seems
likely based on other informal inquiries that it will pass. If so,
then some of us will join the software development team to
correct errors and provide enhancements. That presents a
challenge similar to the one currently underway in the SCOUG
Programming SIG, that of collaboration, communication, and
decision making, including setting priorities.

We've had the second installment of Bob Blair's "Introduction
to PM Programming" which you know from recent responses
on this list has progressed into font rendering. The challenge
here lies in how best to package all this good stuff on the
website such that we have the possibility of a skills transfer
from our experts to the rest of us. Again collaboration,
communication, and decision-making.

I did a google check on POSSI, the Phoenix OS/2 group. I see
nothing there past 2004 from my somewhat slight perusing. I
guess SCOUG dresses in somewhat more durable cloth. At any
rate we remain blessed with a variety of talents and talented
people.

As we move forward then let's make sure that we do it
together. If not, then make it possible to catch up. That says
we need to insure that the feedback system with your input
works.

******************

We have evolved through four generations of programming
language, the first three of which (actual, symbolic assembly,
and HLL) we label as "imperative", where you tell it where,
when, and how you want it done, and the fourth "declarative"
where you simply assert the possibility of doing it or not as
the case may be.

Somehow my fourth generation often appears as the fifth
elsewhere. I have no idea how I lost a generation. Must have
come from a senior moment. I would appreciate someone to
help me fill in the gap.

Meanwhile I will take the fifth on the fourth to see what we
can backfill at least to the third, if not the first and second.
At the same time let's understand a principal difference
between imperative and declarative languages prior to,
during, and after code generation.

Imperative languages insist that the author(s) present
complete logically organized source code on input;declarative,
only the possibility of logically organizing the source code.
That implies logical organization within the software. In
declarative languages this responsibility lies within the
"completeness" proof. On completion, it tells you what it
could complete and where it could not why it could not. In
either instance it provides full "backtracking", both how and
why it arrived at its logical organization.

It cannot logically organize unordered source without some
assistance. Imperative languages can "logically" organize
source at the procedure or call level through the use of
procedure names, of one procedure invoking another, possibly
itself (recursion).

For a declarative language to do so at some lower level either
a statement or a control structure (sequence, decision, or
iteration) these must have names used in "higher" level
invocations. Declarative languages create these name
hierarchies of invoker to invoked for lower level code
segments as well as procedures.

Now note that at least in one imperative language, COBOL,
where code segments exist as "named" paragraphs and get
invoked within "PERFORM" statements embedded within other
paragraphs, that this occurs below the procedure level. The
PERFORMs can occur either "inline", generating a instance
(copy) for each invocation or "out of line" as a sub-routine.

However, in COBOL the "main" paragraph must precede all
others and for readability or documentation purposes normally
enterprises set standards for the naming and ordering of
paragraphs. That marks a difference between imperative and
declarative, as the declarative can through an examination of
the invoking paragraphs determine the hierarchy regardless of
input order.

Note, however, that within a paragraph the author determines
the logical organization of the source. This remains true of
source code segments in declarative languages. As humans
we are less prone to "logical" error in the "small", code
segments, than we are in the "large". Certainly where we
make an error in the "small", which is easy enough to correct
but has ramifications in the "large", it's nice to know that the
software will do the necessary rewrite of the logical
organization for you.

Thus we have something to gain in using an imperative
language with a declarative proof engine, something hinted at
in COBOL, but not completely realized.

So we have a means of automating writing, the ease and
order in which we generate "named" code segments, as well
as their "rewriting" which can consume even larger time with
imperative languages. We can adapt logical organization of
the whole more quickly to changes in this manner than
currently in imperative languages.

Thus when we have a "complete" logical organization the
code generation for both imperative and declarative is the
same. Thus declarative languages offer assistance through
software automation in logically organizing source code not
currently or as completely offered in imperative languages.

So we have looked at the differences with respect to the
division of labor of logical organization of source between
ourselves and the software in imperative and declarative
languages. We have seen that no difference exists during
code generation. That leaves us then with only what
differences exist after code generation.

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

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
"postmaster@scoug.com".

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

Return to [ 22 | May | 2006 ]

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.