On 10/09/2023 10:04 pm, Zbig wrote:
> http://yosefk.com/blog/my-history-with-forth-stack-machines.html

What caught my eye was his description of Moore in action and his
conclusion:

"This is Forth. Seriously. Forth is _not_ the language."

> What caught my eye was his description of Moore in action and his
> conclusion:
>
> "This is Forth. Seriously. Forth is _not_ the language."

To be precise: the descriptions are quotes from Jeff Fox' articles.

Zbig schrieb am Montag, 11. September 2023 um 09:31:02 UTC+2:
> > What caught my eye was his description of Moore in action and his
> > conclusion:
> >
> > "This is Forth. Seriously. Forth is _not_ the language."
> To be precise: the descriptions are quotes from Jeff Fox' articles.

I wouldn't overrate it. Every Forther knows that Forth is more a programming tool
than a language. Shape the tool until it fits nicely into your problem domain.
That's why there are so virtually unlimited Forth "dialects" around.

From this perspective ANS Forth would be a tool for hardware control
with or without character terminals, or for scripting. But well done.

On 11/09/2023 5:30 pm, Zbig wrote:
>> What caught my eye was his description of Moore in action and his
>> conclusion:
>>
>> "This is Forth. Seriously. Forth is _not_ the language."
>
> To be precise: the descriptions are quotes from Jeff Fox' articles.

The comment was the blogger's. His source may have been second-hand
but even after factoring in reporter bias and spin, none of Fox'
statements attributed to Moore struck me as being 'beyond belief'.
I feel more uncomfortable when folks tell me Forth is too complicated
and in need of help which only they can provide.

> >> What caught my eye was his description of Moore in action and his
> >> conclusion:
> >>
> >> "This is Forth. Seriously. Forth is _not_ the language."
> >
> > To be precise: the descriptions are quotes from Jeff Fox' articles.
> The comment was the blogger's. His source may have been second-hand
> but even after factoring in reporter bias and spin, none of Fox'
> statements attributed to Moore struck me as being 'beyond belief'.

In most cases he's quoting Jeff each time when talking about Moore:
„Here's what Jeff Fox, a prominent member of the Forth community who've
worked with Chuck Moore for years, has to say…" (quote), or „One reason
not to use locals is that Chuck Moore hates them:” (and then quote),
„In his chip design tools, Chuck Moore naturally did not use the standard
equations:” (followed by another quote from Jeff's page) etc.

But yes, I agree, his personal words also can be found, like e.g. „Chuck Moore
constantly tweaks the language and largely dismisses the ANS standard as
rooted in the past and bloated.”

> I feel more uncomfortable when folks tell me Forth is too complicated
> and in need of help which only they can provide.

My guess is Forth offers to many… too much freedom! Most people like to
have some constrains, they feel more comfortable having some signposts.

For example: ARM assembly allows for one's own „configuration” of the
CPU to one's liking, I mean there's complete freedom which register shall
be used for which purpose. Guess what? They immediately invented ABI,
stating that „R13 should be used for stack pointer, R15 for program counter”
etc. It's all described in details and even already implemented in (dis)assemblers
and debuggers — that purely „conventional” layout.

Forth probably is perceived as „anarchic”.

On 13/09/2023 12:00 am, Zbig wrote:
>>>> What caught my eye was his description of Moore in action and his
>>>> conclusion:
>>>>
>>>> "This is Forth. Seriously. Forth is _not_ the language."
>>>
>>> To be precise: the descriptions are quotes from Jeff Fox' articles.
>> The comment was the blogger's. His source may have been second-hand
>> but even after factoring in reporter bias and spin, none of Fox'
>> statements attributed to Moore struck me as being 'beyond belief'.
>
> In most cases he's quoting Jeff each time when talking about Moore:
> „Here's what Jeff Fox, a prominent member of the Forth community who've
> worked with Chuck Moore for years, has to say…" (quote), or „One reason
> not to use locals is that Chuck Moore hates them:” (and then quote),
> „In his chip design tools, Chuck Moore naturally did not use the standard
> equations:” (followed by another quote from Jeff's page) etc.
>
> But yes, I agree, his personal words also can be found, like e.g. „Chuck Moore
> constantly tweaks the language and largely dismisses the ANS standard as
> rooted in the past and bloated.”
>
>> I feel more uncomfortable when folks tell me Forth is too complicated
>> and in need of help which only they can provide.
>
> My guess is Forth offers to many… too much freedom! Most people like to
> have some constrains, they feel more comfortable having some signposts.

Is Forth a matter of acceptance? Moore could have been Forth's authority but
he seems to have rejected the role.

"I am not in the business of promoting Forth. I am not promoting what I am
doing here. I am just reporting it."

> For example: ARM assembly allows for one's own „configuration” of the
> CPU to one's liking, I mean there's complete freedom which register shall
> be used for which purpose. Guess what? They immediately invented ABI,
> stating that „R13 should be used for stack pointer, R15 for program counter”
> etc. It's all described in details and even already implemented in (dis)assemblers
> and debuggers — that purely „conventional” layout.
>
> Forth probably is perceived as „anarchic”.

I can imagine. Moore offers no safe haven in which one can become complacent
- a tradition that goes back to Diogenes. Is Forth a philosophy? Moore asked
the question in his first widely reported speech. If it is, he appears to have
stayed the course and ignored the signposts.

On 13/09/2023 7:10 pm, Zbig wrote:
> ...
> That „particular way” in programming area took the form of Forth programming
> language but note, that the more general rules can be applied to variety of domains,
> it's not limited to programming.

'Don't make things more complicated than they need to be' is a good rule.
Ask people what they need and one will get as many answers. So it's not
a particularly easy rule to apply.

On Friday, September 15, 2023 at 5:35:40 AM UTC+2, dxf wrote:
> On 13/09/2023 7:10 pm, Zbig wrote:
> 'Don't make things more complicated than they need to be' is a good rule.

The problem is, once the customer has what h/she wants, the next question
will be for an upgrade that re-introduces all the stuff that was dropped
previously, and maybe even more.

-marcel

In article <47fe1287-b286-43ea-8954-dfb94af70f64n@googlegroups.com>,
Marcel Hendrix <mhx@iae.nl> wrote:
>On Friday, September 15, 2023 at 5:35:40 AM UTC+2, dxf wrote:
>> On 13/09/2023 7:10 pm, Zbig wrote:
>> 'Don't make things more complicated than they need to be' is a good rule.
>
>The problem is, once the customer has what h/she wants, the next question
>will be for an upgrade that re-introduces all the stuff that was dropped
>previously, and maybe even more.

More like: using a working program customers finally understand what
he really wants.
>
>-marcel

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

On Friday, September 15, 2023 at 11:23:42 AM UTC+2, none albert wrote:
> In article <47fe1287-b286-43ea...@googlegroups.com>,
> Marcel Hendrix <m...@iae.nl> wrote:
> >The problem is, once the customer has what h/she wants, the next question
> >will be for an upgrade that re-introduces all the stuff that was dropped
> >previously, and maybe even more.
> More like: using a working program customers finally understand what
> he really wants.
[..]
Very astute observation. But there is always another iteration. Some start
from scratch, some glue on a few extra naughty bits.

-marcel

On 15/09/2023 2:51 pm, Marcel Hendrix wrote:
> On Friday, September 15, 2023 at 5:35:40 AM UTC+2, dxf wrote:
>> On 13/09/2023 7:10 pm, Zbig wrote:
>> 'Don't make things more complicated than they need to be' is a good rule.
>
> The problem is, once the customer has what h/she wants, the next question
> will be for an upgrade that re-introduces all the stuff that was dropped
> previously, and maybe even more.
'The customer made me do it' doesn't look good on a CV.

On 15/09/2023 7:23 pm, albert wrote:
> In article <47fe1287-b286-43ea-8954-dfb94af70f64n@googlegroups.com>,
> Marcel Hendrix <mhx@iae.nl> wrote:
>> On Friday, September 15, 2023 at 5:35:40 AM UTC+2, dxf wrote:
>>> On 13/09/2023 7:10 pm, Zbig wrote:
>>> 'Don't make things more complicated than they need to be' is a good rule.
>>
>> The problem is, once the customer has what h/she wants, the next question
>> will be for an upgrade that re-introduces all the stuff that was dropped
>> previously, and maybe even more.
>
> More like: using a working program customers finally understand what
> he really wants.

If it were that easy there wouldn't exist a hundred languages. Just as
customers are looking for an easy fix, so too are programmers. Much of
what we do is influenced by the current fashion - perhaps all that we do.