SCOUG-Programming Mailing List Archives

<< Previous Message <<

Date:	Sun, 5 Jan 2003 17:51:00 PST8
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: Re: ASK.exe ?

Content Type: text/plain

Peter,

From previous conversations I understand the difficulties that
have so occupied your time. It's just that I missed you during
our presentation after your goading me into giving it. I
enjoyed the experience as almost every sentence was
challenged by the audience. I would say audience
participation reached a new high. As Randell commented, "No
one went to sleep."

As one who believes in applying manufacturing methods in
software in which reuse of assemblies, in this instance filters,
plays an important role, I cannot argue against their use
where circumstances warrant. You assemble assemblies to
create a system.

A system operates as a whole, not as a separate set of
pieces, each requiring separate user communication. Each
communication has its own language to learn and master.
Each communication has its own source to develop and
maintain. Certainly you can (and do) use this process of
separate processes in programming.

In programming we want to go from source to executable(s).
To do that we have to write the source (data entry), perform
syntax and semantic analysis, and generate executable code.
If you examine this closely, the count of the different source
is one. Having to write and maintain any more than that
represents a loss in productivity.

So why not integrate the filters into a single system with all
the non-source communication automated within the
software? That occurs within every interpreter ever written.
It's obviously not a new concept.

It means you cannot (and should not) separate the data entry
filter from the syntax analysis one from the semantic analysis
one from the code generation one. It means then that your
only writing occurs only at data entry and all other writing
internally within the software.

With any source you can only make three types of errors:
syntax, semantic, and logic. With logic you can only make
two types of errors: omission and commission. You can only
correct these errors by writing or rewriting. For the quickest
possibly correction you need the earliest possible detection
which occurs for syntax and semantics immediately after data
entry. Logic errors get detected on testing which requires the
writing of test data. If you use the two-stage logic engine of
logic programming based on predicate logic, e.g. for all x
where x ranges in value from -50 to 2000, you can automate
the writing of the test data.

Moreover as you operate in interpretive mode you can "mark"
the set of source statements and separately test them,
irrespective of any other logic or path in the source. You can
automate the testing of everything from one statement on up.
No process of edit-compile-execute allows this. No set of
filters. No nothing.

On the other hand we want more SCOUG members and the
OS/2 community as a whole to participate in writing open
source. Without arguing what "techies" in this forum have
undergone in terms of learning and mastery, if it is not
necessary (and I hope I have shown it is not) then why force
everyone into unnecessary learning? Particularly when it
means a loss in productivity?

You see that's the issue here. The misuse of filters here is
only symptomatic of the deep hole that the "techies" have
dug for all of us. It's not that what they have forced upon
themselves (and us) does not work. It does. It just doesn't
work as well as simpler alternatives.

I'm surprised that you haven't run into "sift" before. Sift
checks source code for possible misuse, due primarily to the
weak typing of C. Much of sift as a separate filter has now
been incorporated within C++. Just another one of those
issues that Kernighan and Ritchie dismissed as
unnecessary.

I must be unduly dense with respect to ASK. I've managed to
ignore Norton up to now and would request something more
of a detailed specification. I suspect that you need only
ECHO(u/l), as its presence indicates its use; its absence, not.

You don't want to learn Prolog despite its brilliant disciple
Greg Bourassa. Prolog is perhaps the biggest mistake in
fourth generation languages, again straying far from the path
of the KISS principle. Perhaps the biggest mistake they made
was in disallowing the assignment statement, which
unfortunately means you cannot write Prolog completely in
Prolog. Probably accounts for why most of them are
implemented in LISP, a third generation HLL.

I have to admit that the porting URL set me off. Sometimes I
don't believe these people ever listen to what they are saying
or the negative impact it has on potential wannabes. I must
at times upset Dallas with my generally negative UNIX
remarks.

For my money the open source community is its own worst
enemy in putting up unnecessary barriers to entry and then
complaining as ratio of givers to takers continues to decline.
If you want people to contribute source code, then create a
system in which only a single source code exists.

We have more than enough expertise in SCOUG to make this
possible starting from a base of existing open source code.
We can begin with an editor and compiler, merging them into
an interpreter, and eliminate compiler-based language
restrictions to make a better C. The expertise we gain in
doing that will allow us to go where C, C++, and JAVA cannot.
We can then incorporate the filters that allows them all to
appear in source as we incorporate another one which
converts them to a less restrictive, simpler, and more
powerful source.

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

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 [ 05 | January | 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.