Forth-eV Wiki

\ This file is from the Forth SIG on CompuServe.


NOVICE.TXT/binary         06-Feb-88 5760               11

    Keywords: LEARNING TEXT BLOCKS WRITE-ONLY
    
    Some general notes on learning and using Forth from the perspective of 
a novice user.  -Doug Hoffman 



Some notes on Forth from a novice user:
--------------------------------------
By Doug Hoffman  February 6, 1988


CHOOSING FORTH

In mid '85 I had finally decided to purchase my first microcomputer, a
Macintosh.  I knew that I would also want a programming language to use
with it, but was unsure of which.  All of my programming training and
experience was in Fortran from college.  I knew that I wanted something
more powerful than Basic, but was somehow dissatisfied with Fortran.
In Fortran it seemed that as a program's complexity and length increased,
my ability to revise or add to it decreased.

I asked a friend, who happened to be a Motorola sales rep, what he
would recommend.  His response was a wistful, "I can always do something
faster in Forth".  Having never heard of this language, I trotted off to
the local library and luckily stumbled across Leo Brodie's STARTING FORTH.
I was intrigued (and amused) and decided to "go Forth".


ON LEARNING FORTH

After spending an entire weekend wrestling with blocks files, stacks, and
the like, I was horrified and convinced that I had made a mistake.  Who
in their right mind would want to program in this godforsaken language!

One error I made was in immediately trying to port over my favorite
Fortran program.  I had no feel for the concept of information hiding
and factoring, and I tried to write Forth code that paralleled the
Fortran code.  Of course I wound up with extremely long word
definitions that were impossible to read or work with.

In hindsight, I think that I was somewhat impatient and at least half of
the frustration I experienced was caused by the complexity of programming
the Macintosh (I wanted to do windows, menus, controls, etc. right away).

Fortunately I stuck with it and eventually began to appreciate Forth
and learn to use it.  After two years I am hooked and can't imagine
what features another language could offer to pull me away from Forth.
One thing that helped was my prior familiarity with RPN calculators.
I didn't want to give up the notion that the stack grew "upwards".

I think now I have decided that the stack should be thought of as
growing "sideways" (to the left).  This seems more consistent to me
with stack notation, even though we are told to think of the stack as
growing "downwards".  Trivial issue.


THE WRITE-ONLY LANGUAGE

InfoWorld's Steve Gibson has called Forth a "write only" language
( Infoworld, Oct.26,1987).  I assume by that he meant that he has
trouble reading and understanding code that he has written in Forth.


Early on, it also annoyed me to write mathematical expressions in Forth
that didn't look anything like the expression would if I were to write it
out with pencil and paper.  Later, it occurred that the most
difficult task for me, when writing and reading my source code, was to
be able to follow the overall flow, branching, and logic.  For me,
Forth proved to be far superior to Fortran and Basic in doing this.
Correctly coding a simple mathematical expression in Forth takes a
little more work than doing so in an "algebraic" language, but the
extra work spent is trivial when compared to that saved in being
able to follow the overall program flow.

Besides, is  T=(L/C)/((1-(V**2)/(C**2))**.5  really that easy to read?
I think that when the expressions become complex, the stack becomes
equal to or superior than algebraic notation.


TEXT VS BLOCKS FILES

I liken the argument of text vs blocks as being loosely similar to
calculators vs slide rules.  Some old timers still maintain that learning
to use a slide rule was good for you, and you somehow had a better
understanding of the calculation than if you had used a calculator.
I never understood the intrinsic intellectual value of sliding together
pieces of wood and lining up crosshairs. Okay, the ability to do
rough estimates in the head is important, I just don't think that you
need to use a slide rule to learn to do that.

Likewise, writing concise code in modular packets is also a desirable
skill.  But you don't need blocks to do that.

I agree with what I think Don Colburn has said.  It all depends on the
quality of the tools available.  Certainly there are some very good
blocks editors and some not so good text file editors.  The Sibley
Editor is nothing short of marvelous, in my opinion.  If there were
a blocks editor that could read my thoughts, then MAYBE I'd give up
the Sibley Editor.


CHAINING VS SCRIPT FILES

I have no problem in breaking my program up into smaller file segments
(Variables and Arrays, Windows and Controls, Text Routines,
Main Program, Menus, etc.).  This makes the program conceptually
easier for me to think about.  It also saves paper when I change part of
my code and want to update the hard copy.

At first I was writing script files that would include all of the
files that made up my programs.  This worked fine.  But later I found
that if instead I began each file with ANEW and ended it with a
statement to INCLUDE the next file, it worked out better.  This way
if I needed to change some code in, for example, the third file of
ten that were chained together, I merely had to open the third file,
make the changes and "Save & Include" that file.  Only files three
thru ten were then recompiled.  Very quick.  Even quicker when used
with enough ram cache so that the only disk access was for file three.
Perhaps someone else has a better idea.  I'm interested in hearing about
other techniques.


MISCELLANEOUS

Hey, I'm no computer jock.  I start getting lost when I read about
things like DOER>MAKE, IMMEDIATE, TOKEN.FOR, etcetera.  But that's
okay with me.  I am getting far more performance out of Forth than I
did with other languages.