Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #40730 > unrolled thread

Forth programming style...

Back to article view | Back to comp.lang.forth

Contents

  Forth programming style... Mux <Yvo.Zoer@gmail.com> - 2015-07-21 15:40 -0700
    Re: Forth programming style... Julian Fondren <ayrnieu@gmail.com> - 2015-07-21 17:28 -0700
      Re: Forth programming style... Julian Fondren <ayrnieu@gmail.com> - 2015-07-21 17:39 -0700
        Re: Forth programming style... Mark Wills <markwills1970@gmail.com> - 2015-07-22 00:48 -0700
          Re: Forth programming style... "Elizabeth D. Rather" <erather@forth.com> - 2015-07-21 22:25 -1000
            Re: Forth programming style... onewingedshark@gmail.com - 2015-07-22 15:13 -0700
              Re: Forth programming style... "Elizabeth D. Rather" <erather@forth.com> - 2015-07-22 13:24 -1000
              Re: Forth programming style... stephen@mpeforth.com (Stephen Pelc) - 2015-07-23 08:28 +0000
          Re: Forth programming style... Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-22 02:38 -0700
            Re: Forth programming style... Mark Wills <markwills1970@gmail.com> - 2015-07-22 03:14 -0700
              Re: Forth programming style... humptydumpty <ouatubi@gmail.com> - 2015-07-22 03:45 -0700
                Re: Forth programming style... "Elizabeth D. Rather" <erather@forth.com> - 2015-07-22 08:37 -1000
                Re: Forth programming style... Paul Rubin <no.email@nospam.invalid> - 2015-07-22 12:51 -0700
                  Re: Forth programming style... "Elizabeth D. Rather" <erather@forth.com> - 2015-07-22 10:14 -1000
                    Re: Forth programming style... anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-23 06:23 +0000
                    Re: Forth programming style... hughaguilar96@gmail.com - 2015-07-23 16:59 -0700
                    Re: Forth programming style... hughaguilar96@gmail.com - 2015-07-23 20:18 -0700
                  Re: Forth programming style... "HAA" <someone@microsoft.com> - 2015-07-28 21:06 +1000
                    Re: Forth programming style... "Alex McDonald" <blog@rivadpm.com> - 2015-07-28 12:38 +0100
              Re: Forth programming style... "HAA" <someone@microsoft.com> - 2015-07-23 00:02 +1000
              Re: Forth programming style... hughaguilar96@gmail.com - 2015-07-22 21:21 -0700
                Re: Forth programming style... "WJ" <w_a_x_man@yahoo.com> - 2015-07-23 09:05 +0000
                  Re: Forth programming style... hughaguilar96@gmail.com - 2015-07-23 16:47 -0700
                    Re: Forth programming style... Mark Wills <markwills1970@gmail.com> - 2015-07-24 01:24 -0700
                      Re: Forth programming style... franck.bensusan@gmail.com - 2015-07-24 03:48 -0700
                      Re: Forth programming style... Paul Rubin <no.email@nospam.invalid> - 2015-07-24 18:15 -0700
                      Re: Forth programming style... "HAA" <someone@microsoft.com> - 2015-08-01 13:21 +1000
              Re: Forth programming style... hughaguilar96@gmail.com - 2015-07-22 21:48 -0700
              Re: Forth programming style... Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-22 22:28 -0700
                Re: Forth programming style... Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-02 00:43 +0200
              Re: Forth programming style... Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-02 00:22 +0200
                Re: Forth programming style... hughaguilar96@gmail.com - 2015-08-01 16:41 -0700
                  Re: Forth programming style... "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-08-01 22:01 -0400
                Re: Forth programming style... anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-02 05:50 +0000
                  Re: Forth programming style... Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-02 16:33 +0200
              Re: Forth programming style... "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-08-01 22:04 -0400
                Re: Forth programming style... "Elizabeth D. Rather" <erather@forth.com> - 2015-08-02 08:54 -0500
                  Re: Forth programming style... "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-08-03 04:51 -0400
                    Re: Forth programming style... "Elizabeth D. Rather" <erather@forth.com> - 2015-08-03 17:36 -0500
          Re: Forth programming style... anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-22 10:16 +0000
        Re: Forth programming style... mhx@iae.nl - 2015-07-22 10:02 -0700
      Re: Forth programming style... anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-22 10:09 +0000
    Re: Forth programming style... Syd Rumpo <usenet@nononono.co.uk> - 2015-07-22 12:16 +0100
      Re: Forth programming style... Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-22 07:59 -0700
    Re: Forth programming style... glidedog@gmail.com - 2015-07-23 04:24 -0700
    Re: Forth programming style... "Ala'a Alawi" <amalawi@gmail.com> - 2015-07-23 19:32 -0700
      Re: Forth programming style... hughaguilar96@gmail.com - 2015-07-23 21:33 -0700
        Re: Forth programming style... borota@gmail.com - 2015-07-23 22:09 -0700
          Re: Forth programming style... hughaguilar96@gmail.com - 2015-07-23 22:57 -0700
          Re: Forth programming style... "Ala'a Alawi" <amalawi@gmail.com> - 2015-07-24 09:26 -0700
        Re: Forth programming style... "Ala'a Alawi" <amalawi@gmail.com> - 2015-07-24 09:26 -0700

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#40753

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.

[toc] | [prev] | [next] | [standalone]

#40758

hughaguilar96@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

[toc] | [prev] | [next] | [standalone]

#40764

On Thursday, July 23, 2015 at 2:06:37 AM UTC-7, WJ wrote:
> hughaguilar96@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

This code has an overflow bug.

[toc] | [prev] | [next] | [standalone]

#40775

On Friday, 24 July 2015 00:47:04 UTC+1, hughag...@gmail.com  wrote:
> On Thursday, July 23, 2015 at 2:06:37 AM UTC-7, WJ wrote:
> > hughaguilar96@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
> 
> This code has an overflow bug.

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.

[toc] | [prev] | [next] | [standalone]

#40777

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

[toc] | [prev] | [next] | [standalone]

#40793

Mark Wills <markwills1970@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.

[toc] | [prev] | [next] | [standalone]

#41033

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.

[toc] | [prev] | [next] | [standalone]

#40754

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.

[toc] | [prev] | [next] | [standalone]

#40755

> 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.

[toc] | [prev] | [next] | [standalone]

#41051

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.

-- 
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/

[toc] | [prev] | [next] | [standalone]

#41049

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/

[toc] | [prev] | [next] | [standalone]

#41053

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.

[toc] | [prev] | [next] | [standalone]

#41055

On Sat, 01 Aug 2015 19:41:13 -0400, <hughaguilar96@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 ...

[toc] | [prev] | [next] | [standalone]

#41060

Bernd Paysan <bernd.paysan@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.

- 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

[toc] | [prev] | [next] | [standalone]

#41065

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.

-- 
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/

[toc] | [prev] | [next] | [standalone]

#41056

On Wed, 22 Jul 2015 06:14:25 -0400, Mark Wills <markwills1970@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.


Rod Pemberton

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

[toc] | [prev] | [next] | [standalone]

#41064

On 8/1/15 9:04 PM, Rod Pemberton wrote:
> On Wed, 22 Jul 2015 06:14:25 -0400, Mark Wills <markwills1970@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."
==================================================

[toc] | [prev] | [next] | [standalone]

#41073

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

> On 8/1/15 9:04 PM, Rod Pemberton wrote:
>> On Wed, 22 Jul 2015 06:14:25 -0400, Mark Wills <markwills1970@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.


Rod Pemberton

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

[toc] | [prev] | [next] | [standalone]

#41083

On 8/3/15 3:51 AM, Rod Pemberton wrote:
> On Sun, 02 Aug 2015 09:54:05 -0400, Elizabeth D. Rather
> <erather@forth.com> wrote:
>
>> On 8/1/15 9:04 PM, Rod Pemberton wrote:
>>> On Wed, 22 Jul 2015 06:14:25 -0400, Mark Wills <markwills1970@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.

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.

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."
==================================================

[toc] | [prev] | [next] | [standalone]

#40739

Mark Wills <markwills1970@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:-).

- 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

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.forth

csiph-web