SCOUG-Programming Mailing List Archives

>> Next Message >>

Date:	Sat, 15 Feb 2003 20:11:27 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: In retrospect

Content-Transfer-Encoding: 7bit

I hate getting whacked by a cup of coffee. As Charlie said,
holding my thermos of water up to me, "Why did you drink
coffee instead of this?" At any rate things just didn't seem to
go as planned.

All logic programming from SQL to Prolog to Trilogy to AI to
Neural Nets uses a two-stage proof system, a completeness
proof (first stage) and an exhaustive true/false proof (second
stage). Prolog and SQL use a form of logic known as clausal
logic, while Trilogy uses a form known as predicate logic. The
difference between the two forms, which are otherwise
logically equivalent, lies in how the data in the exhaustive
true/false proof is created. In clausal logic, e.g. SQL, the user
must create the data, while in predicate logic, e.g. Trilogy, the
software creates the data.

Unfortunately I couldn't pull off the Trilogy demo of the
spiders, beetles, and legs problem expressed as 8*s + 6*b = l,
in which you give a value for the number of legs and in turn
you receive those combinations of spiders and beetles which
match the equation. I made the error of not prefixing the line
with "all" to read "all Puzzle_soln(x, y, 46)". Rememer to
remind me of this (as if I could possibly forget) next time.

The same sort of logic using data generated by the software
is used the in PL/I program peg_sol4 whose source and one
solution I've attached to this. If I remember correctly, it took
something like 3 days before the first solutions began to
appear.

Having software instead of people create test data represents
one more source that people do not have to maintain. One
that has the added advantage of automatically adapting to
change. So the software both creates and maintains the
source.

I had hoped then to transition to the subject of the control
structures of structured programming: sequence, decision
(if...then...else), and iteration (do while...) along with the
variant of decision (case(switch(...)case(...)...) and iteration
(do until...). All these have the common attribute of one input
and one output, both pluggable, reusable, and for the
purposes here individually testable using software generated
test data based on user prescribed rules.

I should perhaps also provide a graphical illustration of the
control flow within a program to illustrate the reality of finite
paths instead of the myth of infinite paths. We could then
show how you could decompose these paths into software
testable segments, working from the inside out, i.e. from the
lowest level to the highest in the program, and iteratively
performing an exhaustive test of the entire logic of the
program. The end result not only eliminates the need for beta
testing and beta testers, but provides a level of software
quality that such beta testing has never achieved.

Throughout all this you never leave the tool or ever write in
anything except the specification/programming language. One
tool, one language with full functionality. Compare this with
the UNIX toolset that comes with emx, each tool with its own
language that the user must sequence in order to achieve the
same functionality.

The issue is productivity. The guiding principle is KISS. The
deciding principle is Occam's Razor. The maxim is "Let people
do what software cannot and software what people need
not".

As a final note I would suggest doing a google search on Paul
Voda.

File attachment: peg_sol4.pli

File attachment: solution.txt

Return to [ 15 | February | 2003 ]

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.