On Monday, March 7, 2022 at 3:05:49 PM UTC+1, the.bee...@gmail.com wrote:
> On Monday, March 7, 2022 at 3:18:10 AM UTC+1, Paul Rubin wrote:
> > Hans Bezemer <the.bee...@gmail.com> writes:
[..]
Some delightful quotes (although designed to be offensive to a certain
kind of people).
[..]
>> The competent programmer is fully aware of the strictly limited size
>> of his own skull; therefore he approaches the programming task in
>> *full humility*, and among other things he avoids clever tricks like
>> the plague".

Dijkstra's skull was considerably bigger than ours, so it didn't apply
to him.

-marcel

On Monday, March 7, 2022 at 11:51:01 AM UTC+1, minf...@arcor.de wrote:
> .. because I am not intelligent enough or just too lazy to do much stack juggling without errors.
So what your basically saying is you either have a character flaw or serious mental limitations,
but is can all be blamed to Forth.

Hans Bezemer

On 8/03/2022 03:00, Marcel Hendrix wrote:
> On Monday, March 7, 2022 at 3:05:49 PM UTC+1, the.bee...@gmail.com wrote:
>> On Monday, March 7, 2022 at 3:18:10 AM UTC+1, Paul Rubin wrote:
>> > Hans Bezemer <the.bee...@gmail.com> writes:
> [..]
> Some delightful quotes (although designed to be offensive to a certain
> kind of people).
> [..]
>>> The competent programmer is fully aware of the strictly limited size
>>> of his own skull; therefore he approaches the programming task in
>>> *full humility*, and among other things he avoids clever tricks like
>>> the plague".
>
> Dijkstra's skull was considerably bigger than ours, so it didn't apply
> to him.

Perhaps it was but programming is our problem to solve - not Dijkstra's
(nor Moore's, nor 200x). Whether the latter can help is arguable,
testimonials aside. The computing industry is no different to others
that cultivate dependency by supplying an endless stream of product and
infomercials. It now appears there's a language or variant to suit any
taste and lack of skill.

the.bee...@gmail.com schrieb am Montag, 7. März 2022 um 17:57:04 UTC+1:
> On Monday, March 7, 2022 at 11:51:01 AM UTC+1, minf...@arcor.de wrote:
> > .. because I am not intelligent enough or just too lazy to do much stack juggling without errors.
> So what your basically saying is you either have a character flaw or serious mental limitations,
> but is can all be blamed to Forth.
>
My wife says I have quite a number of character flaws. :o)

On Tuesday, March 8, 2022 at 8:39:38 AM UTC+1, minf...@arcor.de wrote:
> My wife says I have quite a number of character flaws. :o)
So does mine! Does that mean we men are all the same or women are all the same? ;-)
My wife's favorite one is: "You don't understand anything!"

As if I were to know that a single nod means I have to to rearrange all items on the table in a very
specific way so she can place two cups on the table where there's already enough space
available to allocate them..

Hans Bezemer

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> ... you get a turnkey image xxx.fi that calls FOO without invoking the
> text interpreter, and FOO does not call the text interpreter, either.

Aha, I see what you mean, the stuff in the quotation gets turned into
runnable code at compilation time, even in the more general situation
where you want to concatenate some strings at runtime.

> I think the text interpreter is an asset of Forth

Sure, but it's non-useful in disconnected targets; and these days,
separating it from the address interpreter (by putting it on a remote
machine) often seems like a better factoring.

Paul Rubin schrieb am Montag, 14. März 2022 um 11:08:02 UTC+1:
> an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> > ... you get a turnkey image xxx.fi that calls FOO without invoking the
> > text interpreter, and FOO does not call the text interpreter, either.
>
> Aha, I see what you mean, the stuff in the quotation gets turned into
> runnable code at compilation time, even in the more general situation
> where you want to concatenate some strings at runtime.
>
>
> > I think the text interpreter is an asset of Forth
>
> Sure, but it's non-useful in disconnected targets; and these days,
> separating it from the address interpreter (by putting it on a remote
> machine) often seems like a better factoring.

In the olden days we often left a text interpreter on board to serve as
remotely controllabe monitor/debugger, even when it was never used
and cost some precious bytes.

"minf...@arcor.de" <minforth@arcor.de> writes:
> In the olden days we often left a text interpreter on board to serve as
> remotely controllabe monitor/debugger, even when it was never used
> and cost some precious bytes.

Sure, back then the i/o device was usually an actual serial terminal
with no computation capability of its own. Now everyone uses a computer
running a terminal emulator. So you might as well put the text
interpreter on the remote computer instead of in the target. The target
would retain the ability to read and execute binary code from the port,
sort of like what the GA144 processors have, or Frank Sergeant's
venerable 3 instruction Forth.

Paul Rubin schrieb am Montag, 14. März 2022 um 18:32:54 UTC+1:
> "minf...@arcor.de" <minf...@arcor.de> writes:
> > In the olden days we often left a text interpreter on board to serve as
> > remotely controllabe monitor/debugger, even when it was never used
> > and cost some precious bytes.
> Sure, back then the i/o device was usually an actual serial terminal
> with no computation capability of its own. Now everyone uses a computer
> running a terminal emulator. So you might as well put the text
> interpreter on the remote computer instead of in the target. The target
> would retain the ability to read and execute binary code from the port,
> sort of like what the GA144 processors have, or Frank Sergeant's
> venerable 3 instruction Forth.

We used analog modem links to plants around the globe.

"minf...@arcor.de" <minforth@arcor.de> writes:
> We used analog modem links to plants around the globe.

That's just a bump in the wire, not really changing much, though I guess
it would have limited bandwidth (300 bps?) enough to have the resident
interpreter possibly help.

On 14/03/2022 21:33, minf...@arcor.de wrote:
> Paul Rubin schrieb am Montag, 14. März 2022 um 11:08:02 UTC+1:
>> an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> > ... you get a turnkey image xxx.fi that calls FOO without invoking the
>> > text interpreter, and FOO does not call the text interpreter, either.
>>
>> Aha, I see what you mean, the stuff in the quotation gets turned into
>> runnable code at compilation time, even in the more general situation
>> where you want to concatenate some strings at runtime.
>>
>>
>> > I think the text interpreter is an asset of Forth
>>
>> Sure, but it's non-useful in disconnected targets; and these days,
>> separating it from the address interpreter (by putting it on a remote
>> machine) often seems like a better factoring.
>
> In the olden days we often left a text interpreter on board to serve as
> remotely controllabe monitor/debugger, even when it was never used
> and cost some precious bytes.

AFAIK SwiftX has the option to install an interpreter. At the same
time it also has a stripper that recursively removes unused definitions
precisely because every byte (or word) of flash continues to be precious.
When debug is desirable, does it need to be a full-blown Forth - or
would something simpler suffice?