🚀 go-pugleaf

In article <142@cci632.UUCP> rb@ccird1.UUCP (Rex Ballard) writes:
[article excerpted for later comment]
[1]
> ... pull out the old "recursive decompiler"
>and "descriptive text cross reference tool" and expand those deep nested
>routines into a pretty "structured listing", which includes the whole
>system.
>
>An even better trick is to draw a roadmap before, during or after coding,
>and include it in the functional spec.
[2]
>Unfortunately, many people are afraid of new tools that require changes in
>the way one thinks.
[3]
>The weakness of forth is not documentation or structure, but the lack
>of axiomatic organization.  It requires a good associative data base,
>either human or computer.  If this is understood and planned, it can
>be quite a simple matter to sell this type of system.

[3] - It is precisely the lack of axiomatic organization which makes Forth
nearly unusable in an environment where code must be generated quickly,
in concert with other programmers, and in a fashion which must be maintained
by programmers other than the original programmers.  I have watched many
Forth programmers at work, and found *NONE* who went about the job of prog-
ramming in an organized fashion.  Much more likely was the "hack" method - 
develop a routine which does a specific, fairly low-level, job, and then
cut, bash and squeeze to fit it into the larger structure.  It takes a very
organized person to be able to keep the entire organization of a large soft-
ware project in his/her head, from top to bottom, and although Forth does
not force this type of conceptualization, the majority of Forth programmers
I have worked with seem to work this way.

[2] - ALL new tools require changes in the way one thinks.  It is simply a 
matter of deciding whether a major change in one's thought is valuable,
or will create more difficulty than it will solve.  My feeling is that there
isn't enough benefit to "thinking Forth" to justify relearning 15 years
worth of lessons.  Show me that there is, and I may change my mind...

[1] - One of the problems I have with Forth is that it requires external
guides before complex programs become comprehensible to someone unfamiliar
with those programs.  It shares with assembly language the drawback that the
low-level modules are extremely primitive, and, in turn, are often used in
extremely labyrinthian ways to accomplish a higher-level goal.  This does
nothing to help understanding.  When you add in the very peculiar structure,
syntax, and notation, you have a software system that, in every complex
example I have seen, is cryptic to the point of illegibility.  I have been
able to take quite complex C programs, and in a matter of a week or two, with
no help from the original authors, been able to port them to entirely different
systems with minimal problems.  The only time I tried this trick with a Forth
program (and a small one at that, originally programmed by someone I was
assured was a very good Forth programmer) I worked for a month before finally
deciding to scrap the whole project. (BTW - this involved porting to a 
machine with an order from management - "No Forth!".  We finally decided to
do a functional equivalent to the program - management decided to hell with
the whole idea.)

----------------
Mike Farren
hoptoad!farren