does the ease of using the forth commands grow with time?
I have a headache trying to remember them all......it seems like i
play a guessing game with trying to sort out my calcualtions on the
stack until I finally get it.....but a week later I've no clue how i
even got the word workign...it just does......is thsi normal?

gavino wrote:

Definitely.

I would give a qualified yes. By that I mean once you have a new Forth
word working and fully tested, then it is quite common (at least for me)
to later forget exactly *how* it works. But I don't care. I am
confident that it does its job as intended. I guess it's a form of
information hiding and I see nothing wrong with that. But, here's the
qualification: You really should be able to go back and understand
words you have written without too much effort.

"gavino" gmail.com> wrote in message
news:b90bc238-54db-4a0b-96e3-1eb7feb80fa8@i18g2000prn.googlegroups.com...

I hope so, and I think that is starting to happen for me.
Although I had some experience with FORTH about thirty years ago
anything at a detail level was long forgotten. So I am in
learning mode again.

From one newbie to another FWIW:
Comments, comments, and more comments. I break my code into
'phrases' whose stack effects I can manage in my head and then list
what is on the stack after each phrase. It takes a little extra effort
but I don't have any problem understanding what I wrote a couple
of months ago. By the time I have the code working, often several of
these phrases have morfed into factors. Often a comment line
suggests a factor.

gavino gmail.com> wrote:

You do get used to it. It took me a while. I am a touch typist. To me
the typing is automatic. I think something and it appears on screen. So
when I wanted to dump a region of memory, I would have already typed the
word 'dump' before I began thinking about the parameters. Which meant
stack underflow messages every time I issued what seemed like a normal
straight-forward command.

I found "Starting Forth" by Leo Brodie a good read, but not a
particularly good reference book. It is not always obvious where to look
for things you vaguely remember reading but can't remember what he was
talking about when he mentioned them.

Do you mean get it to work? or "get it" as in suddenly understanding
what was previously baffling?

I am still a beginner at forth, and that stack without labels and its
reverse syntax nearly drove me nuts when I first started using it.

gavino wrote:

Learning Forth is a different process from learning most programming
languages, because of (a) the stack, and (b) the enormous command set.
In some respects it's like learning a new human language: you have to
develop a lot of vocabulary before you can express yourself effectively.

As others in this thread have said, the two keys are:

1. Comments! Every word needs a comment (the conventional place is just
after the name) describing what the word expects on the stack and what
it leaves there. In addition, a brief description of what it does, and
comments inside the word showing what various phrases are accomplishing,
all help. For newbies like yourself, the practice of putting one short
phrase per line and then a comment showing what's on the stack at the
end of that phrase is very helpful.

Robert Miller wrote:

Slightly wrong approach - give that phrase a name and a stack comment (i.e.
factor, factor, factor!). Especially if you are new to Forth, writing
one-line definitions is a must; writing long definitions is wrong even if
you aren't a newbee, but as beginner, you definitely can't handle them.
This then leads to the reputation of "Forth is unreadable".

Bernd Paysan wrote Re: frustration with starting forth

IMHO, writing *very* short definitions does not automatically lead to
readable code. This is because the number of words and their possible
combinations explodes (Gavino) and, especially with badly chosen names,
endless confusion will result.

If names are chosen correctly, and words have no side-effects, then
one can disregard the 'how' and get along fine (Doug's observation).

One possible reason is that they still use the metric of other popular
languages, where one page long functions or procedures are not
uncommon. I bet people coming from APL for instance don't make that
mistake.

Generally newbies (and sometimes others) are too much focused on the
supposed high cost of calls and returns, which incline them to inline
too much stuff. This is IMO a typical case of premature optimization.

Amicalement,
Astrobe

On Wed, 4 Jun 2008 10:50:01 +0200, mhx@iae.nl (Marcel Hendrix) wrote:

From the VFX Forth kernel sources, which generate the manual.

According to Marcel Hendrix :

Writing very short definitions imply writing many of them, and, as such,
coming up with names for all of them. Finding names works on the
programmer imagination, which is a scarce resource.

In my opinion, one of the strong points of the stack-based syntax that
Forth use is precisely that it designates operands implicitely:
arguments for a word are passed on the stack, and thus obtained from
their position on the stack. This contrasts with other syntaxes such as
C, where names must be given to function arguments and temporaries.
Lifting the need for so many argument names allows the programmer to
allocate more brain space to the task of finding names for functions
(i.e. words), but this can be overdone, as always. This makes writing
very short definitions difficult (at least, that makes it difficult for
me).

--Thomas Pornin