SCOUG-Programming Mailing List Archives

<< Previous Message <<

Date:	Wed, 21 Jan 2004 16:40:01 PST8
From:	"Lynn H. Maxson" <lmaxson@pacbell.net >
Reply-To:	scoug-programming@scoug.com
To:	"SCOUG Programming SIG" <scoug-programming@scoug.com >
Subject:	SCOUG-Programming: The declarative imperative

Content Type: text/plain

Peter accused me of pursuing a quest. I denied it. At least I
denied the specific one he had in mind. I always have a quest
for clear communications. Not infrequently it falters or fails.

As I sat listening to Bob Blair's presentation on parsing in
REXX, it came to me that here lay the proof of my pudding
while I puddled elsewhere. it caused me to ponder the great
documentation monstrosity that IBM masochistically imposed
upon itself and unfortunately many customers imitated.

I refer, of course, to HIPO (Hierarchical Input Plus Output), a
combination of graphical and imbedded text forms. It actually
had four different forms. The admonition of its authors and
repeated in the red manuals IBM published lay in emphasizing
the "what" over the "how" without ever offering the
operational means of making the distinction. In theory and in
practice you find many instances where they are
indistinguishable.

The major problem of HIPO, aside that it jacked up the cost of
documentation exponentially, was that its authors lacked a
fundamental understanding of their own product. That lack
they passed on to their users or to us poor IBM folk who tried
to communicate it to them.

Now you have only three forms of analysis: classification,
structure, and operation. Each of the four HIPO forms fit
exactly one of these. To save you some arithmetic that
means that two of the HIPO forms engaged in the same type
of analysis.

Each form of analysis answers two complementary questions.
For classification it's "what is this a kind of?" and "what are
the kinds of this?". For structure it's "what is this a part of?"
and "what are the parts of this?". For operation it's "what is
this a stage of?" and "what are the stages of this?".

All this basically comes from two works, "Creative Analysis"
by Sampson and "Design for Thinking" by Upton. You will
notice that the HIPO authors at least got the "what" part
correct, but didn't or couldn't clearly communicate the rest.

While listening to Bob's presentation it came to me that I had
failed similarly myself. I have frequently claimed that the
difference between imperative and declarative languages lay
in the imperative focusing on the "how" and the declarative
on the "what". It came to me that in many instances they
were indistinguishable.

I had neglected to note the evolution of imperative
programming languages correctly, i.e. the generational
differences. All machine instructions reflect pure imperatives.
Load register. Add immediate. Pull. Push. Pop. Branch on
equal.

Thus first generation machine languages reflected the same
pure imperative form. Second generation symbolic assembly
languages even with their introduction of macros retained a
one-to-one instructional relationship with the machine
instruction set. Thus second generation reflected a pure
imperative form.

This changed with the introduction of third generation
imperative languages. Here we divorced the HLL (High Level
Language) imperative statements from their LLL (Low Level
Language) dependencies in order to achieve "machine
independence".

In a third generation HLL like PL/I, C, Pascal, Forth, etc. we
use an imperative form, e.g. "read file(filename)
into(record_area);", saying "what" we want done. This
leaves it up to the processing software to determine "how" to
do this.

We retain this same imperative form even in fourth generation
declarative languages. If we put the statements side-by-side,
in many instances no differences exist. We write them the
same. They look the same. They are the same. It looks like
a duck, walks like a duck, and talks like a duck. Chances are
it's a duck.

Technically even in first generation machine language an
instruction says "what" we want to do, leaving it up to the
machine logic (or microprogramming software) to determine
"how" to do it. This means that every imperative statement
from first generation onward has a declarative form. Little
wonder then that the statements themselves don't support
the distinction...or that we confuse people who cannot see the
difference because frankly none exists.

That suggests that we are looking for the difference in the
wrong place. It's not in the statements, but in their
assemblies. In fact in the overall ordering of those assemblies.
And in the automatic reuse of those assemblies or code
segments.

As I watched Bob step through the enumeration of the
different options of the REXX parse verb it occurred to me
that it made the points more precisely and understandingly in
REXX than I had in SQL. The popularity of both in the parse
statement of REXX and the SELECT statement of SQL lies in
their declarative form: they say "what" they want without
dictating "how" it is done. A fact common to both third and
fourth generation HLLs.

Maybe then if we centered our discussion on REXX and not
SL/I, we might more easily make the transition to logic
programming. Along the way maybe we can increase other
areas of enlightenment in REXX as Bob did with the parse
verb.

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

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

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

Return to [ 21 | January | 2004 ]

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.