NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/lang/forth/3749

Internet Message Format | 1993-01-03 | 4.3 KB

Path: sparky!uunet!gatech!destroyer!gumby!yale!mintaka.lcs.mit.edu!ai-lab!hal.gnu.ai.mit.edu!mikc
From: [e-mail] (Mike Coughlin)
Newsgroups: comp.lang.forth
Subject: Re: Documenting
Date: 3 Jan 1993 21:59:08 GMT
Organization: /etc/organization
Lines: 74
Message-ID: <[e-mail]>
References: <4195.UUL1.3#[e-mail]>
NNTP-Posting-Host: hal.gnu.ai.mit.edu

In article <4195.UUL1.3#[e-mail]> [e-mail] (ForthNet articles from GEnie) writes:
>Category 3,  Topic 3
>Message 8         Mon Dec 28, 1992
>ELLIOTT.C                    at 12:26 EST
>
> ----via CRS Premium Bulletin Board -
>  USR Dual Standard 16.8K  [phone]
>
> Date: 12-19-92 (13:38)
>   To: ALL
> From: MARK VANDITTA
> Subj: FORTH CODING STYLE
>
> Is it my imagination, or do most Forth programmers lack formal
> instruction in structured coding?  I have found that most Forth
> programmers write code that is even more unlegible than that of C
> programmers raised on DEC Writers.  Why do Forth programmers
> insist on packing so many words on a single line at the sacrifice
> of clarity?  I like Forth, but I cannot tolerate most Forth
> programmer's coding styles. In other lanuages such as Algol,
> PL/I, Pascal, Ada, and C, most formally trained programmers use
> indentation to set off control structures.  I have yet to see any
> non-trivial Forth program written using indentation to show flow
> of control.  It has been proven that indentation leads to code
> that is easier to read and maintain.
>    <example omitted>
> I had the opportunity the other week to introduce Forth to a few C
> bigot friends of mine.  They all thought it was a neat language,
> but they likened it to APL.  They called it a write only language
> because they thought it was easier to rewrite a Forth program
> than it was to read and modify the existing one.
>
     Forth programmers have been trained in structured programming,
but most of them have absolutely no clue as to how to write
comments. This started years ago because Forth's inventor never
though anybody else would want to read a Forth program.
     One factor in the way Forth source gets written is in the block
structure. There are 16 lines by 64 characters and no tabs, line
feed/carridge return, etc. All the spaces to make up the 1024 chars
in the display are left in. So an indenting style similar to an
assembly language program would produce data on the disk that had
vast numbers of spaces. Writing the source out in lines of Forth
words with few spaces saves disk space. It also results in unreadable
code. Not many Forth programmers think of filling the blank spaces
with comments. Nobody pays much attention to how hard its is for a
non-Forth programmer to read Forth code. If they did then it would
be much easier for Forth programmers to read the code, too. But it
wouldn't be traditional.
     There is a great debate about the use of Forth blocks vs. text
files. The best reason for using text files is to be able to
indent the code for clarity and to neatly add comments where they
would look good. This does not seem to enter into the discussion.
Forth programmers think that a few cryptic abbreviations to show
the state of the stack before and after the word executes and the
use of long word names is all the documentation Forth needs. Ha!
Then they wonder why Forth isn't very popular.
     Forth is easier to understand than other languages that do
as much (or even less). But it needs as much commenting as
assembly language, and it doesn't get it. Every assembly language
programmer knows that a program woun't work if it isn't well
commented. Published assembly language programs are almost always
written with one comment per line plus some extra paragraphs
inclosed in boxes. The uncommented assembly language I've seen
is usually in the middle of Forth programs. Forth is much better
than assembly. Uncomented Forth programs can work. Its just that
only a computer can read them.
     There are Forth programmers who can write clearly commented
source that is easy to understand. You just have to look for a
very long time to find it. There used to be a book about Forth
that discussed good programming style and practice, but it went
out of print since not enough people bought it.

--
   Michael Coughlin             [e-mail]