From: mikeh@starnine.com (Mike Haas)
Subject: Re: Documenting
Date: Mon, 4 Jan 1993 23:45:13 GMT
Organization: StarNine Technologies, Inc.

In article <1992Dec31.112348.12448@sol.ctr.columbia.edu> penev@venezia.rockefeller.edu writes:
>Mike Haas (mikeh@starnine.com) wrote:
>
>Do You need vertical format?	No

NEED? no, anyone can waste time seperating out assembly language
instructions on one line with their eye.  'Course, you can do either
in text files with no negative tradeoffs.  Trying vertical format
with screens dooms you to flipping between many screens.

>Do You need indentation?	No

YES.  Any control structure should be indented.  Period.
Putting IF and ELSE and THEN on the same line is silly and
complicates reading source code tremendously.

>: 
>: This is a side-effect of those ever-so-limiting 64 x 16 damn SCREENS!
>: 
>: In normal file-based environments (which all other languages are
>: standardized on), you don't have to worry about packing as much
>: into that tiny space as possible.
>
>You don't have to wory about about packing as much info in the screen
>either. One screen can hold 5 to 12 words (subroutines). This is
>enormous amount of info. The equivalent amount in C is more, that You
>can fit even on today workstations' 17" screens. Consider the overhead
>in C:
>
>procname(args) {
>	variables declaration;
>	body
>}  
>empty line
>
>You have four lines per entry, which cary basically no information.

What are we discussing, the pros & cons of screens vs. files or the
overhead of different languages?

I hold that antthing that restricts you to looking a a specific block
of text with no scrolling to look at CONTIGUOUS text is outdated
and not defensible (except for standalone controller implementations).

>
>: 
>: In otherwords, with SCREENS, there is no way to create pretty,
>: indented, clear code.  You either have to spread it over
>
>Look at _any_ 10 screens of FORTH, Inc.'s code and You can find 9 to
>be pretty, clear, UNindented code. 

Code that is not indented is, to someone who is used to working
with indented source code, always ugly.

>
>: several screens (requiring constant flipping in an editor), or
>: pack the hell out of each line (to get it all visible in one place).

>... or factor the words better.

Why should I have to rewrite my code just because of an antiquated
display technology?

>
>: 
>: SCREENS only display 16 lines at a time.  More dark ages stuff which
>: continues to cripple Forth's image.
>: 
>: Personally, I'll probably never work with SCREENS again, as I don't
>: anticipate any more SBC projects.  That's fine with me, as Forth
>
>I have worked on i486/MSDOS and R3000/UNIX and find it much more
>convinient to work with screens.

I suspect you have no choice.  Many forths do not support text files.
Proponents of such systems always seem to be the same folks who
argue for ancient stuff like screens.

>
>: really does interface well with modern OS's (even some that aren't
>: so modern), and I'm spoiled by working with standard text files
>: for about 7 years now.  I can't imagine ever preferring SCREENS...
>
>There are things, that files are very unsuitable for. consider a
>sextet index of a Monte Carlo Simulation Program:

Why are text files unsuitable for that?

Sscreens are unsuitable for their prime purpose... displaying source code.
They are also inadequate for tracking source, with all those idiotic
"load screens".

They are also incredibly wasteful... if you only enter one 1-line
definition on a screen, you are wasting all the rest of the storage
space, as screens must occupy 1024 characters, regardless of how
much is white-space and what is not.  Just the remainder of whitespace
on each line following the last non-white character is a waste.

All because of the inability to handle an "end-of-line" character!
And what OS doesn't provide THAT?

>
>
>       420 \ Polymers - Main                                   PSP 22/11/92
>       421 \   Polymers - local                                PSP  3/06/92
>       422 \   Polymers - contd.                               PSP 30/05/92
>       423 \ Energy discretization                             PSP  2/11/92
>       424 \ Parameters of the polymer simulation              PSP 28/05/92
>       425 \ Initial values of the parameters                  PSP  2/06/92
>       426 \ Interaction - structures                          PSP  9/05/92
>       427 \   Horizontal interaction                          PSP 28/05/92
>       428 \   Vertical interaction                            PSP 28/05/92
>       429 \   Location interactions                           PSP 15/04/92
>       430 \   2D-Array calcualtions                           PSP 21/05/92
>       431 \ T-dependent energies for the run                  PSP 29/05/92
>       432 \ Polymer latice                                    PSP 17/04/92
>       433 \   Neibours with cyclic boundary conditions        PSP 27/04/92
>       434 \ Calculate energy index                            PSP 29/05/92
>       435 \ Update sites                                      PSP 29/05/92
>       436 \ Dynamics                                          PSP  5/06/92
>       437 
>       438 \ Tabulate all energy differences                   PSP 29/05/92
>       439 \   Access energies and probabilities               PSP 29/05/92
>       440 \   Build energy and probability                    PSP 29/05/92
>       441 \   Horizontal connectivity                         PSP 26/04/92
>       442 \   Vertical connectivity                           PSP 26/04/92
>       443 \ 
>       444 \ Cluster statistics - structures                   PSP 27/04/92
>       445 \   Walk clusters                                   PSP 27/04/92
>       446 \   Collect cluster lengths                         PSP 22/05/92
>       447 \   Write cluster statistics to disk                PSP 22/05/92
>       448 \ Concentration of monomers                         PSP 25/04/92
>       449 
>       450 \ Stat variables                                    PSP 21/05/92
>       451 \   Definition of stat variables                    PSP 21/05/92
>       452 \   Statistics                                      PSP 21/05/92
>       453 \   Compute thermo-dynamic properties from stat     PSP 20/05/92
>       454 
>       455 
>       456 \ Swapper                                           PSP 17/05/92
>       457 \ Swapping interface                                PSP 17/05/92
>       458 \ Change Lattice side and reboot                    PSP 14/05/92
>       459 \ 96-bit data                                       PSP 22/05/92
>       460 \ Statistical words                                 PSP 30/05/92
>       461 \   Statistical words                               PSP 31/05/92
>       462 \ Data base management                              PSP 20/05/92
>       463 \ Additional operators                              PSP 21/05/92
>       464 \ Invalid fields                                    PSP 24/05/92
>       465 \ File of samples                                   PSP 21/05/92
>       466 \ Thermodynamic quantilies                          PSP  3/11/92
>       467 \ File of lengths                                   PSP 22/05/92
>       468 \ File Density of states                            PSP  8/11/92
>       469 \ Produce SAMPLES from TDQ                          PSP 20/05/92
>       470 \ Convert SAMPLES Old > New                         PSP  3/06/92
>       471 \ Locate L in the file                              PSP 21/05/92
>       472 \ Produce Thermo Dynamic quantities from samples    PSP 24/05/92
>       473 \ Avaraged statistics                               PSP  6/06/92
>       474 \ Cumulant computation from samples                 PSP  6/06/92
>       475 
>       476 
>       477 HEX \ Optimizing                                    PSP 23/04/92
>       478 \ Internal registers                                PSP  5/05/92
>       479 
>
>Try to have this with files. And talk about documentation afterwards.

Simple.  Each is in it's own file.  Clean, clear, and no waste of space.
And if you want to import some support routines into another project,
you simply call it by name without having to remember all those
screen NUMBERS (y-e-c-c-h-h).  Just another place to make a mistake.

'Course, maybe you LIKE having to specify a section of code both
by NUMBER and then include a comment to explain what that number means.
Me?  I like to just type in a descriptive filename.

I quit programming in hex code and front-panel switches when compilers
became avaiilable, too.

>
>: and I don't care how cool a Forth SCREEN editor you have... there are
>: much better ones for text files.
>: 
>
>This is not quite true. I've tried almost all of the editors on the PC
>(pe2, e3, kedit, edit, professional editor (IBM), WINWORD) and emacs on UNIX.

Sorry.  Try a good editor with a gui... mouse operation, drag-select,
cut copy paste, find & replace MULTIPLE FILES OPEN.

Check out text editors in a WINDOWING environment, like Mac or
Amiga, Next, OS/2, even (yuk) Windows.  (Do you get the idea
the world is changing without asking you?  Or the Forth community?)

>None is better for editing programs that the screen editor I use. The
>reason is very simple. Even though the good editors have their
>languages, not is a flexible as FORTH is. They are pretty narrow too.
>On the contary one has the entire source of his editor in FORTH and
>implements whatever functions he considers usefull. And one ends up
>with a highly tuned to himself editor. 

Big deal.  Not as flexible?  You need to looka round a little more.
SCREENS are not at all flexible.  They are fixed chunks of 1024
characters that can't be printed, searched or in any OTHER way
processed by the prolifera of OS utilities any system provides.
Or third-party product like print spoolers, source control
systems, etc. etc. etc.

Screens waste space and limit what you can see at one time (can't even
look at two things together if they aren't on the same screen).

And customizability?  There are text editors that are 100%
customizable.  You can add e-macs-style macros to make them feel
like emacs, or vi, or ???  That's flexibility.  You can establish
any keyboard paradigm for any editor, or dream up your own.
Never has a Forth editor approached what is done in standard text
file world.

The reason is simple.  Only Forth people write Forth editors.
The rest of the computing universe provides products for text files.
Therefore, there is a tremendous amount of creativity, ideas, and
energy that goes into constantly providing better text-file
processing tools.


You can write macros in them, interface to other languages (ever hear
of language-sensitive editors?... some might even have offered
Forth interoperability IF Forth wasn't so wierd with SCREENS).

>
>
>: I hope I never again have to wind my way trough something like...
>: 
>: 5 LOAD 8 LOAD 23 LOAD 100 110 THRU 56 LOAD 13 LOAD etc. etc. etc
>: 
>
>You can write extremely cryptic code in FORTH, as well as in almost
>any languge. An usual load screen, though looks like:
>
> 0 ( Electives)   DECIMAL
> 1 : <CREATE>   >IN 2@   SWAP 1024 * + ,  (CREATE) ;
> 2    ' <CREATE> 'CREATE !     4 CONSTANT B/H  ( 0 if no  LOCATE)
> 3 ( Aids) 12 LOAD  13 LOAD  14 LOAD 11 HELPS  10 LOAD  23 LOAD
> 4 ( Disk retries   33 LOAD     6 LOAD)  2 LOAD
> 5 ( 32-bit)  15 18 THRU   ( 21 23 THRU)  ( char)  19 LOAD
> 6 ( L.C. Editor) 20 LOAD  ( UNIX Date & Time) 34 35 THRU
> 7 ( Calendar)  31 LOAD   TODAY @ .DATE  ( Loops)  4 5 THRU
> 8 ( Time)  32 LOAD   .(  Time )  @TIME .TIME
> 9 : SYSTEM   11 DATED  ."  Time "  @TIME .TIME ;
>10 : ONDISK   7 OFFSET @ -  HELPS ;     7 LOAD
>11 ( Tasks)  24 25 THRU   \ Printer)  28 LOAD  ( Runner)  29 LOAD
>12 ( Screen editor)  1 LOAD \TERM    222 LOAD
>13 : HELP   SYSTEM ;    GILD
>14 ( Terminal: ANSI)     ' ?CREATE 'CREATE !
>15 \S   polyFORTH II Level 4      31 Jan 1992 

That's just beautiful.  Really gorgeous.  And you're trying
to DEFEND THAT?  Load screens are laughable.  You don't
realize it, but you might as well be arguing for piston-powered
airplanes being better than jets.

>
>
>FORTH is a extremely democratic language. You can write _whatever_ You
>want (and be responsible for this afterwards). I won't argue, that
>screens is better or worse than files for everybody. I'll argue, that
>it's beter for me.  And this is the beauty of FORTH - You can express
>Your abstractions in code. FORTH is neither high level, nor low level.
>It is of one particular level - _Your_ level.

The beauty of Forth has nothing to do with screens.  In fact, using
text files removes so many headaches, that Forth actually improves
as a managable language.

I always wonder how many proponents of screens have never tried
a good file implemtation.

The fact that many still argue for screens is a statement as to 
why Forth will never be accepted by the mainsteam.