SCOUG-Programming Mailing List Archives

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

Date:	Fri, 2 Jan 2004 20:39:34 PST8
From:	"Lynn H. Maxson" <lmaxson@pacbell.net >
Reply-To:	scoug-programming@scoug.com
To:	"osfree" <osFree@yahoogroups.com > , "scoug-programming@scoug.com" <scoug-programming@scoug.com >
Subject:	SCOUG-Programming: QA equals testing, Part One:Detection

Content Type: text/plain

Peter Skye wrote:
"The difficulty here comes when someone wants to read and
understand the specs, Lynn. Things need to be organized so
they can be understood. Can you imagine studying chemistry
and not learning the table of elements until three semesters
on? ..."

Peter,

We live in different universes. You live in one in which you
can always predict change;I, in one in which change often
occurs unpredictably, in fact randomly. I have two things that
I need to accomplish. One, I need to insure that I have
specified a change correctly. Two, I need to insure how this
change works within its set of associated specifications.

The first only I can do, correctly or otherwise. Correctly or
otherwise it remains my responsibility. The second I leave up
to the software to determine the optimal, logical organization
of the source. This means at the end of the process I have
two sources of equivalent content for viewing.

The software has no concern if a change or set of changes
impacts an existing logical organization. It doesn't use the
currently logical organization as source input, which
imperative languages require you to do. It simply generates a
new logical organization. It does it hundreds and perhaps
thousands of times faster than it takes you to alter a single
logical path in an existing logical organization. It regenerates
from scratch, from unordered specs, where you must rewrite.

"...I'm serious here. There's the engineer who makes the
theoretical (which is quite organized) and makes it practical.
There is the scientist who takes random pattern-matches and
creates a concept (which is organized). Then there are the
weed-smoking, pill-popping artists who are all tangentially
connected to Haight-Ashbury and can't even get organized
enough to buy groceries at 7-11.

Which camp are you in?"

I'm in the camp of the division of labor where I do what the
software cannot, i.e. write specifications, and it does what I
need not, i.e. analysis, design, construction, and testing. It
doesn't do anything that I cannot view, follow, or understand.
It produces a global logical organization without concern for
how many times it gets tossed and regenerated from scratch.
It does it in less time than I can write a single statement.

The point is I can write a single specification once regardless
of the number of instances it occurs reused in the optimized
logical organization. That says I only have to modify a single
source, submit it to have all use instances occur. I can choose
to have it occur once invoked repeatedly as a subroutine or
have it replicated in each use instance or through
meta-programming, again written as a specification, any
mixture of each.

While I can only speak to my experience I don't know of any
imperative language implementation which allows this
flexibility. It's builtin to declarative language implementations.
It's what occurs as part of the completeness proof. It's part of
the compilation/interpretive process. I have at another time in
another thread suggested that you could make it work for
imperative languages by making changes to the
implementation without having to change the language.

Logic programming uses a two-stage proof engine. Nothing
prevents an imperative language implementation from doing
the same. In that manner we could take advantage of
people's ability to write error-free code in the small in
conjunction of software to do the same in the large. It simply
means not requiring a programmer to perform global logical
organization prior to submitting for a compile.

This means that you can have named reusable code segments
from the statement level up through any sequence of control
structures up to a procedural level. Any reusable code at any
level can have reuse instances within any other including
across multiple procedures. By implication it means that you
can input multiple "main" procedures into one compile as a
single unit of work producing multiple output executables.

You can do this by modifying the existing GCC compiler if you
so choose with all the benefits of doing so. You don't have to
wait for SL/I. It's not an SL/I-specific thing. It's a logic
programming thing that doesn't care if its input source is
imperative or declarative or a mixture of both.

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

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 [ 02 | 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.