SCOUG-Programming Mailing List Archives

>> Next Message >>

Date:	Wed, 22 Feb 2006 12:50:20 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: Trip preparation

Content Type: text/plain

We have a road map, giving us a set of stops along the way.
For reasons almost of necessity our first stop, building a GUI
with OS/2 Presentation Manager, will prove our most difficult
and thus most challenging. We have an excellent guide in Bob
Blair. You can look forward to including it as part of your
comfort zone. We will take the time necessary for that to
occur. Its mastery will make the remaining stops essentially
routine. That should lead to a successful journey.

While we devote some moments to mastering Presentation
Manager and constructing our GUI editor, the first step toward
our final interpreter/compiler/documenter tool, we will do
some prep work for the remaining stopovers.

I also may have caught you offguard by appending
"documenter" to our tool. Remember we have a goal to
increase programmer productivity. While we have challenges
in improving his think time, we will focus on improving his
writing time. We will do it in two ways, reduce the total
written amount, what he has to write, and reduce the
different languages he has to use. We actually seek to
reduce the source language to one and from it to have the
software generate most of the documentation now done
manually.

We know it works for flowcharting, given the number of
products offered to produce flowcharts from source code. If a
correlation exists between source code and some document,
whatever source code we can deduce from the document we
can use to produce the document.

The advantage of this lies in having only one set of source
code to maintain with any changes reflected throughout all
documentation by software. Thus documentation such as
flowcharts, dataflows, structure charts, and UML will occur in
real time as the software reflects changes in the source code.

The smallest programmable unit of software is the statement.
We perform syntax checking at the statement level. This
does not mean we have to wait until we have entered a
complete statement before we do syntax checking. We can
do it in real time, but only at a statement level.

I have made the assertion that three, third generation,
"legacy" languages--APL, LISP, and PL/I--include everything
and more found in all the others. The truth or falsity of that
assertion begins in syntax checking through an examination of
the syntax rules of each language.

As both APL and LISP execute only in interpretive mode,
"smart" editors, those which perform syntax analysis, normally
do not cover either of these. Unfortunately most "smart"
editors do not include PL/I. These three languages do have
syntactic rules which we need to state in order to do a
comparison to provide a first test for the assertion.

So first we will focus on providing a means of entering and
maintaining source code, an GUI editor. We will begin with an
understanding of how the Watcom editor works. That means I
need to insure that everyone has access to a copy of its
source code. I will do that.

I would like to end this with another look at "control
structures", the basic building blocks of structured or
"goto-less" programming. All control structures have a
common feature, one input and one output connection. This
essentially makes them "pluggable" units attachable end to
end.

We have three basic forms: sequence, decision, iteration. The
simplest sequence is a single statement, our basic
programmable unit. We can expand this sequence with the
addition of another statement or another control structure
either decision or iteration. While decision and iteration are
statement assemblies unlike a single statement each represent
a programmable and plugable unit again conforming overall to
the one in, one out connection rule.

Thus decision and iteration like any other assembly may
contain control structures (sub-assemblies) or be contained in
higher level control structure assemblies. in every instance at
every level each structure conforms to the one in, one out
rule.

Now you have in programming a concept of "unit testing". In
using a compiler the smallest acceptable unit is a procedure
which it treats as a program. In using an interpreter the
smallest testable unit is a "variable" or a single statement.
This points up a significant difference between compiled and
interpretive code when it comes to testing.

With a GUI editor/interpreter you can mark a subsection of
your source code and test it as long the "cut" (the marked
portion) falls on "a" control structure boundary. Now you can
ask to test just this section...as if the other section did not
exist.

As we are or will be using a fourth generation language proof
engine along with predicate logic, we will have the ability to
specify value ranges, valid and invalid, for each variable in
the marked section. Once specified the software will consider
all the variables as a set and enumerate all possible
combinations of values among the variables and pass them as
input to our selected code. This will tell us what worked
(produced a "true" result) and by its absence what did not.

When you expand this from the level of a single statement or
control structure up to that of an entire procedure or
program, you have no need to offer it up to receive additional
testing by anyone. You have essentially eliminated the alpha
and beta of testing. You have kept it within the scope of a
single individual. This holds truer to the purpose of open
source, enabling the individual, than that practiced currently.

So enjoy the trip.

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

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