SCOUG-Programming Mailing List Archives

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

Date:	Thu, 15 May 2003 21:03:32 PDT7
From:	"Lynn H. Maxson" <lmaxson@pacbell.net >
Reply-To:	scoug-programming@scoug.com
To:	< "scoug-programming@scoug.com" > scoug-programming@scoug.com >
Subject:	SCOUG-Programming: A slight pause

Content Type: text/plain

"Baby talk. The machines can grow up, just as we did"

Not on their own. Basically the architecture hasn't changed
since the first computer. It cannot grow just as we did. We
haven't mastered our own growing process yet, just as we
have no intimate understanding of what we blissfully refer to
as intelligence. The machines lack intelligence. No software
can transcend the instruction set. It cannot do what the
instruction set will not allow. No amount of logic, fuzzy or
otherwise, will change that.

When you create a machine that can dynamically create its
instruction set you may have made a jump in capabilities, but
have created a completely useless computer, i.e. something
that does what you instruct it to. We have enough trouble
with people who refuse to follow instruction. Who would buy
a computer as obstinate?

I'm not going to enter a debate on the merits of fuzzy logic. I
do have some comments on ambiguity, which may exist
initially, but eventually must disappear in getting to a machine
instruction set. That ambiguity, the possibility of the same
thing having multiple meanings, moves a parser from doing
content to performing context analysis in natural languages.
Actually the preceding definition is incomplete. Ambiguity also
includes contradictions. Ambiguity then becomes the generic
situation in any decision process.

Too many people try to prevent ambiguity from entering the
software development process. They often forget that the
normal state of a process is incomplete. Ambiguity in a
process, representing an incompleteness of some sort, need
only resolution at some point prior to completeness, the end
of the process.

If we have a goal of minimizing writing effort in software, to
get as close to "write once" software we have to minimize
rewriting. To do that we may need to introduce ambiguity in
our writing, leaving it to the software to eliminate it at some
point prior to completion.

For example, in REXX and APL "a = 7" and "a <- 7" both
implicitly define "a" as a numeric, in this instance integer
variable. That's fine unless you at some other point say "a =
8.4". It's still numeric, but has changed from an integer to a
real number variable. Normally that means it changes from a
fixed binary (integer) form to a floating point (real) form.

Actually both 7 and 8.4 are decimal numbers, fixed dec (1)
and fixed dec (2,1) respectively in PL/I. If you consider that 7
and 7.0 represent the same decimal value then the fixed dec
(2,1) covers both 7 and 8.4. The software in processing this
can easily upgrade a fixed dec (1) to the more inclusive fixed
dec (2,1). Now C, which has no native fixed point, variable
precision decimal arithmetic support has only a real, i.e.
floating point, option as an all inclusive form.

The point is that "a" in this instance is a numeric variable. If
we have multiple instances with an equally multiple possible
values, we won't know if we have an all inclusive form until
after all the instances are in. Only until they are in do we
have to make a decision.

That's an instance of "late" binding, of putting off making a
decision until the latest possible moment. Moreover it means
we can "review" its various meanings instead of having to
"preview" their possibilities before we have more complete
knowledge. Therefore why can we not simply state that a
variable is numeric, a generic description, putting off its
explicit definition until we feel we have covered all use
instances?

If we can do it for arithmetic variables, we can do the same
for string variables: we can put off any explicit declaration
until we have all the use instances. As long as we have some
valid form covering the use instances determined by the
software we have no reason not to take advantage of the
reduced rewriting that late binding provides.

This actually gets back to something imposed as a language
restriction or rule when we really have an implementation
restriction: someone didn't want to bother writing the
software to ease the programming effort. They didn't want
to deal with ambiguity, though they could have decided
otherwise. That places the burden on the programmer.

"Parse this sentence: "Read the User Log File and print a
report of all users who consumed more than 3% of system
resources." That's not COBOL. Nor is it a logically flowing
program. But there is enough information in that single
sentence to generate a complete program."

You were doing fine until you got to "system resources".
Back to the requirements gathering.

"I have no quarrel with your direction. But you need to make
your computer as useable to the non-programmer as your car
is useable to the non-mechanic"

I want to ease the task of programming through software that
allows people to do what it cannot and it to do what people
need not: shift all clerical activity to the software. I will
agree that as a programmer I want to provide an equally
proficient user interface to the non-programmer. In short
from tool builder to tool user through multiple levels I want
each builder level to make the extra effort necessary to
reduce what the user must do.

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

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