SCOUG-Programming Mailing List Archives

Date:	Sat, 15 Jul 2006 19:32:28 -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: Project status

Content Type: text/plain

I think we agree that Bob has carried us far enough in his
introduction to PM programming that we should undertake a
direct try at our project of incrementally "smarting" an editor,
resulting in an improved and definitely industry unique
interpreter/compiler.

In truth Bob has not carried you far enough, if you have not
attended his presentations. He and I will have to work out a
means of combining his visuals with their step by step process
of window development with a narrative to provide it as a
tutorial from our website. Steven has suggested that we also
review similar existing work which exists from several
sources. He doesn't quite understand that "several", which is
so acceptable to him, might in itself be part of the problem for
which we hope to offer a solution. Nevertheless it does
represent another source upon which we may draw.

I'm all the time having to address questions about SL/I as if I
viewed the situation as one solvable by a language...alone. In
truth it is a language problem. More to the point it is a
multiple language problem. Even more to the point it comes
down to a "manual" writing problem in multiple languages
requiring the maintenance of multiple sources which rely on
"manual" means to remain in sync.

You have the crux of the matter before you, the reliance on
manual means. Now we must write, write initially or rewrite,
something. Our guide lies in writing only what is necessary
and not writing that which is not, leaving it up to some
non-manual agent, in this instance software, to do. Thus
people should write what software cannot and software what
people need not.

Software arises from "user" needs which get expressed as
"requirements(R)", go through a development/maintenance
process, and come out with a version of a product(P). Then
"new" or "changing" requirements initiate a new cycle of the
process, resulting in a new version of the product.

That development/maintenance process we call the Software
Development Process or SDP. It consists of five distinct, but
hopefully seamlessly connected stages: specification(S),
analysis (A), design (D), construction (C), and testing (T)

Thus the cycle goes as follows:
R(1) -> S -> A -> D -> C-> T -> P(1) -> R(2) -> ...
over the "lifecycle" of the product. The historical difficulty of
the software profession lies in the fact that the interval
between R(x) and P(x) frequently overlaps the occurrence of
R(x+1), which may include one or more R's. In short we can't
get to P(2) without interrupting the the SDP for P(1), thus
halting it to restart the process with a larger set of Rs, or
holding the new Rs up until P(1) is done. These "held up" Rs
constitute a "backlog", which basically has plagued the
software profession since its beginning.

What's more unfortunate is the belief that an improved
programming language, a really improved programming
language, a really improved programming methodology, will
solve the problem of an enterprise whose IT support
demonstrably cannot implement changes, i.e. Rs, as fast as
they occur...creating the backlog.

At the same time no one hears any complaint about the
backlog associated with an SQL query...because there isn't
any. You don't have to be a programming professional to
create queries at a rate consistent with your needs. The
difference is not due to a lack of programming features and
functions in SQL, i.e. a reduction in scope of effort, but to
something else entirely: SQL requires only the writing of the
query, a specification only. The software accepts the
specification source and automatically does the analysis,
design, construction, and testing.

Thus the language itself does not affect the SDP as does its
"type" or "class". We have two types of programming
languages, "imperative" and "declarative", Imperative
languages include the first three generations of "actual",
"symbolic assembly", and "HLLs". Declarative languages
represent the fourth generation of HLLs, of which SQL is one.

Declarative languages are based on logic programming. Logic
programming requires the use of a two-stage proof engine, a
completeness proof (A, D, and C) and an exhaustive true/false
proof (T). Logic programming offers two complementary
logical forms, clausal and predicate. Clausal requires the user
supply the test data for the proof. Predicate requires the
user supply only the range of values each variable may
assume during the proof process. It accepts the responsibility
for generating the test data: all the enumerated sets of all
variable values.

Now what does this mean? Consider the following:

R -> S -> A -> D -> C -> T -> P
M M M M M M ------Imperative language
M M S S S M/S ----declarative clausal
M M S S S S ------declarative predicate

Now if you consider that R, S, A, D, C, and T each have a
separate M source, M write, M rewrite, it should be obvious
that the choice which has the least in terms of manual (M)
input is the declarative predicate. A backlog can only occur if
it takes longer to manually write a specification than on
average writing a requirement. Thus we can expect with a
declarative predicate programming language that a backlog
will occur only as a transient condition.

Thus we have solved what the current OO proposed would do,
but obviously didn't.

What you should take from this is not to continue the
argument of which language is better than another, but which
type of language, imperative or declarative, offers us a way
out of the backlog problem: where we can institute changes
globally as fast as they occur.

Moreover we have only two M processes to keep in sync on
input, R and S. On output we have another M, which we do
not show. Associated with any P product is a set of user
documentation, manually written. So effectively we have 3
Ms to keep in sync.

We will save how we use the software to assist in that as
well for a future discussion of the data repository/directory.

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

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 [ 15 | July | 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.