🚀 go-pugleaf

In article <893@hoptoad.uucp> farren@hoptoad.UUCP (Mike Farren) writes:
>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.

This is one I will gladly concede, in fact the most touted advantage of
Forth is that one programmer can build a complex system in a few weeks
or months (this is more a function of coding style and environment than
language syntax), there is no guarentee however that anyone else will
understand the quirks of the original programmer :-).

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

The reason this came up in net.arch in the first place is because most
programmers spend 5-15 years thinking in terms of large, flat routines.
When these routines are broken into their smallest componant parts,
they end up being useful "extensions" or "primitives.  Anyone can benefit
from habits learned by using forth, reguardless of the actual language
they use.  The other feature of "screen sized subroutines" is that
in RISC archetectures with good fast caches, these primitives become
self-optimizing micro-code.

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

There are two issues here.  If the primitives are "axiomatic" (you intuitively
know what they do, and what results to expect), they can be more useful than
a "compiled language" in which all primitives are limited to a specific
syntax.  Unfortunately, Forth primitives are not as axiomatic as they could
be.  Here, Smalltalk has shown to be a definite improvement over Forth.

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

In Forth, as in C, coding styles can vary from well structured to "totally
obfuscated".  Look at some of the winners of the "obfuscated C contest" :-).
Many forth packages are deliberately obfuscated just before release.
The most common technique is the "white space squisher".  Seeing forth with
no block structuring can be quite distressing.  This is not the "normal"
form or style.

>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.)

Ironically, I had just the reverse experience.  My first introduction to
C was Ron Cain's compiler, followed immediately by V6 Unix.  My previous
experience was in Forth, and these 20 page definitions, pointers to functions
returning pointers to ints, and some of the other "finesse" tricks of C made
my first impressions of C less than great.  Fortunately, I got over this
initial shock and C has been a very useful language ever since.  However,
I still try to stick with "screen sized" functions, build libraries and a
main-line, rather than programs with a few subroutines.

I won't even try to convince anyone they should convert all of their
production code to Forth.  There are too many advantages to the C/Unix
environment such as lint, indent, cb, cflow, ..... that make C easier
to document and analyse.  What I do reccomend, is examining general
style of programming.  Do you use an in-line copy rather than a macro
or a subroutine.  If you could use a subroutine at little or no cost,
would you rather use a macro or a subroutine?  If the answer to the
last question is yes, then it is actually possible to build an archetecture
that makes subroutines containing loops run FASTER than an in-line expanded
loop.

To be honest, if there were a GOOD C interpreter or incremental compiler/
editor that supported FULL C, available in source form for 4.2 BSD, I would
really like to know!  It is the only part of Forth that I actually miss :-).

>Mike Farren
>hoptoad!farren

Rex Ballard.