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

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

Best teaching methodology for Forths?

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

Contents

  Best teaching methodology for Forths? Ron Aaron <rambamist@gmail.com> - 2016-03-04 07:16 +0200
    Re: Best teaching methodology for Forths? "Elizabeth D. Rather" <erather@forth.com> - 2016-03-03 23:21 -0800
      Re: Best teaching methodology for Forths? hughaguilar96@gmail.com - 2016-03-04 12:37 -0800
    Re: Best teaching methodology for Forths? november.nihal@gmail.com - 2016-03-04 03:25 -0800
      Re: Best teaching methodology for Forths? Ron Aaron <rambamist@gmail.com> - 2016-03-04 14:30 +0200
        Re: Best teaching methodology for Forths? november.nihal@gmail.com - 2016-03-04 07:36 -0800
          Re: Best teaching methodology for Forths? Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-04 19:09 +0000
          Re: Best teaching methodology for Forths? Ron Aaron <rambamist@gmail.com> - 2016-03-05 18:53 +0200
        Re: Best teaching methodology for Forths? Julian Fondren <julian.fondren@gmail.com> - 2016-03-04 11:11 -0800
          Re: Best teaching methodology for Forths? Ron Aaron <rambamist@gmail.com> - 2016-03-05 18:54 +0200
            Re: Best teaching methodology for Forths? rickman <gnuarm@gmail.com> - 2016-03-05 13:59 -0500
              Re: Best teaching methodology for Forths? Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-06 00:56 +0000
                Re: Best teaching methodology for Forths? hughaguilar96@gmail.com - 2016-03-05 17:16 -0800
                  Re: Best teaching methodology for Forths? rickman <gnuarm@gmail.com> - 2016-03-05 20:54 -0500
                    Re: Best teaching methodology for Forths? hughaguilar96@gmail.com - 2016-03-05 18:25 -0800
                      Re: Best teaching methodology for Forths? hughaguilar96@gmail.com - 2016-03-09 18:26 -0800
                        Re: Best teaching methodology for Forths? hughaguilar96@gmail.com - 2016-03-10 23:09 -0800
                          Re: Best teaching methodology for Forths? humptydumpty <ouatubi@gmail.com> - 2016-03-11 03:39 -0800
                            Re: Best teaching methodology for Forths? hughaguilar96@gmail.com - 2016-03-12 17:57 -0800
                              Re: Best teaching methodology for Forths? humptydumpty <ouatubi@gmail.com> - 2016-03-13 08:25 -0700
                                Re: Best teaching methodology for Forths? humptydumpty <ouatubi@gmail.com> - 2016-03-13 11:30 -0700
                                Re: Best teaching methodology for Forths? hughaguilar96@gmail.com - 2016-03-13 14:06 -0700
              Re: Best teaching methodology for Forths? "Elizabeth D. Rather" <erather@forth.com> - 2016-03-07 16:28 -0800
                Re: Best teaching methodology for Forths? rickman <gnuarm@gmail.com> - 2016-03-07 19:39 -0500
                  Re: Best teaching methodology for Forths? Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-08 22:13 +0000
                    Re: Best teaching methodology for Forths? Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-09 01:18 +0000
                      Re: Best teaching methodology for Forths? rickman <gnuarm@gmail.com> - 2016-03-08 20:41 -0500
                        Re: Best teaching methodology for Forths? "Elizabeth D. Rather" <erather@forth.com> - 2016-03-10 22:33 -0800
                          Re: Best teaching methodology for Forths? hughaguilar96@gmail.com - 2016-03-10 23:17 -0800
                          Re: Best teaching methodology for Forths? hughaguilar96@gmail.com - 2016-03-13 14:41 -0700
                            Re: Best teaching methodology for Forths? Julian Fondren <julian.fondren@gmail.com> - 2016-03-13 17:26 -0700
                              Re: Best teaching methodology for Forths? "Elizabeth D. Rather" <erather@forth.com> - 2016-03-13 21:46 -1000
                                Re: Best teaching methodology for Forths? hughaguilar96@gmail.com - 2016-03-14 08:12 -0700
                                Re: Best teaching methodology for Forths? Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-14 17:45 +0000
                                  Re: Best teaching methodology for Forths? "Elizabeth D. Rather" <erather@forth.com> - 2016-03-14 14:11 -1000
                                    Re: Best teaching methodology for Forths? hughaguilar96@gmail.com - 2016-03-15 01:13 -0700
                              Re: Best teaching methodology for Forths? hughaguilar96@gmail.com - 2016-03-14 08:55 -0700
                                Re: Best teaching methodology for Forths? Julian Fondren <ayrnieu@gmail.com> - 2016-03-15 03:16 -0700
                              Re: Best teaching methodology for Forths? hughaguilar96@gmail.com - 2016-03-16 16:13 -0700
                            Re: Best teaching methodology for Forths? "WJ" <w_a_x_man@yahoo.com> - 2016-03-26 22:11 +0000
                            Re: Best teaching methodology for Forths? "WJ" <w_a_x_man@yahoo.com> - 2016-03-26 22:15 +0000
    Re: Best teaching methodology for Forths? rickman <gnuarm@gmail.com> - 2016-03-04 12:42 -0500
      Re: Best teaching methodology for Forths? Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-04 19:16 +0000
        Re: Best teaching methodology for Forths? rickman <gnuarm@gmail.com> - 2016-03-04 15:22 -0500
        Re: Best teaching methodology for Forths? Ron Aaron <rambamist@gmail.com> - 2016-03-05 18:58 +0200
          Re: Best teaching methodology for Forths? "HAA" <someone@microsoft.com> - 2016-03-09 10:07 +1100
    Re: Best teaching methodology for Forths? IanYellowley <iany99@gmail.com> - 2016-03-04 13:57 -0800
      Re: Best teaching methodology for Forths? hughaguilar96@gmail.com - 2016-03-04 15:07 -0800
        Re: Best teaching methodology for Forths? stephen@mpeforth.com (Stephen Pelc) - 2016-03-05 11:22 +0000
          Re: Best teaching methodology for Forths? hughaguilar96@gmail.com - 2016-03-05 15:10 -0800
            Re: Best teaching methodology for Forths? Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-06 00:05 +0000
              Re: Best teaching methodology for Forths? hughaguilar96@gmail.com - 2016-03-05 17:06 -0800
              Re: Best teaching methodology for Forths? rickman <gnuarm@gmail.com> - 2016-03-05 20:58 -0500
              Re: Best teaching methodology for Forths? hughaguilar96@gmail.com - 2016-03-14 11:10 -0700
          Re: Best teaching methodology for Forths? hughaguilar96@gmail.com - 2016-03-05 15:23 -0800
            Re: Best teaching methodology for Forths? stephen@mpeforth.com (Stephen Pelc) - 2016-03-06 09:28 +0000
              Re: Best teaching methodology for Forths? hughaguilar96@gmail.com - 2016-03-06 13:45 -0800
      Re: Best teaching methodology for Forths? Ron Aaron <rambamist@gmail.com> - 2016-03-05 18:59 +0200
    Re: Best teaching methodology for Forths? Whammo <sidciavic@gmail.com> - 2016-03-08 19:47 -0800
    Re: Best teaching methodology for Forths? Brad Eckert <hwfwguy@gmail.com> - 2016-03-23 16:19 -0700
      Re: Best teaching methodology for Forths? Ron Aaron <rambamist@gmail.com> - 2016-03-24 07:29 +0200
      Re: Best teaching methodology for Forths? Richard Owlett <rowlett@cloud85.net> - 2016-03-24 04:44 -0500
      Re: Best teaching methodology for Forths? Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-24 12:47 +0000
        Re: Best teaching methodology for Forths? Paul Rubin <no.email@nospam.invalid> - 2016-03-24 10:19 -0700
          Re: Best teaching methodology for Forths? Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-25 00:54 +0000
            Re: Best teaching methodology for Forths? Paul Rubin <no.email@nospam.invalid> - 2016-03-24 19:24 -0700
              Re: Best teaching methodology for Forths? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-25 11:38 +0000
                Re: Best teaching methodology for Forths? Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-25 12:42 +0000
                  Re: Best teaching methodology for Forths? Doug Hoffman <glidedog@gmail.com> - 2016-03-25 09:07 -0400
                  Re: Best teaching methodology for Forths? Julian Fondren <julian.fondren@gmail.com> - 2016-03-25 07:54 -0700
                  Re: Best teaching methodology for Forths? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-25 14:29 +0000
                  Re: Best teaching methodology for Forths? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-03-25 21:17 +0000
                    Re: Best teaching methodology for Forths? Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-26 00:43 +0000
                      Re: Best teaching methodology for Forths? Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-26 12:06 +0000

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

#46222

hughaguilar96@gmail.com wrote:

> I've been programming in Forth for 30 years, and DO loops still trip me up

ANS Forth was designed to make things easy for the microprocessor
and for the implementor of the language.

It was not designed to make things easy for the user of the language.

The only conceivable place for this language is in a tiny
embedded controller.

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

#45830

On 3/4/2016 12:16 AM, Ron Aaron wrote:
> I've noticed that among the 8th user-base, there are some who "get it"
> immediately and within a week are writing real programs.  There are
> others who, even after months, are barely able to write a functioning
> program.
>
> The first group consists not only of former Forthers, but also of
> complete novices.  The second group seems to have far more long-term
> C/Java users.
>
> My question: what is the best way to teach people with disparate
> backgrounds how to program effectively in a Forth-type language?
>
> This is not an academic question: our distributor in India will be
> giving workshops, and we want to help the students there get comfortable
> and effective as quickly as possible.
>
> Thanks for any constructive suggestions!

What is so different about 8th that a "Forther" would have trouble 
learning it?   Or are you saying the "Forthers" aren't really able to 
write a functioning program to begin with?

-- 

Rick

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

#45837

Am Fri, 04 Mar 2016 12:42:48 -0500 schrieb rickman:

> On 3/4/2016 12:16 AM, Ron Aaron wrote:
>> I've noticed that among the 8th user-base, there are some who "get it"
>> immediately and within a week are writing real programs.  There are
>> others who, even after months, are barely able to write a functioning
>> program.
>>
>> The first group consists not only of former Forthers, but also of
>> complete novices.
[...]
> What is so different about 8th that a "Forther" would have trouble
> learning it?   Or are you saying the "Forthers" aren't really able to
> write a functioning program to begin with?

He said that Forthers are productive within a week, as well as complete 
novices.  It's the C/Java camp which have difficulties.  Of course, Forth 
and Forth-like programming languages are quite different from C/Java.  
That not only includes coding habits, but also the approach to verify 
programs.  C/Java programmers rely on debuggers and test programs instead 
of interactively trying one short function after the other.

8th is IMHO conceptually closer related to Factor than Forth, but this 
apparently isn't a big problem for Forthers.  As 8th is a dynamic typed 
functional programming language, novices probably can be more productive 
with it than with Forth, where you need to know more about bits and bytes 
to become productive.

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

#45839

On 3/4/2016 2:16 PM, Bernd Paysan wrote:
> Am Fri, 04 Mar 2016 12:42:48 -0500 schrieb rickman:
>
>> On 3/4/2016 12:16 AM, Ron Aaron wrote:
>>> I've noticed that among the 8th user-base, there are some who "get it"
>>> immediately and within a week are writing real programs.  There are
>>> others who, even after months, are barely able to write a functioning
>>> program.
>>>
>>> The first group consists not only of former Forthers, but also of
>>> complete novices.
> [...]
>> What is so different about 8th that a "Forther" would have trouble
>> learning it?   Or are you saying the "Forthers" aren't really able to
>> write a functioning program to begin with?
>
> He said that Forthers are productive within a week, as well as complete
> novices.  It's the C/Java camp which have difficulties.

Yes, I didn't read that correctly.

-- 

Rick

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

#45858

On 04/03/2016 21:16, Bernd Paysan wrote:

> 8th is IMHO conceptually closer related to Factor than Forth, but this 
> apparently isn't a big problem for Forthers.  

Yep.  I haven't had any Forthers find 8th difficult, though there have
been complaints about the lack of "create... does>' (which I've
partially fixed in the last release).


> As 8th is a dynamic typed 
> functional programming language, novices probably can be more productive 
> with it than with Forth, where you need to know more about bits and bytes 
> to become productive.

I think so, that's pretty much why it's been done the way it was done.
You don't have to create an array or a map, etc. - they're already
there.  So you can concentrate on the problem you want to solved, rather
than on building first the infrastructure to solve it.

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

#45943

Ron Aaron wrote:
> On 04/03/2016 21:16, Bernd Paysan wrote:
>
> > 8th is IMHO conceptually closer related to Factor than Forth, but this
> > apparently isn't a big problem for Forthers.
>
> Yep.  I haven't had any Forthers find 8th difficult, though there have
> been complaints about the lack of "create... does>' (which I've
> partially fixed in the last release).

This was one of the complaints about ColorForth IIRC.  The difficulty
with Forth-like languages is that forthers will always look at them in
terms of Forth - instead of what they're intended to be.  In short, you
need to attract a new audience which can be difficult when it comes
to stack-based languages.

As regards teaching I think most of it up to the student and how
willing they are to persist with it.  That was my experience with Forth.
What kept me going was the positive propaganda surrounding Forth.

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

#45842

On Thursday, 3 March 2016 21:17:01 UTC-8, Ron Aaron  wrote:
> I've noticed that among the 8th user-base, there are some who "get it"
> immediately and within a week are writing real programs.  There are
> others who, even after months, are barely able to write a functioning
> program.
> 
> The first group consists not only of former Forthers, but also of
> complete novices.  The second group seems to have far more long-term
> C/Java users.
> 
> My question: what is the best way to teach people with disparate
> backgrounds how to program effectively in a Forth-type language?
> 
> This is not an academic question: our distributor in India will be
> giving workshops, and we want to help the students there get comfortable
> and effective as quickly as possible.
> 
> Thanks for any constructive suggestions!

FORTH is ideal to use/teach in a design based  environment.  If one is interested in first  looking at specific, small, low level functionality, testing, then combining and building upwards, the language lends itself so well that people will accept the "differences". I used this approach in building a simple 3 axis interpolator for CNC systems during a CAD/CAM course.  I gave only a one hour intro to FORTH and explained why it was suited to purpose first...There were no complaints.

It seems that FORTH will have problems in many of the more conventional environments where the "design approach" is missing and the large hammer, top down, approach is in vogue.

I remember many years ago our University Department moving from MathCad to Matlab as a standard student support tool. I was quite happy to simulate things that were already designed using Matlab but actually designing was very different and more cumbersome...even if one were designing control systems!!

So my vote would be for clearly formulated real world problems with an initial emphasis on factoring...

Ian

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

#45843

On Friday, March 4, 2016 at 2:57:33 PM UTC-7, IanYellowley wrote:
> It seems that FORTH will have problems in many of the more conventional environments...

If Forth has problems in conventional environments, that is bad news for Forth --- somewhat like an automobile that has problems with flat dry asphalt surfaces.

I agree that Forth is primarily oriented toward micro-controller programming --- similar to how a jeep is primarily oriented toward off-road driving --- but I see no reason why Forth has to fail so badly at easy stuff such as text processing.

I had this thread:
https://groups.google.com/forum/#!topic/comp.lang.forth/CYR7FhjYMkg
Here I introduce string-stack.4th which has the goal of bringing ANS-Forth up to the level of QBASIC in regard to text-processing. So far, no response. Elizabeth Rather says that we aren't allowed to consider strings to be a data-type, but we are required to have the adr and cnt on the data-stack so that we can work with them individually. Stephen Pelc says: "For practical applications, all Forth standards to date have been inadequate for commercial level string handling." Oh nooooooo! A Forth-200x committee member says that Forth can't be used for "practical applications" involving "commercial level string handling" --- this is despite the fact that QBASIC was widely used for just that --- in the 1990s there were abundant job offerings for QBASIC programmers, but zilch for Forth programmers.

Nobody wants to respond to that thread because Elizabeth Rather and Stephen Pelc have made their weighty judgments and determined that the Forth community can never get past PAD as the foundation of string-handling. If anybody expresses interest in string-stack.4th they will offend Elizabeth Rather and Stephen Pelc as well as all of the other Forth-200x committee members (all of whom were appointed to the committee by Elizabeth Rather) --- the committee will make another weighty judgment and say that the person is not a Forth programmer at all --- just like they did with me.

I don't think that Stephen Pelc is as dumb as he appears to be --- he is just playing dumb --- MPE makes money from "joint projects" with Forth Inc., meaning that Elizabeth Rather sells jobs based on the "Forth Inc." name that implies Forth expertise but then she out-sources the programming to Pelc because Forth Inc. only employees sales-people but doesn't have any programmers capable of writing even the simplest software. Because of this, Pelc has to ape Elizabeth Rather's idiocy, even when he actually knows better, because contradicting Elizabeth Rather on comp.lang.forth would undermine her "leading expert" status which she relies on for selling jobs, and Pelc relies on her to sell jobs because otherwise he would have to do his own marketing (programmers don't like to do marketing because it is distasteful work).

Ultimately, comp.lang.forth is all about selling Forth Inc. --- anybody who believes that comp.lang.forth is here to help the common Forth programmer is delusional --- people like me are just seen as competition.

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

#45853

On Fri, 4 Mar 2016 15:07:29 -0800 (PST), hughaguilar96@gmail.com
wrote:

> Stephen Pelc says: "For practical applications, all Forth standards to
> date have been inadequate for commercial level string handling."

Yes, I said that

> Oh nooooooo! A Forth-200x committee member says=
> that Forth can't be used for "practical applications" involving "commercia=
>l level string handling"

No, I did not say that. The solution in Forth, as you well know, is to
expand the base Forth system to have a commercial-level string
handling package. That's what several of our clients have done.

>I don't think that Stephen Pelc is as dumb as he appears to be --- he is ju=
>st playing dumb --- MPE makes money from "joint projects" with Forth Inc"

Your knowledge of the Europay OTA project is just wrong, so please 
refrain from broadcasting ignorant rubbish about it. Similarly, your
comments about Forth-200x just display your ignorance.

Stephen

-- 
Stephen Pelc, stephenXXX@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

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

#45862

On Saturday, March 5, 2016 at 4:22:03 AM UTC-7, Stephen Pelc wrote:
> On Fri, 4 Mar 2016 15:07:29 -0800 (PST), hughaguilar96@gmail.com
> wrote:
> 
> > Stephen Pelc says: "For practical applications, all Forth standards to
> > date have been inadequate for commercial level string handling."
> 
> Yes, I said that
> 
> > Oh nooooooo! A Forth-200x committee member says=
> > that Forth can't be used for "practical applications" involving "commercia=
> >l level string handling"
> 
> No, I did not say that. The solution in Forth, as you well know, is to
> expand the base Forth system to have a commercial-level string
> handling package. That's what several of our clients have done.

I think that you want the ANS-Forth standard to be crippled. This is because VFX provides the fixes, but without source-code. The purpose of this is so your claim to be ANS-Forth compliant lures customers in, but then their software quickly becomes dependent upon VFX-specific code, so they are in vendor lock-in and can't migrate to any other ANS-Forth compiler. This trick only works well when ANS-Forth is crippled.

A good example of this is HIDE and REVEAL (and SMUDGE which was in Forth-83 but toggled the smudge-bit which was rather confusing) --- you know that HIDE is necessary (my cross-compiler relies on it) so you provide it --- but you are very happy that it isn't in the ANS-Forth standard so your customers who use it can't migrate to any other ANS-Forth system. 

Similarly, you want ANS-Forth (and Forth-200x as well) to be crippled in regard to text-processing. You do provide a few simple functions (UPPER STR= ISTR= and ICOMPARE) but you don't provide source-code (doesn't matter to me because I wrote all of those myself for my string-stack.4th). Also, you say: "For practical applications, all Forth standards to date have been inadequate for commercial level string handling." This implies to the reader that text processing can't be done (by them) in ANS-Forth. Now you say that several of your clients have commercial-level string-handling. This means that you wrote it for them and you got paid to do so, so you aren't going to provide it to the street ANS-Forth programmer unless they pay you also. Once again, this trick only works well when ANS-Forth is crippled.

The irony here is that my string-stack.4th that I give away for free is more efficient than your (ahem!) "commercial-level" string-handling code. I don't even have to look at your code to know that my code is more efficient --- I just know that my code is more efficient because I was thinking when I wrote it --- I have tricks that make code efficient.

> >I don't think that Stephen Pelc is as dumb as he appears to be --- he is ju=
> >st playing dumb --- MPE makes money from "joint projects" with Forth Inc"
> 
> Your knowledge of the Europay OTA project is just wrong, so please 
> refrain from broadcasting ignorant rubbish about it. Similarly, your
> comments about Forth-200x just display your ignorance.

Well, according to Elizabeth Rather, it was "joint projects" (plural). Anyway, whether it was one project of many, this is still a violation of the rule that every company has one vote on the Forth-200x committee. You make money from Forth Inc. so you are beholden to Forth Inc.. Similarly, Peter Knaggs is your employee (http://mpeforth.com/about.htm) but is also a committee member. I'm not familiar with all of those names on the committee, but I suspect that every committee member is an employee of Forth Inc. either directly or indirectly.

I have said that every Forth-200x committee member is appointed to their position by Elizabeth Rather. You have said that I am displaying my ignorance. So, why don't you explain exactly how Forth-200x committee members get on the committee??? Inquiring minds want to know!

The whole Forth-200x Standard reeks of astro-turfing to me. The term "astro-turfing" means a purely corporate project that is represented as being a grass-roots effort (the Tea Party being a typical example in politics).

Anton Ertl wrote the code for {: and when I pointed out that it had a bug (the local after the | were not initialized to zero, but were initialized to whatever happened to be in memory), Anton replied that this is not a bug because he wrote the code according to spec and the spec didn't require that these locals be initialized to the same thing every time (only common-sense requires that). So where did this "spec" come from? Obviously, it came from Leon Wagner. Also, why wasn't the name { which has almost 30 years of common usage? The reason is that SwiftForth uses { for multi-line comments and so { couldn't be used for local declarations, despite the fact that everybody in the Forth world other than Forth Inc. for 30 years has been using { for local declarations. That really makes it obvious who is the boss of Forth-200x!

Bernd Paysan wrote the code for the fake quotations, and he described this as his "assignment" (he really used this word). Obviously, Leon Wagner assigned this to him. Then he had Alex McDonald write the RfD. This is astro-turfing --- he doesn't want to write the RfD himself because then it will be obvious that all this stuff comes from the committee --- he wants a plebian to write the RfD so that it looks like a grass-roots effort coming from the common users. 

Bernd Paysan's quotations are utterly worthless! He knew perfectly well that the quotation needed to have access to the parent function's local variables, but he refused to provide this fundamental functionality. I think that he wants everybody to say that his quotations are worthless. This is so he can reply: "Well, of course quotations are worthless, but that just proves that we should have followed Elizabeth Rather's advice and not implemented quotations! Instead we listened to Hugh who said that we should have quotations, and now we have utterly worthless quotations in Forth-200x that nobody will ever use." Of course, he is dodging the fact that I have quotations in Stundurd Forth that do have access to the parent function's locals and are useful --- the entire language is centered around the use of quotations, so if they are not useful then the entire language is not useful either.

Forth-200x represents itself as being a grass-roots effort of the entire Forth community --- all of the Forth-200x committee members were appointed by Elizabeth Rather and all of them are representing Forth Inc. --- the Forth-200x committee consider Forth community people such as myself to be competition to Forth Inc. and hence their enemy.

ANS-Forth is seriously crippled! Every time that I wrote code in ANS-Forth, such as this string-stack.4th, I run into problems with the standard that I have to work around. ANS-Forth is really the worst programming-language standard in the history of programming. This is Elizabeth Rather's fault! After such a gross failure as that, why would anybody have any respect for her at all??? She is not a programmer. She really knows nothing about programming. ANS-Forth was a marketing gimmick designed to convince the world that Forth Inc. sets the standard for Forth. This was a coup! ANS-Forth is what killed Forth --- I remember a time prior to ANS-Forth when Forth was still taken seriously --- after ANS-Forth nobody took Forth seriously and it was just considered to be a joke.

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

#45865

Am Sat, 05 Mar 2016 15:10:03 -0800 schrieb hughaguilar96:

> Bernd Paysan wrote the code for the fake quotations, and he described
> this as his "assignment" (he really used this word). Obviously, Leon
> Wagner assigned this to him. Then he had Alex McDonald write the RfD.
> This is astro-turfing --- he doesn't want to write the RfD himself
> because then it will be obvious that all this stuff comes from the
> committee --- he wants a plebian to write the RfD so that it looks like
> a grass-roots effort coming from the common users.

No, we volunteer to take over tasks.  Most of the discussion about 
quotations has been collected and organized by Stephen Pelc already, and 
Alex McDonald took that and created the RfD.  As a volunteer I don't 
complain when somebody else actually does the work that I volunteered 
for, even though my footer clearly says that I expect suboptimal results 
from delegating work.

IMHO you should stop ranting about this mediocre design-by-committee-
standard, and proceed with your straightForth standard, which certainly 
is not a fake grass-root movement, but a real one-man heterosexual hero 
show.

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

#45869

On Saturday, March 5, 2016 at 5:08:44 PM UTC-7, Bernd Paysan wrote:
> Am Sat, 05 Mar 2016 15:10:03 -0800 schrieb hughaguilar96:
> 
> > Bernd Paysan wrote the code for the fake quotations, and he described
> > this as his "assignment" (he really used this word). Obviously, Leon
> > Wagner assigned this to him. Then he had Alex McDonald write the RfD.
> > This is astro-turfing --- he doesn't want to write the RfD himself
> > because then it will be obvious that all this stuff comes from the
> > committee --- he wants a plebian to write the RfD so that it looks like
> > a grass-roots effort coming from the common users.
> 
> No, we volunteer to take over tasks.  Most of the discussion about 
> quotations has been collected and organized by Stephen Pelc already, and 
> Alex McDonald took that and created the RfD.  

You said this:
On Saturday, August 1, 2015 at 4:19:12 PM UTC-7, Bernd Paysan wrote: 
> And I have no problem if somebody else does my job.  After all, I actually 
> was assigned to do the quotation RfD.

Now you describe this as volunteering:

> As a volunteer I don't 
> complain when somebody else actually does the work that I volunteered 
> for, even though my footer clearly says that I expect suboptimal results 
> from delegating work.

Well, you certainly do get sub-optimal results when delegating to Alex McDonald! LOL That's hilarious! And, btw, where is Alex McDonald now? Isn't it true that he was such an embarrassment that you told him he would no longer be allowed to write the RfDs for your work, and so he got mad and left?

Here is a sample:
On Tuesday, August 4, 2015 at 3:05:55 AM UTC-7, Alex McDonald wrote:
> RfD: Quotations
> ...
> There has been some discussion about providing higher-order or
> embedded functions that are able to refer to their parent's locals
> during their execution. This is a middle ground between the proposal
> here and full closures that (almost always) require garbage
> collection, and it would permit execution of the quotation in the
> execution scope of the parent; in the BAR example above, if the
> quotation was executed prior to the return of BAR to its caller.
> 
> There are two schools of thought.
> 
> 1. Define [: ;] such that a standard program may not access
>    local variables of the outer definition inside the quotation.
> 
> 2. Permit such a feature, but restrict valid execution of the
>    quotation to the lifetime of the parent's execution.
> 
> Solution 2 requires some form of locals frame, and may be excessively
> complex to implement; it appears to have few advantages over
> the simpler quotations as proposed here.

The bottom line here is that nobody on the Forth-200x committee knows how to implement quotations that have access to the parent function's locals. You guys just aren't any good at programming!

And here is some more from Alex McDonald's RfD:
> The following notes on quotations and closures incorporate material
> from several people, including Anton Ertl, Andrew Haley, Marcel
> Hendrix, Ward Mcfarland, Bernd Paysan, and Elizabeth Rather. If you
> have been left out and want acknowledgement, please let me know.
> 
> Additional contributors; Hugh Aguilar and Gerry Jackson.

I threatened to sue for libel if Forth-200x used my name. Whether my name is still there or not, I don't know, as the RfD is hanging in limbo now that Alex McDonald has disappeared --- Bernd Paysan is looking for another plebian to take over the RfD because he still doesn't want his own name associated with it --- but nobody is volunteering because they don't want their name associated with it either --- who is such a gross brown-noser that he would be willing to take the blame for your screw-up?

Alex McDonald listed Elizabeth Rather as a primary contributor to prove to the readers that he already has permission and that his RfD will be a slam-dunk for him, so there is no point in complaining.

In my Stundurd Forth document I list some quotations from Elizabeth Rather that really show what her contribution to quotations is:

Elizabeth Rather quote #3:  
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!

Elizabeth Rather quote #4:  
I hate locals :-)

Elizabeth Rather quote #5:  
I'd actually be grateful for a simple English explanation of what "quotations" are, as I've heard the term used in various ways in this context [general purpose data-structures], and have never seen an explanation that isn't along the lines of, "Well, this is how {whatever} does it..."

Elizabeth Rather quote #6:  
Does "*every* application" you write use exactly the same kind of data arranged in the same way? If so, having written it once you can reuse it often. If not, you either have to rearrange your data to make it work or modify your "general purpose" structure.

And yet more from Alex McDonald's RfD:
> [Note 1]
> The phrase "ambiguous condition" has a specific meaning in Forth
> standards. An ambiguous condition is "a circumstance for which this
> standard does not prescribe a specific behavior". The RfD process
> also states: "If you want to leave something open to the system
> implementor, make that explicit, e.g., by making it an ambiguous
> condition."

Are you guys aware that a programming-language standard is supposed to standardize the programming language?

> IMHO you should stop ranting about this mediocre design-by-committee-
> standard, and proceed with your straightForth standard, which certainly 
> is not a fake grass-root movement, but a real one-man heterosexual hero 
> show.

John Passaniti disappeared a long time ago, but you continue to play the homo card (accusing me of being homophobic, which is the one argument that you are guaranteed to win against me). This would work a lot better if you found another homo to be your attack poodle.

Alex McDonald was your attack poodle after John Passaniti left. He would say things to me like: 
"You have a serious misunderstanding of pointers work."
"You really don't know how CREATE DOES> works."
etc. etc.

You rewarded Alex McDonald for his loyalty to Forth-200x by allowing him to put his name on the quotations RfD, but then he disappeared before he got his slam-dunk and the RfD was approved.

Now you don't have an attack poodle anymore. Don't worry though! One of the Forth-200x mailing-list brown-nosers will volunteer pretty soon --- being an attack-poodle is a big step up from being a common brown-noser.

> Bernd Paysan
> "If you want it done right, you have to do it yourself"

You should change your tag to say: 
"If you screw it up completely, you have to get somebody else to take the blame." 

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

#45875

On 3/5/2016 7:05 PM, Bernd Paysan wrote:
> Am Sat, 05 Mar 2016 15:10:03 -0800 schrieb hughaguilar96:
>
>> Bernd Paysan wrote the code for the fake quotations, and he described
>> this as his "assignment" (he really used this word). Obviously, Leon
>> Wagner assigned this to him. Then he had Alex McDonald write the RfD.
>> This is astro-turfing --- he doesn't want to write the RfD himself
>> because then it will be obvious that all this stuff comes from the
>> committee --- he wants a plebian to write the RfD so that it looks like
>> a grass-roots effort coming from the common users.
>
> No, we volunteer to take over tasks.  Most of the discussion about
> quotations has been collected and organized by Stephen Pelc already, and
> Alex McDonald took that and created the RfD.  As a volunteer I don't
> complain when somebody else actually does the work that I volunteered
> for, even though my footer clearly says that I expect suboptimal results
> from delegating work.
>
> IMHO you should stop ranting about this mediocre design-by-committee-
> standard, and proceed with your straightForth standard, which certainly
> is not a fake grass-root movement, but a real one-man heterosexual hero
> show.

Clearly, Hugh is on a tear.  Why bother to reply to him when you know it 
will have no impact other than to prompt additional vehement, vitriolic 
replies?

-- 

Rick

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

#46061

On Saturday, March 5, 2016 at 5:08:44 PM UTC-7, Bernd Paysan wrote:
> IMHO you should stop ranting about this mediocre design-by-committee-
> standard, and proceed with your straightForth standard, which certainly 
> is not a fake grass-root movement, but a real one-man heterosexual hero 
> show.

Well, I did design Stundurd Forth --- the name Stundurd is supposed to emphasize the fact that it is not Standard Forth --- afaik, the entire point of the Forth-200x Standard is that it gives the Forth-200x committee members the high-ground in any argument, because they (you) can denounce everything else as being non-standard without bothering to look at it.

Here is an excerpt from my Stundurd.txt file (notice that I'm using quotations, which Forth-200x lacks):


Here is an ANS-Forth function for printing numbers upwards:

: up.  \ limit base --                          \ assumes LIMIT is above BASE
    ?do  I .  loop ;

In Stundurd Forth, use this:

: up.  \ limit base --                          \ assumes LIMIT is above BASE
    tuck -  { dup .  1+ }  |iterate drop ;

Here is an ANS-Forth function that is like UP. but goes downwards (using ?DO with a negative step is very non-intuitive):

: down.  \ limit base --                        \ assumes LIMIT is below BASE
    swap 1+  swap ?do  I .  -1 +loop ;

In Stundurd Forth, DOWN. would be similar to UP. except that our count is negated and our increment is negative (hopefully this will seem intuitive to the reader):

: down.  \ limit base --                        \ assumes LIMIT is below BASE
    tuck - negate  { dup .  1- }  |iterate drop ;

We could have a function THROUGH. ( limit base -- ) that goes either up or down:

: design  \ val -- |val| sign                   
\ converts VAL into an absolute value, and provides SIGN as either -1 or 1 representing sign of original VAL
    dup 0< if  negate  -1  exit then
    1 ;

: through.  \ limit base --                     
\ if LIMIT is above BASE iterate up, otherwise iterate down
    tuck -                                      \ -- base count             
    design -rot                                 \ -- step base count        
    { dup .  over + }  |iterate 2drop ;

The reader may be wondering what happens if LIMIT equals BASE (causing VAL to be zero). It may seem that DESIGN should return zero when VAL is zero, rather than one. This isn't necessary. |ITERATE and ITERATE are similar to ?DO in ANS-Forth in that they exit prior to its loop if LIMIT equals BASE, so the step value (provided by DESIGN) for use in the quotation is never used because the quotation is never executed. |EACH and |ITERATE both exit prior to the loop they are given a zero (a null pointer for |EACH or a zero count for |ITERATE), and they never execute the quotation in this case.

The advantage of the Stundurd idiom is that all of the complicated iteration code gets hidden away inside of the higher-order function. The application programmer doesn't have to deal with this stuff, which is a good thing because iteration is a common source of bugs. The application programmer's job is much easier if he just has to write the quotation and give it to a higher-order function. Another advantage is that the application program is more compact. Higher-order functions such as |EACH or |ITERATE may get used dozens of times in an application program. If every loop were written explicitly with BEGIN WHILE REPEAT, this would result in quite bloated code. If every loop is written with a quotation and a call to a higher-order function, this results in pretty compact code. The Stundurd only has 32KB of program-memory, so the instruction set is designed to make it easy to write compact code.

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

#45864

On Saturday, March 5, 2016 at 4:22:03 AM UTC-7, Stephen Pelc wrote:
> Similarly, your
> comments about Forth-200x just display your ignorance.

And, btw, why don't you put my disambiguifiers in VFX?

ANS-Forth was sabotaged to prevent the users from writing an outer-interpreter, which was done to prevent the users from writing cross-compilers (I wrote MFX in UR/Forth which was Forth-83). My disambiguifiers work around this sabotage.

Do you want people to be able to write cross-compilers in VFX or not?

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

#45884

On Sat, 5 Mar 2016 15:23:02 -0800 (PST), hughaguilar96@gmail.com
wrote:

>Do you want people to be able to write cross-compilers in VFX or not?

The MPE cross compilers have been hosted on whatever Forth has been
current at MPE. The current one is VFX Forth.

Stephen


-- 
Stephen Pelc, stephenXXX@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

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

#45901

On Sunday, March 6, 2016 at 2:28:48 AM UTC-7, Stephen Pelc wrote:
> On Sat, 5 Mar 2016 15:23:02 -0800 (PST), hughaguilar96@gmail.com
> wrote:
> 
> >Do you want people to be able to write cross-compilers in VFX or not?
> 
> The MPE cross compilers have been hosted on whatever Forth has been
> current at MPE. The current one is VFX Forth.

I should have asked this:
"Do you want people to be able to write cross-compilers in ANS-Forth or not?"

ANS-Forth was sabotaged to prevent the user from writing an outer-interpreter. Section (4.1.2), "Ambiguous Conditions," lists one of the ambiguous conditions as: "attempting to obtain the execution token, (e.g., with 6.1.0070 ', 6.1.1550 FIND, etc.) of a definition with undefined interpretation semantics." This means that words like IF etc. can't be ticked or given to FIND. My disambiguifiers fix this problem. This was discussed here:
https://groups.google.com/forum/#!searchin/comp.lang.forth/bug$20vfx/comp.lang.forth/oXXQAGDKP7w/iMLU1ExXOAIJ

If I can't write an outer-interpreter, then I can use the built-in outer-interpreter. The problem here is that ANS-Forth once again has been sabotaged to prevent number compilation from being revectored.

I can actually write a cross-compiler in VFX easily enough. If I do however, then I have vendor lock-in because I'm using VFX-specific code. I mentioned HIDE earlier as some VFX-specific code that I require. A word like HIDE is trivial to implement given carnal knowledge, but it is impossible to be written in ANS-Forth. So why was this word not put in ANS-Forth? Obviously, this was purposeful sabotage of the ANS-Forth standard!

My point here is that ANS-Forth was purposely crippled to prevent the common users from writing certain kinds of software, especially cross-compilers. This was done for the purpose of forcing the users to pay for this software from the compiler-vendors.

I don't begrudge you making money. Everybody has to make money. I do think that you are the worst possible person to be on the Forth-200x committee however, because you are strongly motivated to cripple the standard in order to prevent competition. This is my opinion --- Elizabeth Rather obviously thinks that you are the best possible person to be on the Forth-200x committee --- this is why she appointed you to the committee (everybody appointed to the committee is strongly motivated to cripple the standard to prevent competition from people like me).

You sell VFX on the basis that it is ANS-Forth compliant. The implication is that code written on VFX can be ported to other ANS-Forth systems. This is not true however. ANS-Forth has been crippled so that only the most trivial software can be written in ANS-Forth, but any "commercial-level" software will necessarily be specific to a particular vendor.

Also, btw, I don't believe that you really know how to write a cross-compiler. You have stated that it is necessary to simulate the target processor at compile-time. This is not true. Either you don't know how to write a cross-compiler, or you were obfuscating the subject for the purpose of confusing people who were trying to figure out how cross-compilation works.  This was in this thread:
https://groups.google.com/forum/#!searchin/comp.lang.forth/lc53/comp.lang.forth/wP5nw1ClzsM/E-TV9v2y9RoJ

On Tuesday, December 8, 2009 at 3:18:13 PM UTC-7, Stephen Pelc wrote:
> On Tue, 8 Dec 2009 14:32:02 -0500, Jonah Thomas <jethomas5@gmail.com>
> wrote:
> 
> >Suppose you extended the cross-compiler so that the TARGET could be the
> >HOST . Then you'd have a clear distinction between COMPILER words and
> >regular words, but the distinction between HOST and TARGET would have
> >disappeared.
> 
> There are three types of compilation involved
> 1) Host compilation
> 2) Clone compilation (target CPU same as host and memory matches)
> 3) Cross compilation (target CPU is not host CPU)
> 
> In the third case you have to simulate *everything* when dealing
> with both the definition and execution of defining words. It's not
> easy. You also have to extend the normal Forth compiler by at least
> two time frames. Forth cross compilers are much more complicated
> and much more subtle than they appear to be.

Way back in the early 1980s there were "cross-compilers" that simulated everything on the host machine. Typically these were for a 6502. The compiler ran too slowly on the 1 Mhz. 6502 machine, so a simulator for the 6502 was written for a faster computer such as the 8 Mhz. MC68000. The 6502 compiler was then run under the simulator and it was faster than on the native hardware. Apparently this is what you are doing now --- this is not really cross-compilation however.

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

#45859

On 04/03/2016 23:57, IanYellowley wrote:

> So my vote would be for clearly formulated real world problems with an initial emphasis on factoring...

I think this is in fact what my partners will be steering towards.  They
do low-level electronics sorts of things.  So writing an app to flash an
LED at a certain frequency (or the like) and then building up from there
may be how they would like to proceed.

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

#45946

On Thursday, March 3, 2016 at 9:17:01 PM UTC-8, Ron Aaron wrote:

> 
> My question: what is the best way to teach people with disparate
> backgrounds how to program effectively in a Forth-type language?

 I believe my greatest obstacle to learning forth was it's utter simplicity.
Like assembly language, my brain wanted to believe there was more to it.
 I had to understand that each word or instruction does very little and complexity builds from very little. 

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

#46170

On Thursday, March 3, 2016 at 10:17:01 PM UTC-7, Ron Aaron wrote:
> My question: what is the best way to teach people with disparate
> backgrounds how to program effectively in a Forth-type language?
> 

Change the perception of what a programming language is and what it should do. Forth is a language for building languages. You should end up with a Forth-flavored language that fits the application domain.

The lexicon of words you build is there to:
1. Minimize information entropy, Shannon's famous H.
2. Debug the programmer.
3. Debug the program.

Experienced programmers have to develop new habits. Not only should you keep functions to less than a page, you should keep them to between 7 and 15 words. This isn't a strict rule, but it has been shown to work well. It goes well with:

A. Keep it simple.

B. Test as you go. This is the best way to debug the programmer, since programmers are notoriously buggy.

C. Crash early and crash often. Like B, but with the humility to actively look for flaws in your reasoning (by getting your hands dirty) instead of assuming you've already thought of the best approach and coded it with minimal bugs.

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

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

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

csiph-web