Forth programming style...

[Mux]

This has probably been discussed to death but I wanted to get an update on what people have adopted. Personally, I've subscribed to Chuck's '1-liner' method where I try to break bigger functions down into small, single line words that eventually get called to build the function.

Anyone?

-Mux

[Julian Fondren]

Stack comments are a must. ciforth's Stallman-style
comments may be superior, but I haven't used them for a
while to see. But I *have* used kc5tja's style of no
stack comments,

( demonstration )
: foo some words ;
: bar some words ;
: long-word see it reads like an index ;

and, coming back to that code years later, I couldn't
make heads or tails of it, which is not a reaction I
enjoy having to my own code. I still do like kc5tja's
emphasis on not caring if words 'redefine' earlier words,
as this takes advantage of Forth's dictionary to let you
be freer with your names.

And I think the remainder of Forth style is just having
good names and good factors. I don't think definition
lengths matters so much, except to hint that you may be
missing a trick with your factors, or that your word may
being doing more than its name would suggest.

But if you want rules, these are the best:
https://groups.google.com/d/msg/comp.lang.forth/BNjiUjmN2pw/SHwGuf4lqK4J
plus "don't bury your tools". I guess that's from
Thinking Forth? I don't remember the source.



Some discussion about the Forth Stallman convention:
https://groups.google.com/d/msg/comp.lang.forth/jIkvsMkdJjw/RfDIGh5_ot4J

[Julian Fondren]

On Tuesday, July 21, 2015 at 7:28:08 PM UTC-5, Julian Fondren wrote:
> But if you want rules, these are the best:
> https://groups.google.com/d/msg/comp.lang.forth/BNjiUjmN2pw/SHwGuf4lqK4J

From that:

> These rules are not for beginners learning their Forth ABCs but might be
> helpful to a person who has written a program and wants to make it
> clearer.

Rules for beginners would be more like:

1. Use stack comments!
2. Don't use locals!
3. Don't write definitions longer than 3-5 lines!
4. Here's a list of naming conventions.
5. Please still try to use a human language with your names.
6. Don't use vocabularies.
7. You probably don't need that cool feature from language X.
8. Don't let holier-than-thou Forth programmers make you
wear a straitjacket. After pulling your hair out for a
while, you'll go raving mad and run off to learn Common
Lisp or Haskell or something, and literally nobody wants
that.

[Mark Wills]

Rules 8 and 2 contradict each other! Rule 3 is good.

I would let beginners use locals. They reduce stackrobatics.
Locals greatly simplify the process of actually writing out
the code. You don't need to worry about the position of things
on the stack so much. When they have got a little more
proficient and confident, get the beginner to return to his
code and see if he can "solve the puzzle" without locals.
Perhaps by factoring more. Show him the actual value of
factoring.

When I was starting out, writing Forth was like solving a
fricking rubics cube, because, as we know, in Forth, you're
managing the flow of data (the stack) as well as code. It
meant that writing code could be damn right frustrating.
It was partly of my own making: inappropriate factoring.
That's where having a mentor present (i.e. classroom)
is invaluable. Eventually the penny drops and you realise
just how much factoring can simplify things. But I'm all
for a gentle introduction to Forth, having been there
myself.

I'm convinced that most people that try Forth give
up in sheer frustration. Let's face it, if C or some other
"normal" language is your thing, then Forth is just plain
hard. More so if you're learning it on your own.

Here's some of my personal guidelines:
* code in lower case
* useCamelCase for word names
* use UPPERCASE for constants and sys calls
* words that store to memory shall be prepended with !
* words that fetch from memory shall be prepended with @
* words that write to IO shall be prepended with io!
* words that fetch from IO shall be prepended with io@
* no magic numbers (use constants)
* stack comments
* all words shall have a small english description

[Elizabeth D. Rather]

On 7/21/15 9:48 PM, Mark Wills wrote:
> On Wednesday, 22 July 2015 01:39:02 UTC+1, Julian Fondren wrote:
>> On Tuesday, July 21, 2015 at 7:28:08 PM UTC-5, Julian Fondren wrote:
>>> But if you want rules, these are the best:
>>> https://groups.google.com/d/msg/comp.lang.forth/BNjiUjmN2pw/SHwGuf4lqK4J
>>
>> From that:
>>
>>> These rules are not for beginners learning their Forth ABCs but might be
>>> helpful to a person who has written a program and wants to make it
>>> clearer.
>>
>> Rules for beginners would be more like:
>>
>> 1. Use stack comments!
>> 2. Don't use locals!
>> 3. Don't write definitions longer than 3-5 lines!
>> 4. Here's a list of naming conventions.
>> 5. Please still try to use a human language with your names.
>> 6. Don't use vocabularies.
>> 7. You probably don't need that cool feature from language X.
>> 8. Don't let holier-than-thou Forth programmers make you
>> wear a straitjacket. After pulling your hair out for a
>> while, you'll go raving mad and run off to learn Common
>> Lisp or Haskell or something, and literally nobody wants
>> that.
>
> Rules 8 and 2 contradict each other! Rule 3 is good.

I don't see a contradiction, probably because I don't understand what #8
means, in practice.

> I would let beginners use locals. They reduce stackrobatics.
> Locals greatly simplify the process of actually writing out
> the code. You don't need to worry about the position of things
> on the stack so much. When they have got a little more
> proficient and confident, get the beginner to return to his
> code and see if he can "solve the puzzle" without locals.
> Perhaps by factoring more. Show him the actual value of
> factoring.

I strongly disagree. Having taught probably a thousand or more new Forth
programmers, I find that a few days of intensive practice with stacks is
sufficient for it to become straightforward and natural, rather like
learning to ride a bicycle. If they start with locals, they tend to
simply skip that learning process and will never feel comfortable using
the stack.

> When I was starting out, writing Forth was like solving a
> fricking rubics cube, because, as we know, in Forth, you're
> managing the flow of data (the stack) as well as code. It
> meant that writing code could be damn right frustrating.
> It was partly of my own making: inappropriate factoring.
> That's where having a mentor present (i.e. classroom)
> is invaluable. Eventually the penny drops and you realise
> just how much factoring can simplify things. But I'm all
> for a gentle introduction to Forth, having been there
> myself.

Yes, I regret that there aren't enough classes. I encourage the folks
who are teaching the scouts to have good Forth classes at the beginning!

> I'm convinced that most people that try Forth give
> up in sheer frustration. Let's face it, if C or some other
> "normal" language is your thing, then Forth is just plain
> hard. More so if you're learning it on your own.

Part of the problem is that many newbies are working with Forths that
are not well-documented and from obsolete books like Starting Forth. A
much better place to start, IMO, is from one of the free evaluation
versions of the commercial Forths. These tend to have a better user
interface and extensive documentation. Once one acquires some skill with
the language, if he/she wants one of the non-commercial versions, or
wants to write one, it'll be much easier.

> Here's some of my personal guidelines:
> * code in lower case
> * useCamelCase for word names
> * use UPPERCASE for constants and sys calls
> * words that store to memory shall be prepended with !
> * words that fetch from memory shall be prepended with @
> * words that write to IO shall be prepended with io!
> * words that fetch from IO shall be prepended with io@
> * no magic numbers (use constants)
> * stack comments
> * all words shall have a small english description
>

It's good for anyone to develop a consistent style. In our books (e.g.
Forth Application Techniques, Forth Programmer's Handbook, product
manuals) we describe the style guidelines we use at FORTH, Inc. We also
recommend that groups working on a project agree on a group style, which
all programmers in the group will use in their code. This makes it far
easier for programmers in the group to read and share each others' code
comfortably.

Cheers,
Elizabeth

--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[Raimond Dragomir]

I strongly agree with all of that above.

I would add this:
"Stackrobatics" only for deep burried library words. Words that are
normally "write once" and don't have to look at them often. Words that
you need only a stack comment to look at (or any other documentation)
to use properly.
For "application" words/logic use stack juggling only when the use it's
obvious (one, two levels at most). For anything else use locals, or even
global variables.

[Anton Ertl]

Julian Fondren <ayr...@gmail.com> writes:
> I still do like kc5tja's
>emphasis on not caring if words 'redefine' earlier words,
>as this takes advantage of Forth's dictionary to let you
>be freer with your names.

Diasdvantage: you cannot directly test the shadowed word.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm

[Mark Wills]

I'm with Raimond :-)

I'm aware that (for some reason) there's a general dislike for local
variables among Forthers. It's almost like it's a measure of clever
you are: If you need locals you're not a "real" Forther. I'm all for
writing code that I and others can understand six months or six years
from now. That's actually quite hard to do in Forth, especially in
the lowest levels of an application. Locals in particular help code
be me much more readable.

I must admit, there have been times when
I've looked at older Forth code that I have written, with a view to
modifying it in some way. You get bogged down with all those DUPs
SWAPS, >R R> "noise" that it really is simpler to scrap it, note the
stack effect, and re-write it from scratch. It's actually quicker!

I want to say something about phrases. I believe the concept of
phrases exist in Forth, much more than other programming languages.
I believe that very experienced Forth programmers can analyse code
and recognise common phrases and understand what they are doing at
an almost unconcious level, similar to an epxerienced music reader
reading a stave. I believe Elizabeth can do this. I, alas, cannot.
I have to read each word and conciously compute what is happening.
I have to execute the code in my head, word by word. I believe
Elizabeth and some of the others here (Stephen, Anton, Bernd,
Hugh) do not. They understand it at a more unconcious, instinctual
level. Experience really pays off in Forth.

[Anton Ertl]

Mark Wills <markwi...@gmail.com> writes:
>On Wednesday, 22 July 2015 01:39:02 UTC+1, Julian Fondren wrote:
>> On Tuesday, July 21, 2015 at 7:28:08 PM UTC-5, Julian Fondren wrote:
>> > But if you want rules, these are the best:
>> > https://groups.google.com/d/msg/comp.lang.forth/BNjiUjmN2pw/SHwGuf4lqK4J
>>
>> From that:
>>
>> > These rules are not for beginners learning their Forth ABCs but might be
>> > helpful to a person who has written a program and wants to make it
>> > clearer.
>>
>> Rules for beginners would be more like:
>>
>> 1. Use stack comments!
>> 2. Don't use locals!
>> 3. Don't write definitions longer than 3-5 lines!
>> 4. Here's a list of naming conventions.
>> 5. Please still try to use a human language with your names.
>> 6. Don't use vocabularies.
>> 7. You probably don't need that cool feature from language X.
>> 8. Don't let holier-than-thou Forth programmers make you
>> wear a straitjacket. After pulling your hair out for a
>> while, you'll go raving mad and run off to learn Common
>> Lisp or Haskell or something, and literally nobody wants
>> that.
>
>Rules 8 and 2 contradict each other! Rule 3 is good.

Maybe rule 8 is just meant to indicate that you should take the other
rules as rules-of-thumb rather than laws. Maybe beginners should even
try violating rule 1, to see why this is a bad idea:-).

[humptydumpty]

Hi!

I'll try first using stack.

Just an example of my recent coding.
Having to write a definition:

push ( addr len delta -- ;inside buffer at ADDR LEN push block of LEN-DELTA
size from ADDR to ADDR+DELTA )

I wanted to experiment with locals, so first definition was:

: push { addr len delta -- } addr addr delta + len delta - cmove> ;

I didn't like it, so reedited 'push' using stack:

: push ( len delta addr -- ) dup 2swap /string cmove> ;

I decided to stay with stack.

Analyzing version using locals, I observed I was to much attracted to
use the thoughtless way of doing, it was so easy to do it, even not
observed the opportunity to use '/string'!

Even using '/string', I like more stack version than local version:

: push { addr len delta -- } addr addr len delta /string cmove> ;


Have a nice day,
humptydumpty

[Syd Rumpo]

_Always_ include the number base in a literal (eg $49, #73 %01001001 or
similar convention). OK, maybe not 0 and 1, but why not.

Cheers
--
Syd

[HAA]

Mark Wills wrote:
> ...

> I'm with Raimond :-)
>
> I'm aware that (for some reason) there's a general dislike for local
> variables among Forthers. It's almost like it's a measure of clever
> you are: If you need locals you're not a "real" Forther.

It's a measure of how well you were taught Forth :) Some quotes from
Jeff Fox ...

"Stacks are great (for Forth) so use them. Chuck has said "Don't use locals."
You have a stack for data, this is Forth, locals are for a whole different picture."

"If it is your habit to use locals then it is likely that [you] don't understand why
locals disrupt Forth factoring, or don't care about that because C factoring
is fine with you."

> I'm all for
> writing code that I and others can understand six months or six years
> from now. That's actually quite hard to do in Forth, especially in
> the lowest levels of an application. Locals in particular help code
> be me much more readable.

This is the "I need to dumb down my code because [insert excuse here]."
argument. It does Forth no favors.

[Raimond Dragomir]

Hehe, I forgot about that. For me it is so obvious that I enforced this
rule in the interpreter. I don't have a BASE variable for numeric input.
My BASE (because I have one however) is only for numeric output formatting.
Numeric input (literals) is controlled by number prefixes.

[m...@iae.nl]

On Wednesday, July 22, 2015 at 2:39:02 AM UTC+2, Julian Fondren wrote:
> On Tuesday, July 21, 2015 at 7:28:08 PM UTC-5, Julian Fondren wrote:
> > But if you want rules, these are the best:
> > https://groups.google.com/d/msg/comp.lang.forth/BNjiUjmN2pw/SHwGuf4lqK4J
>
> From that:
>
> > These rules are not for beginners learning their Forth ABCs but might be
> > helpful to a person who has written a program and wants to make it
> > clearer.
>
> Rules for beginners would be more like:
>
> 1. Use stack comments!
> 2. Don't use locals!

It is like that joke about left and right being
age-dependent. Beginners shall zealously use
the stack, but if they still use it when they're
proficient in Forth, they should have their head
examined.

> 3. Don't write definitions longer than 3-5 lines!
> 4. Here's a list of naming conventions.
> 5. Please still try to use a human language with your names.
> 6. Don't use vocabularies.
> 7. You probably don't need that cool feature from language X.
> 8. Don't let holier-than-thou Forth programmers make you
> wear a straitjacket. After pulling your hair out for a
> while, you'll go raving mad and run off to learn Common
> Lisp or Haskell or something, and literally nobody wants
> that.

I am learning Haskell and Python right now, but after Forth,
everything is so incredibly boring.

-marcel

[Elizabeth D. Rather]

This is a good example. Complex "stackrobatics" does *not* represent
good Forth programming style, it's the sign of a newbie who hasn't made
the effort to think out problems clearly in a stack-based medium. It
takes commitment to the concept that the stack can be used simply and
effectively, plus some practice in learning how. Indeed, riding a
tricycle is easier than riding a two-wheeled bike, but the latter is
more powerful, which is why kids are willing to make the effort.

[Paul Rubin]

humptydumpty <oua...@gmail.com> writes:
> push ( addr len delta -- ;inside buffer at ADDR LEN push block of LEN-DELTA
> size from ADDR to ADDR+DELTA )
> I wanted to experiment with locals, so first definition was:

> : push { addr len delta -- } addr addr delta + len delta - cmove> ; ...

> Analyzing version using locals, I observed I was to much attracted to
> use the thoughtless way of doing, it was so easy to do it, even not
> observed the opportunity to use '/string'!

Locals are more useful when there are enough live values that it's hard
to get at them with stack operations. Classic example is multiplying
two complex numbers, x=a+bi and y=c+di, so x*y = (ac-bd) + i(ad+bc):

: z* { a b c d -- re im } a c * b d - a d * b c + ;

that can be done with stack juggling but who wants to bother?

The genius of Forth was realizing this situation doesn't occur all that
often. But it does sometimes occur. Chuck's code uses VARIABLEs rather
freely to deal with it when it arises. That means you either burn RAM
by permanently allocating a cell for each such variable even when
they're not simultaneously in use, or else you have to carefully track
which ones might overlap during nested calls. You also must handle the
possibility of such variables being used by multiple words. Better is
to use stack-like allocation for them, plus temporary names, and that
which is what locals amounts to.

[Elizabeth D. Rather]

I know that many languages and CS courses regard using VARIABLEs as
anathema, but in many years of experience I have not found that to be an
issue in Forth. Taking your concerns (which are the common ones)
individually:

* "Burning" RAM by permanently allocating a cell: As far as the
internals of something like a complex multiply, Chuck would have written
that in code, for performance, using registers. VARIABLEs are for values
that are being used in various definitions in the program. For those
variables, there are two situations: either you're on a PC, with a
gazillion megabytes that you don't need, or you're on a microcontroller
with limited RAM. In the first case, the relatively small number of
VARIABLEs your application will need is a drop in the bucket. In the
second, you need to look carefully at the RAM space your application
needs, and design your overall program to make good use of it. "Good
use" includes allocating variable for things that need to be used by
more than one definition. A program that is going to involve complex
numbers is getting them from somewhere, processing them, and then using
them somewhere. In other words, they aren't really "local" to a single
definition, but a property of the application, in which case they
deserve readable names and permanent allocations. Besides, garbage
collection is a source of degraded performance and instability, which
you can ill afford in an embedded application.

* Name space management: that's an issue of overall program design. Use
names that are meaningful in the context. Any Forth worth using will
give you an error message when you redefine a name, and LOCATE will help
you find it and resolve the conflict appropriately and quickly.

[onewing...@gmail.com]

On Wednesday, July 22, 2015 at 2:25:18 AM UTC-6, Elizabeth D. Rather wrote:
>
> Part of the problem is that many newbies are working with Forths that
> are not well-documented and from obsolete books like Starting Forth.

What books would you suggest then?
What tutorials? (Keeping in mind the desire to learn Forth, not particular implementations [unavoidable, in practice, but certainly worth minimizing.])
Are any of them for the new Forth 2012 Standard? -- http://lars.nocrew.org/forth2012/

I ask from the point of view of a programmer who hasn't *really* learned forth so much as learned about it. I like things *about* Forth, but haven't really used it (much like Lisp).

[Elizabeth D. Rather]

I have written two: The Forth Programmer's Handbook (a reference based
on Forth94) and Forth Application Techniques (a tutorial, also
Forth94-compatible). Both are available as paper copies from Amazon.
Handbook is also included electronically with all FORTH, Inc. products,
including the free evaluation versions. Both books will work fine with
the recent Forth2012, although they don't cover all the original
additions. They both also include some features that are in common usage
but not standardized, but these are clearly indicated. Application
Techniques is the text for courses I have taught for many years, and
includes many problem sets to help you with your practice.

Stephen Pelz has also written a book, available from MPE.

[hughag...@gmail.com]

On Wednesday, July 22, 2015 at 3:14:27 AM UTC-7, Mark Wills wrote:
> > > I'm convinced that most people that try Forth give
> > > up in sheer frustration. Let's face it, if C or some other
> > > "normal" language is your thing, then Forth is just plain
> > > hard. More so if you're learning it on your own.

In my FMITE document (http://www.forth.org/FMITE.txt) I have this:

Even if you are just working with single-cell data, if you have a lot of stack-juggling then the use of locals will likely result in more readable source-code (likely faster machine-code too, if you have more than three data in use). The FMITE is one of the few Forth micro-controllers that supports locals in the instruction set (we can be pretty sure that Charles Moore's processors won't support locals in this universe's lifetime) --- so use locals on the FMITE to write readable and efficient LOTD programs (LOTD source-code is not supposed to be a puzzle that has to be solved like Sudoku). On the other hand, the hallmark of recalcitrant C programmers is the over-use locals --- this will result in ugly source-code (especially if the locals have meaningless names) and inefficient machine-code (especially if a local is used only once or twice in a function) --- then they complain bitterly that Forth is ugly and inefficient, and say that they are in a hurry to get back to writing C code for mainstream processors (my response is: "Don't let the door hit you in the ass on the way out!")

The manual for ISYS Forth (for the Apple-IIc) gave us this example of good Forth style:

: par \ r1 r2 -- r \ calculate parallel resistance of two resistors
ddup + */ ;

: par3 \ r1 r2 r3 -- r \ calculate parallel resistance of three resistors
par par ;

The high-functioning C'diot may avoid stack-juggling (the DDUP in PAR above) like this:

: par local{ r1 r2 -- r } \ calculate parallel resistance of two resistors
r1 @ r2 @
r1 @ r2 @ + */ ;

: par3 local{ r1 r2 r3 -- r } \ calculate parallel resistance of three resistors
r1 @ r2 @ par
r3 @ par ;

The low-functioning C'diot will do even worse. For one thing, he may fail to understand */ because he can't translate it into C code --- so he will use * and / instead, resulting in an overflow bug. Or, he may fail to understand */ but will understand that overflow is an issue --- so he will use D* and D/ instead, resulting in abysmally slow code. Also, he may fail to understand that one of the purposes of factoring is so that sub-functions can be reused (PAR was reused in PAR3) because factoring is not considered to be a virtue in the C world. A collision of not understanding */ and not understanding reusability, would result in this:

: par local{ r1 r2 r3 -- r } \ calculate parallel resistance of two resistors (WARNING: overflow is possible!)
r1 @ r2 @ *
r1 @ r2 @ + / ;

: par3 local{ r1 r2 r3 | t1 -- r } \ calculate parallel resistance of three resistors (WARNING: overflow is possible!)
r1 @ r2 @ *
r1 @ r2 @ + / t1 !
t1 @ r3 @ *
t1 @ r3 @ + / ;

The LOTD code above appears to have been written in C first, and then translated line-by-line into LOTD; it is pretty much just an rpn-version of C. It is typical for C'diots to have a function such as PAR3 that obviously contains cut-and-paste code from another function (the PAR function just above it). It is also typical for C'diots to comment their bugs (as done above, with the comments warning that overflow is possible). Of course, the true C'diot would put a comment on every line in a vain effort at improving readability --- and then criticize the good-style version of PAR and PAR3 for not being adequately commented!

A good way to avoid stack-juggling is to use structs, and only have the pointers to the structs on the data-stack. Our LINE.LENGTH function shown earlier was an example of this. LOTD provides a heap (that is something else we can expect that Charles Moore won't provide ever), so the heap should be used. Whenever several data are used together and are only meaningful in relation to each other (like the X and Y coordinates of a point), then these data should be packed together into a struct and the struct held in the heap, and only the pointer to the struct passed around on the stack. This greatly reduces the amount of data on the stack, which increases both readability and efficiency.

[hughag...@gmail.com]

On Wednesday, July 22, 2015 at 3:14:27 AM UTC-7, Mark Wills wrote:

> I'm aware that (for some reason) there's a general dislike for local
> variables among Forthers. It's almost like it's a measure of clever
> you are: If you need locals you're not a "real" Forther. I'm all for
> writing code that I and others can understand six months or six years
> from now. That's actually quite hard to do in Forth, especially in
> the lowest levels of an application. Locals in particular help code
> be me much more readable.

When I started programming in ANS-Forth I didn't use locals for at least ten years. This wasn't due to "some reason" --- this was due to the fact that I was using SwiftForth v2 (that I paid over $400 for). In SwiftForth, (LOCAL) crashes the system whenever it is used. Also, LOCALS| in ANS-Forth has the parameters backwards.

Only when I wrote the novice package in 2009 did I write { and finally make locals work.

> I want to say something about phrases. I believe the concept of
> phrases exist in Forth, much more than other programming languages.
> I believe that very experienced Forth programmers can analyse code
> and recognise common phrases and understand what they are doing at
> an almost unconcious level, similar to an epxerienced music reader
> reading a stave. I believe Elizabeth can do this. I, alas, cannot.
> I have to read each word and conciously compute what is happening.
> I have to execute the code in my head, word by word. I believe
> Elizabeth and some of the others here (Stephen, Anton, Bernd,
> Hugh) do not. They understand it at a more unconcious, instinctual
> level. Experience really pays off in Forth.

You are making it sound more difficult than it is. Your paragraph above will scare off more novices than it will encourage. They will think: "Well, shoot! I don't have any instinctual grasp of Forth, so I should just quit." Actually, nobody does have an instinctual grasp nor intuition nor any other super-powers. You're just making this up! Everybody has to "read each word and consciously compute what is happening." You don't have to "execute the code in [the] head" though --- you can write comments after each line to help yourself keep track of what is on the stack. Here is a typical example from the novice package:

macro: exchange ( adrX adrY size -- ) \ the size of the record must be a multiple of W
begin dup while \ -- adrX adrY remaining
over @ fourth @ \ -- adrX adrY remaining Y X
fourth ! fourth ! \ -- adrX adrY remaining
rot w + rot w + rot w -
repeat
3drop ;

Your claim that Forth experts subconsciously know what code does, without reading it out, reminds me of an old Korean who was teaching me Go (Baduk in his language). He was a 4-dan and I was a 9-kyu at the time. I would play a stone then he would study it for 5 or 10 seconds and then say: "You're just guessing, aren't you?" In those days, I imagined that I had intuition as to where to play the stones. This works sometimes, but not always, and I wasn't learning anything nor progressing at all. What I primarily learned from him, is that you have to read it out every time. The difference between a dan and a kyu, is mostly that that dan doesn't guess. The difference between one dan and another dan, is primarily in strategy and fuseki, but in the tactics none of them ever guess --- they always read it out --- sometimes they misread, but they never neglect to read due to confidence in their intuition. Nowadays, what makes me feel confident in a game is to see my opponent throwing away his aji because he hasn't read out the sequence and figured out that his group is dead --- I know that he is just guessing --- verily, guessing is the road to ruin.

[Raimond Dragomir]

> I want to say something about phrases. I believe the concept of
> phrases exist in Forth, much more than other programming languages.
> I believe that very experienced Forth programmers can analyse code
> and recognise common phrases and understand what they are doing at
> an almost unconcious level, similar to an epxerienced music reader
> reading a stave. I believe Elizabeth can do this. I, alas, cannot.
> I have to read each word and conciously compute what is happening.
> I have to execute the code in my head, word by word. I believe
> Elizabeth and some of the others here (Stephen, Anton, Bernd,
> Hugh) do not. They understand it at a more unconcious, instinctual
> level. Experience really pays off in Forth.

I don't think Forth is special about this. I started the programming in Pascal.
It was hard. Then I switched to C. It was also hard. Then I discovered Forth.
Also hard.
I think programming is easier after you spend a lot of time with it.
In any language.

[Anton Ertl]

"Elizabeth D. Rather" <era...@forth.com> writes:
>I know that many languages and CS courses regard using VARIABLEs as
>anathema, but in many years of experience I have not found that to be an
>issue in Forth.

I have.

> As far as the
>internals of something like a complex multiply, Chuck would have written
>that in code, for performance, using registers.

An good example of avoiding locals by using factoring and good stack
management techniques? If we have Forth compilers where you cannot
gain performance by using machine code for such tasks (and I think we
have, at least if SIMD instructions are not available), the remaining
reason for code would be that it's easier to do it with registers than
with the stack. Is a Forth solution with locals preferable to a code
solution with registers? IMO yes.

> Besides, garbage
>collection is a source of degraded performance and instability, which
>you can ill afford in an embedded application.

Locals in Forth are not garbage collected, so why do you bring that up
in a discussion of locals in Forth?

>* Name space management: that's an issue of overall program design. Use
>names that are meaningful in the context. Any Forth worth using will
>give you an error message when you redefine a name,

No Forth system worth using gives an error message when you redefine a
name. Redefinitions are not only allowed in standard programs, the
fact that they do not produce errors, as well as the fact that old
uses still refer to the old name, and new uses refer to the new name
is a feature of Forth, and one in which it is pretty unique:
<http://www.complang.tuwien.ac.at/forth/language-features.html>

However, Forth systems usually show warnings on redefinitions.

[Stephen Pelc]

On Wed, 22 Jul 2015 15:13:03 -0700 (PDT), onewing...@gmail.com
wrote:

>What books would you suggest then?

>What tutorials? (Keeping in mind the desire to learn Forth, not particular
>implementations [unavoidable, in practice, but certainly worth minimizing.])

See:
www.mpeforth.com/books.htm

Stephen

--
Stephen Pelc, steph...@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

[WJ]

hughag...@gmail.com wrote:

> The manual for ISYS Forth (for the Apple-IIc) gave us
> this example of good Forth style:
>
> : par \ r1 r2 -- r \ calculate parallel resistance of two resistors
> ddup + */ ;
>
> : par3 \ r1 r2 r3 -- r \ calculate parallel resistance of three resistors
> par par ;
>
> The high-functioning C'diot may avoid stack-juggling
> (the DDUP in PAR above) like this:
>
> : par local{ r1 r2 -- r } \ calculate parallel resistance of two resistors
> r1 @ r2 @
> r1 @ r2 @ + */ ;
>
> : par3 local{ r1 r2 r3 -- r } \ calculate parallel resistance of three resistors
> r1 @ r2 @ par
> r3 @ par ;

Scheme:

;; Calculate parallel resistance of 2 or more resistors.
(define (par . rs)
(if (null? (cddr rs))
(/ (apply * rs) (apply + rs))
(par (car rs) (apply par (cdr rs)))))

gosh> (par 24 24)
12
gosh> (par 24 24 24)
8
gosh> (par 24 24 24 24)
6
gosh> (par 24 24 24 24 24)
24/5

--
The report card by the American Society of Civil Engineers showed the national
infrastructure a single grade above failure, a step from declining to the point
where everyday things simply stop working the way people expect them to. ---
washingtonpost.com/local/trafficandcommuting/us-infrastructure-gets-d-in-annual-report/2013/03/19/c48cb010-900b-11e2-9cfd-36d6c9b5d7ad_story.html

[glid...@gmail.com]

You will get many different answers because people are different and
have different needs and Forth is used for many different purposes.
Forth is very malleable so it easily accommodates many different styles.

You are smart to study the recommendations and styles of others and
there are some widely accepted best practices such as always include
stack comments. (Although I never include a stack comment for a
definition that doesn't consume or leave stack items. No stack comment
= no stack effect.) Thinking Forth is good read and has a good section
on style.

If you program as part of a work group then your style may be largely
dictated.

If you program alone then you are free to adopt/create your own style.

In resource constrained use the typical Forth system rewards efficient
stack use. In a resource rich environment one's style may include
the use of locals. For example I value my time and therefore the
time it takes to solve a problem and have no issue in using locals when
they help. And no, I *don't* always reach for locals first. After
awhile one realizes that one is just rearranging items on the stack, not
solving the problem at hand. Or one is spending time rearranging the
problem just so the stack comes out "nice". Again, this can distract me
from solving the problem at hand. This is a somewhat controversial
topic so I'll leave it at that.

One of the nice things about Forth is the compiler does not get in your
way via type checking and other rigid rules.

-Doug

[hughag...@gmail.com]

This code has an overflow bug.

[hughag...@gmail.com]

On Wednesday, July 22, 2015 at 1:14:38 PM UTC-7, Elizabeth D. Rather wrote:
> I know that many languages and CS courses regard using VARIABLEs as
> anathema, but in many years of experience I have not found that to be an
> issue in Forth.

You have spent your entire career at Forth Inc. denouncing general-purpose data-structures and reusable code-libraries. Here you are doing it again, hijacking a thread on Forth style.

The issue is reentrancy --- any reusable code has to be reentrant --- this is programming-101, well-known by every programmer in the world.

In my FMITE document (http://www.forth.org/FMITE.txt) I provided some quotes from you --- here are a couple that I think explain what in your background causes you to hate the concept of reusable code so much:

"Truly, I don't see the point of all this paranoia about reentrancy, particularly in systems without a multitasker. VARIABLE was *designed* for things that would be used in multiple definitions. I remember the horror of (*gasp*) global variables back in the 1960's in Fortran. But, frankly, in 30+ years of programming in Forth I never found them a problem. I think this is all about mythical dragons."

"In 1971-2 I managed a group of COBOL programmers and wrote a fair amt of COBOL myself. Yes, it was an interesting learning experience!"

[Ala'a Alawi]

Hi Mux,

Here are other notes, style and methods emphasized by the Chuck that I'd documented for myself from his writings, talks and Jeff fox site (http://www.ultratechnology.com):

- Always try to move decision on anything in your program earlier rather than later on (Runtime > Compilation > Edit time > Design time).
- Early binding rather than late binding
- Keep block/screen size to 1 KB. This is one of forth key stones as per its creator (the other two being 'words' and 'stacks')
- Avoid unsolvable problems.
- Emphasis on Thoughtful/mindful/through thinking/discipline with
patients/paying attention
- Scaling (integer scaling).
- Avoid locals.
- The following are words that Charles advertised against their usage:
- postpone
- pick
- roll
- +loop
- depth
- No more than 1-2 arguments per word.
- No more than 3-4 deep stack manipulation per word.
- Remove more than what you added.
- Definitions should be 5 to 7 words.
- No hooks (a place holder for later upgrade since you do
not know where it will be and if guessed, its is mostly in the other
direction) - (Ala'a: in other words, solve only the current problem.)

From the above: Keep it simple and stupid, and only solve what is required.

Also here is a webpage by Jeff that in which he explains Chuck problem solving method (http://www.ultratechnology.com/method.htm)

Remember: Take the above with a grain of salt. Also, corrections are welcome (with reference please, if possible)

Regards,

Ala'a

[hughag...@gmail.com]

On Wednesday, July 22, 2015 at 1:14:38 PM UTC-7, Elizabeth D. Rather wrote:

> As far as the
> internals of something like a complex multiply, Chuck would have written
> that in code, for performance, using registers.

Here we have Elizabeth Rather telling us what Chuck would do. How would she know? Is she channeling him psychically?

In all likelihood, Elizabeth Rather doesn't know what complex numbers are.

In this thread, https://groups.google.com/forum/#!topic/comp.lang.forth/BcWvGxFFuzA%5B1-25%5D
I was complaining that there is no D/ available in ANS-Forth, which I needed in my continued-fraction program. We have this exchange:
On Friday, November 20, 2009 at 12:07:12 AM UTC-7, Elizabeth D Rather wrote:
> Hugh Aguilar wrote:
> ...
> > The problem is the ANS-Forth standard. Really, how obvious was the
> > need for double-precision arithmetic? This could have been an
> > extension to the language similar to floating-point. Compiler-writers
> > working on small microprocessors could decline to implement it if they
> > didn't want to.
> >
> > I am frustrated with the ANS-Forth standard because I believe that the
> > bad design of the standard is the #1 reason for the failure of Forth
> > to become an important language. Forth was doing pretty well in the
> > 1980s, but we needed a standard. What we got was Forth-83, and then
> > ANS-Forth-94, both of which were badly designed. With some more
> > thoughtful leadership we could have succeeded.
>
> There are D+, D-, M*, M/, and M*/ (and the unsigned operators). These
> were adequate in a very wide variety of projects over a 30 year period,
> many of which were extremely computation-intensive and running on slow
> 16-bit processors.
>
> Forth's design is pragmatic: it has functions that have been needed and
> that have proven their usefulness *in Forth*, not necessarily those that
> have been required in other languages. Generally speaking, Forth has
> the most flexible set of *integer* arithmetic operators of any language.
> In particular, M*/ was one of Chuck's most brilliant innovations. I'm
> sure if Chuck were trying to do your continued fractions that is what he
> would rely on. Yes, that sometimes requires thinking differently, like
> many other things in Forth.
>
> Cheers,
> Elizabeth

This was actually my first-ever contact with Elizabeth Rather. Here she is channeling Chuck again, telling me how he would write my continued-fraction program. How would she know? Also, she is telling me that this "requires thinking differently" --- differently from what? --- in all likelihood, Elizabeth Rather doesn't know what continued-fractions are.

This reminds me of how people trying to sell a message will sometimes claim to be "channeling" a Pharaoh from ancient Egypt or a wise space-alien with a goofy name or a god worshiped by an obscure aboriginal group that none of their readers are familiar with --- always somebody who has more authority than they do but who is conveniently unavailable.

Elizabeth Rather is a total phony --- she has never written a computer program in her life --- ANS-Forth is a cult founded upon a priestess channeling an unavailable god.

Think about this: If you were a long-dead Pharaoh or a wise space-alien or Chuck Moore and you were actively trying to save humanity, why would you communicate only with one person rather than with everybody, and why would you pick an idiot?

Think about this: Maybe the gods aren't actively trying to save humanity because they don't really give a damn --- we are going to have to think for ourselves --- we are not going to progress until we stop faking it and get real.

[hughag...@gmail.com]

On Thursday, July 23, 2015 at 7:32:58 PM UTC-7, Ala'a Alawi wrote:
> - The following are words that Charles advertised against their usage:
> - postpone

Well, Charles Moore ought to hate my novice-package, as I use POSTPONE extensively.

Actually, it seems unlikely that Charles Moore advised against POSTPONE --- meta-compiling is one of Forth's best features --- if we can't write code that executes at compile-time and generates code that executes at run-time, then we might as well just program in C.

But I don't claim to have any particular insight into Charles Moore's thinking --- I just do what I want to do, and the rest will follow --- Elizabeth Rather has already said that I'm not a Forth programmer, so maybe Charles Moore will show up on comp.lang.forth one day solely for the purpose of saying that I'm not a Forth programmer (I would be quite honored to be denounced by Charles Moore himself; anybody can get denounced by the priests and sycophants as they are pretty free with their denunciations, but it takes real talent to offend the gods).

[bor...@gmail.com]

From http://www.greenarraychips.com/home/documents/greg/DB004-131030-aFUSER.pdf
[c] (Cyan text) enters words only. Not relevant for F18 code, but analogous to POSTPONE in ANS Forth when compiling x86 code.

So colorForth seems to have it too.

[hughag...@gmail.com]

If you can't have immediate words, then the only alternative is for COMPILE, to special-case all of the words that would normally be immediate (such as: IF etc.) --- but that is Stephen Pelc's idea of Forth, not Charles Moore's.

In ANS-Forth, FIND is completely screwed-up --- we have section 4.1.2 that says it is ambiguous for FIND or tick to obtain the xt of the special-case words, and section 6.1.1550 that says: "For a given string, the values returned by FIND while compiling may differ from those returned while not compiling." So, as a practical matter, the ANS-Forth programmer has no idea what FIND is going to do --- it is all ambiguous and pretty much anything is possible.

My disambiguifiers work around the ambiguity in FIND however, by using POSTPONE instead. For example:

: if state @ 0= abort" *** no interpretation semantics for: IF ***" postpone if ; immediate

Now FIND works the same way on every ANS-Forth compliant compiler, and it works in a way that makes sense (words like IF that should be immediate are immediate).

If we don't have POSTPONE then we are totally screwed! Without POSTPONE we can't have the disambiguifiers, and so we are left with the highly ambiguous FIND that works differently on every ANS-Forth compliant compiler.

I think that the ANS-Forth committee made FIND ambiguous for the purpose of preventing the ANS-Forth programmers from writing cross-compilers --- but they either forgot to make POSTPONE ambiguous or they lacked the courage to do this as it would totally prevent meta-compiling in ANS-Forth which people would notice, so they left POSTPONE as a loophole in their sabotage. Now my disambiguifiers take advantage of this loophole to work around the ambiguity and confusion that the committee worked so hard to create).

Maybe Elizabeth Rather can psychically channel Charles Moore and inform us that Charles Moore wants Forth to be ambiguous and that we must all embrace ambiguity (a kind of original sin) or be excommunicated.

[Mark Wills]

It's also utterly un-readble gibberish. I mean, lets face it, in the
vast majority of languages, you can normally get an idea of what some
piece of code is doing, even if you don't understand all of it.

And people say Forth is write only! Pah!

Respect to WJ for being able to write it, I suppose, but it's not for
me.

[franck....@gmail.com]

Le vendredi 24 juillet 2015 10:24:20 UTC+2, Mark Wills a écrit :
> It's also utterly un-readble gibberish. I mean, lets face it, in the
> vast majority of languages, you can normally get an idea of what some
> piece of code is doing, even if you don't understand all of it.
>
> And people say Forth is write only! Pah!
>
> Respect to WJ for being able to write it, I suppose, but it's not for
> me.

In Oforth :

// parn ( rl -- r ) : Calculate parallel resistance of 2 or more resistors
: parn { #[ dup2 * tor + / ] swap reduce }

[ 24, 24 ] parn .
12 ok
[ 24, 24, 24, 24 ] parn .
6 ok


If #par word is also needed, it can be created and used instead of the
quotation :

// par ( r1 r2 -- r )
: par { dup2 * tor + / }

// parn ( rl -- r )
: parn { #par swap reduce }


About #reduce, it is a high order word :

// reduce ( aWord aCollection -- x )
It just applies the word between each element of a collection to
compute something :

>#+ [ 1, 2, 3, 4, 5 ] reduce .
15 ok
(this computes : 1 2 + 3 + 4 + 5 + )

>#max [ 1, 2, 3, 8, 2 ] reduce .
8 ok

Franck

[Ala'a Alawi]

On Friday, July 24, 2015 at 8:33:51 AM UTC+4, hughag...@gmail.com wrote:
> On Thursday, July 23, 2015 at 7:32:58 PM UTC-7, Ala'a Alawi wrote:
> > - The following are words that Charles advertised against their usage:
> > - postpone
>
> Well, Charles Moore ought to hate my novice-package, as I use POSTPONE extensively.

http://www.ultratechnology.com/forth2.htm (search for postpone), but as pointed by bor...@gmail.com, colorforth do use it!

Ala'a

[Ala'a Alawi]

On Friday, July 24, 2015 at 9:09:43 AM UTC+4, bor...@gmail.com wrote:

> From http://www.greenarraychips.com/home/documents/greg/DB004-131030-aFUSER.pdf
> [c] (Cyan text) enters words only. Not relevant for F18 code, but analogous to POSTPONE in ANS Forth when compiling x86 code.
>
> So colorForth seems to have it too.

I did not check colorForth, but searching again you are correct it seems to be the Cyan words, but you can check the following page from Jeff Fox site http://www.ultratechnology.com/forth2.htm (search for postpone) and it seems that it maybe Jeff's interpretation rather than literal quote.

Thanks for the feedback.

Ala'a

[Paul Rubin]

Mark Wills <markwi...@gmail.com> writes:
> It's also utterly un-readble gibberish. I mean, lets face it, in the
> vast majority of languages, you can normally get an idea of what some
> piece of code is doing, even if you don't understand all of it.

I'd have written:

(use-modules (srfi srfi-1)) ; guile
(define (par . rs)
(reduce (lambda (x y) (/ (* x y) (+ x y))) (inf) rs))

Maybe that's not so readable either, if you're not used to functional
programming idioms, but the idea is to start with one "infinity" (inf)
ohm resistor (i.e. open circuit), then add the additional resistors in
parallel with it one by one. The Haskell equivalent to WJ's Scheme code
would be:

par [x,y] = x*y / (x+y)
par (x:xs) = p2 [x, p2 xs]

that is, you start with the formula for two resistors, and if there are
more than two, recursively take the first one and combine it with the
rest. That code crashes if there are fewer than two resistors. The
combinator-oriented version would be:

par = foldl1 (\x y -> x*y / (x+y))

which means take the 2-resistor formula and fold it over the argument
list.

[HAA]

Paul Rubin wrote:
> ...

> The genius of Forth was realizing this situation doesn't occur all that
> often. But it does sometimes occur. Chuck's code uses VARIABLEs rather
> freely to deal with it when it arises. That means you either burn RAM
> by permanently allocating a cell for each such variable even when
> they're not simultaneously in use, or else you have to carefully track
> which ones might overlap during nested calls. You also must handle the
> possibility of such variables being used by multiple words. Better is
> to use stack-like allocation for them, plus temporary names, and that
> which is what locals amounts to.

Too complicated. Use the Forth, Luke.

0 value LVAR

: word1
LVAR >R
... do stuff with LVAR ...
R> TO LVAR ;

: word2
LVAR >R
... do stuff with LVAR ...
R> TO LVAR ;

What? It lacks the eye-candy of ANS/200x locals? Fortunately my
purpose is to offer a solution to the issues raised in the post - not
promote the concept of locals in Forth which Chuck firmly rejects.

[Alex McDonald]

Well, there's BASE @ followed by BASE ! to address the problem of
"gratuitous base bashing" (which iirc is from Stephen Pelc). So it has a
history and pedigree.

What we need now is a real retro Forth conversation. I'll start with my
pet hate; >BODY ! on bodies one should never bang.

: inconstant create , does> @ ;
5 inconstant x
6 ' x >body !

[HAA]

Mark Wills wrote:
> ...

> It's also utterly un-readble gibberish. I mean, lets face it, in the
> vast majority of languages, you can normally get an idea of what some
> piece of code is doing, even if you don't understand all of it.
>
> And people say Forth is write only! Pah!

As you would know :)

> Respect to WJ for being able to write it, I suppose, but it's not for
> me.

It's a programming language's *differences* from others that makes it
fascinating and worth the effort learning. Take locals. Any number of
languages use local variables. How about a language that eliminates
them completely by design? Amazing, right? Can you imagine adding
local variables to such a language? It's a terrible idea as it diminishes
what made that language different and worth the learning.

[Bernd Paysan]

Mark Wills wrote:

> I want to say something about phrases. I believe the concept of
> phrases exist in Forth, much more than other programming languages.
> I believe that very experienced Forth programmers can analyse code
> and recognise common phrases and understand what they are doing at
> an almost unconcious level, similar to an epxerienced music reader
> reading a stave. I believe Elizabeth can do this. I, alas, cannot.
> I have to read each word and conciously compute what is happening.
> I have to execute the code in my head, word by word. I believe
> Elizabeth and some of the others here (Stephen, Anton, Bernd,
> Hugh) do not. They understand it at a more unconcious, instinctual
> level. Experience really pays off in Forth.

For my part, yes. However, for me, that did not take long to get there.
I'm talking about the few days to get sufficiently comfortable with the
stack, as Elizabeth writes. Of course, you still get better with more
experience.

If you avoid getting comfortable with the stack, you'll just never get
comfortable with the stack. One thing I did at the start of learning Forth,
and I'd recommend that for everybody: I did read others code, especially the
sources of the system I've been using at that time (VolksForth). Each word
had a stack comment and a shadow block describing what it does. There were
no locals, and the shadow block entry had to be as short as the word itself
or it wouldn't fit (usually, it was smaller).

You actually have to read others code to start really understanding a
language. If you write your own code and read it soon afterwards, you
remember your thinking behind the code, so you still don't have to
understand your code. After 6 months, you have forgotten that, and if the
code then is unreadable, it is because you never could read your code.

So by reading code from others, you'll not fall into the trap of thinking
you can read it, because you had just written it. You really have to read
it, it's not your code. And if the code has only a little small comment,
you can't avoid reading the code itself. If it has a lot of comments, you
read the comments, and actually avoid reading the code, too.

The code is in a very different language. It is much more comfortable to
skip learning that different language if you find a (lazy) way how to.

The biggest power of our brain lies in the unconscious parts. And they can
learn a lot. Push all the hard work to the unconscious parts, and do the
easy stuff conscious.

When Elizabeth talks about "riding a bicycle", I don't know how much she
actually knows about that. I like the analogy, but most people learn to
ride when they are pretty young. And then they forget that experience. I
remember very little about that, most of it involved a parking lot with not
many cars, but it was going a little downhill, and my mother pushed me to
get up to speed so I could learn riding at a speed where my bike was pretty
much stable.

I, after I bought a recumbent bike, have the experience of learning how to
ride a bicycle as adult. That's a process I remember, and as adults learn
considerably slower than prepubescent childs, I not only remember it, it
also took long enough to understand what happened (not just an afternoon as
my childhood experience took). After about 1000km, everything was fully
automated, and the bicycle at whatever speed just did what I wanted it to
do. Magically, because no conscious decision of how to turn the handlebar
was made anymore.

You want it, the bike does it, and the middleware in your brain just works.
That's how to ride a bike works. When you learn a language (regardless of
human or computer language), you should get to the same point: a
considderable part of the thinking must be automated. You don't have the
time to translate word by word into your target language, then rearrange the
words using the grammar rules, and then say them. This takes way too long.
Automate the important things, and you can speak fluently. Even with a
limited vocabulary and grammar.

For some fun how important automating things is, watch some of the late 70s
Jackie Chan movies of the "Drunken Master" epoch. It's all about learning
Kung Fu. Kung Fu is such a stunning martial art, because the practicers
learn many complicated movements by heart. That takes an awful lot of time,
and it's the reason why a master in his 50s can easily beat a much stronger
learner in his 20s (and that's someone who already learns for 10 years or
more!).

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

[Bernd Paysan]

Raimond Dragomir wrote:
> I don't think Forth is special about this. I started the programming in
> Pascal. It was hard. Then I switched to C. It was also hard. Then I
> discovered Forth. Also hard.
> I think programming is easier after you spend a lot of time with it.
> In any language.

Certainly you learn all the time. But IMHO it's not just that.

When I started to learn programming, I first just read books, without
actually trying. I did that before I actually bought a computer. It looked
all hard. Two books however didn't look hard. One was Rodnay Zak's BASIC
book ("my first BASIC program"), the other was Starting Forth. I did
realize that the level of difficulty was very different: Zak's BASIC book
was some silly simple stuff, but he's certainly an excellent teacher.
Starting Forth had some remarkable powerful examples at the end. For such a
beginner's book at least.

Pascal or C were languages which I thought were too complicated, and some
concepts were very difficult to understand (i.e.: I didn't). After learning
Forth, I reread K&R's C book. And I could actually make sense out of those
things I didn't understand before. IMHO, part of that success was that
Starting Forth teaches concepts like number representation and memory to
newbies. And to some extent it is because Forth is conceptually simpler
than other languages, and therefore more understandable if you don't mind
that it is different.

[hughag...@gmail.com]

On Saturday, August 1, 2015 at 3:22:29 PM UTC-7, Bernd Paysan wrote:
> You want it, the bike does it, and the middleware in your brain just works.
> That's how to ride a bike works. When you learn a language (regardless of
> human or computer language), you should get to the same point: a
> considderable part of the thinking must be automated. You don't have the
> time to translate word by word into your target language, then rearrange the
> words using the grammar rules, and then say them. This takes way too long.
> Automate the important things, and you can speak fluently. Even with a
> limited vocabulary and grammar.

This was my comment:

On Wednesday, July 22, 2015 at 9:48:59 PM UTC-7, hughag...@gmail.com wrote:
> Your claim that Forth experts subconsciously know what code does, without reading it out, reminds me of an old Korean who was teaching me Go (Baduk in his language). He was a 4-dan and I was a 9-kyu at the time. I would play a stone then he would study it for 5 or 10 seconds and then say: "You're just guessing, aren't you?" In those days, I imagined that I had intuition as to where to play the stones. This works sometimes, but not always, and I wasn't learning anything nor progressing at all. What I primarily learned from him, is that you have to read it out every time. The difference between a dan and a kyu, is mostly that that dan doesn't guess. The difference between one dan and another dan, is primarily in strategy and fuseki, but in the tactics none of them ever guess --- they always read it out --- sometimes they misread, but they never neglect to read due to confidence in their intuition. Nowadays, what makes me feel confident in a game is to see my opponent throwing away his aji because he hasn't read out the sequence and figured out that his group is dead --- I know that he is just guessing --- verily, guessing is the road to ruin.

So, which one of us writes code that works? Bernd Payson imagines that he can mentally automate programming so that working code just spills out of his keyboard without any conscious thought. I say that code has to be tested, and that guessing is the road to ruin. All of the code in the novice-package works --- this is because I don't guess --- in Forth programming, I am a dan.

On a related note, SwiftForth-v2 (that I paid over $400 for) would crash every time that (LOCAL) was used. It had obviously never been tested even once --- this is not a subtle bug that somehow got through testing --- there was no testing done before the product was shipped to the customer.

> For some fun how important automating things is, watch some of the late 70s
> Jackie Chan movies of the "Drunken Master" epoch. It's all about learning
> Kung Fu. Kung Fu is such a stunning martial art, because the practicers
> learn many complicated movements by heart. That takes an awful lot of time,
> and it's the reason why a master in his 50s can easily beat a much stronger
> learner in his 20s (and that's someone who already learns for 10 years or
> more!).

Okay! Bernd Payson compares himself to Kung Fu masters that he has seen in chop-socky movies from the late-1970s.

Bernd: Those movies are comedies; you are not supposed to take them seriously.

I did kick-boxing when I was younger. I can tell you with certainty that it is a bad idea to "learn many complicated movements by heart." I always refused to do katas (choreographed sequences of moves done repetitively). Katas not only don't help a guy to win, but they defeat him mentally. When he gets in the ring his mind of full of this complicated nonsense and he becomes confused, and when he sees fists flying at his face he cringes. My opinion on the subject of martial-arts is that what matters more than anything else is that the guy knows how to control his breathing --- this is not mentioned in the chop-socky movies --- but this is the truth.

[Rod Pemberton]

On Sat, 01 Aug 2015 19:41:13 -0400, <hughag...@gmail.com> wrote:

> Bernd Payson imagines that he can mentally automate programming
> so that working code just spills out of his keyboard without
> any conscious thought.

Sometimes, you do write some funny ... stuff, Hugh.
Unfortunately, it's usually in the middle of a TL;DR rant.

Sadly, I knew a guy who programmed like that. His code was the
absolute worst spaghetti code you ever saw. This wasn't because
he wasn't smart. It was because he never learned, nor applied
structured coding concepts in a disciplined manner to his code.
Doing that is a choice. It won't simply happen. It can't always
be enforced by the language.


Rod Pemberton

--
Scientists now say we'll experience a mini-ice in 2030.
So, I guess we need more global warming today ...

[Rod Pemberton]

On Wed, 22 Jul 2015 06:14:25 -0400, Mark Wills <markwi...@gmail.com> wrote:

> I want to say something about phrases. I believe the concept of
> phrases exist in Forth, much more than other programming languages.

?

Do you mean the language is more like English than algebra? ...

> I believe that very experienced Forth programmers can analyse code
> and recognise common phrases and understand what they are doing at
> an almost unconcious level, similar to an epxerienced music reader
> reading a stave. I believe Elizabeth can do this. I, alas, cannot.
> I have to read each word and conciously compute what is happening.
> I have to execute the code in my head, word by word. I believe
> Elizabeth and some of the others here (Stephen, Anton, Bernd,
> Hugh) do not. They understand it at a more unconcious, instinctual
> level. Experience really pays off in Forth.
>

Well, I've only coded my Forth system in Forth, which Ms. Rather
dismisses as mostly non-standard Forth coding. The solutions for
some of the system words are rather abstruse. It's unlikely that
I would do what they do if I ever coded a "normal" Forth application.
It'd be too cryptic or wouldn't "flow" easily or be elegant or
fast, etc. When coding in C, the C I use today is very minimal
compared to that which I used years ago. Even then, I was far
from fully using C's functionality. I.e., most of the C language
isn't really needed, especially almost all of the C library. It's
mostly decoration or work reduction for the lazy or stupid ...

So, from my perspective, programming is more like solving a jigsaw
puzzle or geometry problem or using Lego's to construct something
or playing Tetris slowly. You have a large bunch of pieces that
can be put together or used in different ways to solve your problem.
You attempt your basic solution or design in your head first to
reject sure failures, then you move to implement it in physical
reality. It doesn't have to work, at first. It's just the initial
outline of your solution. If I had never solved a Rubik's cube,
I might view Forth as frustrating as solving a Rubik's the first
time. However, having solved Rubik's cube many times (without
cheating or learning any moves from books), I know there are only
a small handful of different actual combinations. With a programming
language, there can be a nearly infinite number of solutions. So,
over time, I moved away from recommended C coding styles and techniques
and developed the code techniques which work best for me. Of course,
you need to solve a wide range of problems in different manners,
sometimes repeatedly, to decide what works and what doesn't.

[Anton Ertl]

Bernd Paysan <bernd....@gmx.de> writes:
>The biggest power of our brain lies in the unconscious parts. And they can
>learn a lot. Push all the hard work to the unconscious parts, and do the
>easy stuff conscious.
>
>When Elizabeth talks about "riding a bicycle", I don't know how much she
>actually knows about that. I like the analogy, but most people learn to
>ride when they are pretty young. And then they forget that experience. I
>remember very little about that, most of it involved a parking lot with not
>many cars, but it was going a little downhill, and my mother pushed me to
>get up to speed so I could learn riding at a speed where my bike was pretty
>much stable.
>
>I, after I bought a recumbent bike, have the experience of learning how to
>ride a bicycle as adult. That's a process I remember, and as adults learn
>considerably slower than prepubescent childs, I not only remember it, it
>also took long enough to understand what happened (not just an afternoon as
>my childhood experience took). After about 1000km, everything was fully
>automated, and the bicycle at whatever speed just did what I wanted it to
>do. Magically, because no conscious decision of how to turn the handlebar
>was made anymore.

I very much doubt that you made any conscious decision of how to turn
the handlebar in the first 1000km. The trick when riding a bicycle is
that you counteract a deviation from the desired course by turning the
handlebar in the "wrong" direction; e.g., if the bike veers left, but
you want to go straight, at first you turn the handlebar left; if the
bike goes straight, but you want to go right, at first you turn the
handlebar left.

That's normally totally subconscious, and when you consciously think
"steer to the right", your brain translates this subconsciously into
putting the appropriate forces on the handlebars, and, on upright
bicycles, to support this with appropriate upper body movements.

Learning to ride a normal recumbent (not a Flevo) is learning how to
do this with just the handlebars, and no upper body movements. I
learned this as adult and found it pretty easy. I have seen various
degrees of difficulties when other adults tried it; some could ride
easily right away, one had a really hard time. I guess it depends on
how much they do with the upper body normally, and how much with the
handlebars. Theory: people who are good at hands-free riding have a
harder time at recumbent riding.

[Elizabeth D. Rather]

On 8/1/15 9:04 PM, Rod Pemberton wrote:
> On Wed, 22 Jul 2015 06:14:25 -0400, Mark Wills <markwi...@gmail.com>
> wrote:
>
>> I want to say something about phrases. I believe the concept of
>> phrases exist in Forth, much more than other programming languages.
>
> ?
>
> Do you mean the language is more like English than algebra? ...
>
>> I believe that very experienced Forth programmers can analyse code
>> and recognise common phrases and understand what they are doing at
>> an almost unconcious level, similar to an epxerienced music reader
>> reading a stave. I believe Elizabeth can do this. I, alas, cannot.
>> I have to read each word and conciously compute what is happening.
>> I have to execute the code in my head, word by word. I believe
>> Elizabeth and some of the others here (Stephen, Anton, Bernd,
>> Hugh) do not. They understand it at a more unconcious, instinctual
>> level. Experience really pays off in Forth.
>>
>
> Well, I've only coded my Forth system in Forth, which Ms. Rather
> dismisses as mostly non-standard Forth coding. The solutions for
> some of the system words are rather abstruse. It's unlikely that
> I would do what they do if I ever coded a "normal" Forth application.
> It'd be too cryptic or wouldn't "flow" easily or be elegant or
> fast, etc.

I have no idea what this is trying to say. FORTH, Inc's Forth systems
are all coded in Forth, with the exception of key primitives which we
write using Forth assembler because they need to be fast. With the
advent of optimizing compilers, these become fewer and fewer.

> When coding in C, the C I use today is very minimal
> compared to that which I used years ago. Even then, I was far
> from fully using C's functionality. I.e., most of the C language
> isn't really needed, especially almost all of the C library. It's
> mostly decoration or work reduction for the lazy or stupid ...

I can't comment on C style :-)

> So, from my perspective, programming is more like solving a jigsaw
> puzzle or geometry problem or using Lego's to construct something
> or playing Tetris slowly. You have a large bunch of pieces that
> can be put together or used in different ways to solve your problem.
> You attempt your basic solution or design in your head first to
> reject sure failures, then you move to implement it in physical
> reality. It doesn't have to work, at first. It's just the initial
> outline of your solution. If I had never solved a Rubik's cube,
> I might view Forth as frustrating as solving a Rubik's the first
> time. However, having solved Rubik's cube many times (without
> cheating or learning any moves from books), I know there are only
> a small handful of different actual combinations. With a programming
> language, there can be a nearly infinite number of solutions. So,
> over time, I moved away from recommended C coding styles and techniques
> and developed the code techniques which work best for me. Of course,
> you need to solve a wide range of problems in different manners,
> sometimes repeatedly, to decide what works and what doesn't.

I'm sure one's coding style evolves in any language. The important thing
is to keep the objectives in mind. IMO the important objectives are
efficiency and clarity.

Cheers,
Elizabeth

--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[Bernd Paysan]

Anton Ertl wrote:
> I very much doubt that you made any conscious decision of how to turn
> the handlebar in the first 1000km. The trick when riding a bicycle is
> that you counteract a deviation from the desired course by turning the
> handlebar in the "wrong" direction; e.g., if the bike veers left, but
> you want to go straight, at first you turn the handlebar left; if the
> bike goes straight, but you want to go right, at first you turn the
> handlebar left.

Yes, I know. You are right, it's hard to to conscious. At first, for slow
speed, I sat upright to be able to use my body movement, as I was used to.
At speed, my slow, conscious operation of the bike's handlebar was fast
enough to keep it sort-of in the right direction.

> That's normally totally subconscious, and when you consciously think
> "steer to the right", your brain translates this subconsciously into
> putting the appropriate forces on the handlebars, and, on upright
> bicycles, to support this with appropriate upper body movements.
>
> Learning to ride a normal recumbent (not a Flevo) is learning how to
> do this with just the handlebars, and no upper body movements. I
> learned this as adult and found it pretty easy. I have seen various
> degrees of difficulties when other adults tried it; some could ride
> easily right away, one had a really hard time. I guess it depends on
> how much they do with the upper body normally, and how much with the
> handlebars. Theory: people who are good at hands-free riding have a
> harder time at recumbent riding.

Probably. I'm pretty good at hands-free. I suppose learning to ride a
motorcycle, where the body movement doesn't change the center of gravity
much (the motorcycle is much heavier) helps to learn to ride a recumbent.

[Rod Pemberton]

On Sun, 02 Aug 2015 09:54:05 -0400, Elizabeth D. Rather <era...@forth.com> wrote:

> On 8/1/15 9:04 PM, Rod Pemberton wrote:
>> On Wed, 22 Jul 2015 06:14:25 -0400, Mark Wills <markwi...@gmail.com>
>> wrote:

>>> I want to say something about phrases. I believe the concept of
>>> phrases exist in Forth, much more than other programming languages.
>>
>> ?
>>
>> Do you mean the language is more like English than algebra? ...
>>
>>> I believe that very experienced Forth programmers can analyse code
>>> and recognise common phrases and understand what they are doing at
>>> an almost unconcious level, similar to an epxerienced music reader
>>> reading a stave. I believe Elizabeth can do this. I, alas, cannot.
>>> I have to read each word and conciously compute what is happening.
>>> I have to execute the code in my head, word by word. I believe
>>> Elizabeth and some of the others here (Stephen, Anton, Bernd,
>>> Hugh) do not. They understand it at a more unconcious, instinctual
>>> level. Experience really pays off in Forth.
>>>
>>
>> Well, I've only coded my Forth system in Forth, which Ms. Rather
>> dismisses as mostly non-standard Forth coding. The solutions for
>> some of the system words are rather abstruse. It's unlikely that
>> I would do what they do if I ever coded a "normal" Forth application.
>> It'd be too cryptic or wouldn't "flow" easily or be elegant or
>> fast, etc.
>
> I have no idea what this is trying to say.

Clearly.

If I was coding a Forth program - which I haven't done - and not
a Forth interpreter - which I have done - then, I likely wouldn't
do some of the complicated stuff that some of the Forth system words
require when coding words for the Forth program. I.e., I would
most likely use a simpler, more fluid, easier to grasp, perhaps more
factored, method of coding for a regular Forth program. E.g., some
stack sequences for stack words or loop primitives are generated by
an optimizer and are almost indecipherable by a human. These are
shorter, faster than more readable definitions.

> FORTH, Inc's Forth systems
> are all coded in Forth, with the exception of key primitives which we
> write using Forth assembler because they need to be fast.

... as does my Forth.

[Elizabeth D. Rather]

Sorry, I still don't get what point you're trying to make. Can you give
an example? I think it's always a good idea to write high level
sequences that are short and fast. Once one is comfortable with Forth
programming (as in the recent discussion about phrases and bicycle
riding) short, simple sequences are more readable. Optimizers will
generally do a better job with simple sequences than complex ones, and
the source will be more maintainable over time.

If you would use your Forth to write some programs for practice, you'd
probably improve both your code and your ability to read others' code.

>> FORTH, Inc's Forth systems
>> are all coded in Forth, with the exception of key primitives which we
>> write using Forth assembler because they need to be fast.
>
> ... as does my Forth.