середа, 2 січня 2019 р. о 11:30:24 UTC [email protected]d пише:

Paul Rubin <[email protected]d> wrote:

[email protected] (Anton Ertl) writes:

We're in an era where ram in kilobyte amounts costs almost nothing.
Or on even smaller parts, I think it's hard for Forth to compete resource-wise with C, because of the memory used by Forth's stacks,

I know there are some C compilers that statically allocate everything
based on whole-program analysis, but I don't know of any that are
effective on tiny MCUs that are too small for Forth. Apart from
anything else, if you're constrained for code space you'll want to use something like byte-token-threading, and that's easy in Forth.

the higher inconvenience of using bytes instead of wider cells,
program space used by the interpreter and extraneous Forth word definitions, etc. Maybe there are Forth compilers that can target
an 8-bit MCU with 0.5k of program flash and 32 bytes of ram, but
(like C) they will be external compilers that don't bring much interactivity to the target app either.

Interactivity on very small devices has been a solved problem in Forth
for some 30 years, ever since talker PROMs and then chipFORTH. 0.5k of program space is tight, though. For Forth, especially if you want multi-tasking, I think that a reasonable minimum is 128-256 bytes of
RAM and 4k program space.

Once you're at the level of an industrial device (not battery
powered) you might as well use an embedded Linux board (starting at
the 5 dollar Raspberry Pi Zero) and then have basically unlimited resources and software options.

Not necessarily. If you have a very small MCU that is controlling
something, you're quite likely to be at the sharp end of real
time.

Andrew.

You got me interested. I am new to programming and have not learned all the languages yet. I'm just learning how to create and manage databases. This source https://www.programmingassignment.net/services/dbms-assignment-help/ helps me a lot to solve
difficulties in this direction Programming is not such a simple science as I thought, there are many nuances here and you need to spend time to figure it all out.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

One of the most interesting things about Forth is the lack of collaboration with in a community to excel and promote the language, while I see lots of individual efforts, lots of great intentions, it’s this lack of collaboration that creates greater
fragmentation and in the end and a deterrent reason for new uptake in the language IMO.

From an embedded perspective, I firmly believe that FORTH really does have something that should greatly appeal commercial application, provided it is wrapped into a set of tools that enable commercialization and collaboration with in a community. IMHO
the is is so much wasted effort into trying to build “ my forth is better than your’s “ with the right intent, yet this does not serve the community to capture new adoption of users or commercial applications.
Forth has so much to offer, and yes, doing interactive programing is a great thing, but provided the way most (i’ll use traditional forthers here as to not not hurt anyone as I still have my Franklin 1000 for 84 where I started programing just to prove
that it’s not age related ) traditional forthers, where they are building a great deal of tools into a little MCU intended to placed in it’s single uprose function once deployed, it does not add lot’s of value to have editors or complex tools other
than the development fase. Provided a Forth (i’ll use IDE here explain a concept ) IDE with in a Forth where you could have a single Forth, a target compiler, tools to have the interactiveness of been on the HW *tethered to the target IMHO would
probably be the best solution.

In this view of Forth on a PC *IDE and a tethered system would allow the efforts of the Fort community to focus on building target compilers for each of the platforms they wish to incorporate. Once this happens, it would allow the community and in
interest of newcomers to extend the (tools as a collection of vocabulary to help and build the IDE experience ) tools need to help in development of the applications. One of these tools for example would be having the capacity to see the register values
as the applications executes, again in a idealized tethered forth, you are executing the extended vocabulary to get the output needed and presenting it on the IDE.

Ideally, this would allow for more repeatability of cross platform compiling the forth code, and it should attract new users that would extend the platform provided collaboration along with commercial backing in a open source effort.

Call me an idealist, but once you are there, the community can further consider how to extend the tethered functionality, like wireless, OTA updates, etc.

Well, that is a thought, and many can choose their own path and that is perfectly fine as we don’t hold the ultimate truth… * i certainly do not * but if anyone is truly interested in helping drive FORTH’s adoption, I hope this could be, not a
blueprint of what to consider, but more of a seed of where to lead the discussion.

Forth has a very strong potential to, IMHO, reevaluate how programing is learned for embedded systems, it would give users a better understanding of the underlining HW, it would allow for more efficient programs, great opportunity to build commercial
solutions while still gaining the hobbyist’s interest along with the interactiveness and the DSL capabilities of forth naturally has to offer.

Moving to a stack based programing does take effort and application for the programmer, it has taken me about two to three months to really begin to understand the return stack and how to best use it to grasp some of the more advanced ways of
implementing forth to solve problems. It’s a fun language once you start, but the fragmentation and the lack of repeatability is the hardest barrier to grasp some of these concepts IMO, specially from those that learn by reading the code, testing it,
the making changes to experiment with the reinforcement of expected outcomes *repeatability of the code*.

FWIW, food for thought.

Jose.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday, 6 November 2022 at 12:12:48 UTC, [email protected] wrote:

One of the most interesting things about Forth is the lack of collaboration with in a community to excel and promote the language, while I see lots of individual efforts, lots of great intentions, it’s this lack of collaboration that creates greater

fragmentation and in the end and a deterrent reason for new uptake in the language IMO.

From an embedded perspective, I firmly believe that FORTH really does have something that should greatly appeal commercial application, provided it is wrapped into a set of tools that enable commercialization and collaboration with in a community. IMHO

the is is so much wasted effort into trying to build “ my forth is better than your’s “ with the right intent, yet this does not serve the community to capture new adoption of users or commercial applications.

Forth has so much to offer, and yes, doing interactive programing is a great thing, but provided the way most (i’ll use traditional forthers here as to not not hurt anyone as I still have my Franklin 1000 for 84 where I started programing just to

prove that it’s not age related ) traditional forthers, where they are building a great deal of tools into a little MCU intended to placed in it’s single uprose function once deployed, it does not add lot’s of value to have editors or complex tools
other than the development fase. Provided a Forth (i’ll use IDE here explain a concept ) IDE with in a Forth where you could have a single Forth, a target compiler, tools to have the interactiveness of been on the HW *tethered to the target IMHO would
probably be the best solution.

In this view of Forth on a PC *IDE and a tethered system would allow the efforts of the Fort community to focus on building target compilers for each of the platforms they wish to incorporate. Once this happens, it would allow the community and in

interest of newcomers to extend the (tools as a collection of vocabulary to help and build the IDE experience ) tools need to help in development of the applications. One of these tools for example would be having the capacity to see the register values
as the applications executes, again in a idealized tethered forth, you are executing the extended vocabulary to get the output needed and presenting it on the IDE.

Ideally, this would allow for more repeatability of cross platform compiling the forth code, and it should attract new users that would extend the platform provided collaboration along with commercial backing in a open source effort.

Call me an idealist, but once you are there, the community can further consider how to extend the tethered functionality, like wireless, OTA updates, etc.

Well, that is a thought, and many can choose their own path and that is perfectly fine as we don’t hold the ultimate truth… * i certainly do not * but if anyone is truly interested in helping drive FORTH’s adoption, I hope this could be, not a

blueprint of what to consider, but more of a seed of where to lead the discussion.

Forth has a very strong potential to, IMHO, reevaluate how programing is learned for embedded systems, it would give users a better understanding of the underlining HW, it would allow for more efficient programs, great opportunity to build commercial

solutions while still gaining the hobbyist’s interest along with the interactiveness and the DSL capabilities of forth naturally has to offer.

Moving to a stack based programing does take effort and application for the programmer, it has taken me about two to three months to really begin to understand the return stack and how to best use it to grasp some of the more advanced ways of

implementing forth to solve problems. It’s a fun language once you start, but the fragmentation and the lack of repeatability is the hardest barrier to grasp some of these concepts IMO, specially from those that learn by reading the code, testing it,
the making changes to experiment with the reinforcement of expected outcomes *repeatability of the code*.

FWIW, food for thought.

Jose.

Thank you very much for your post.
It summarizes many aspects I have experienced over the years.
I think it is in many ways the mindset of forthers.
I can do better if I write my own Forth ...

I sometimes wonder, if there are more Forth variants
than there are applications using a standard Forth.

In other languages it is very often the IDE that stops people to mess with the language,
as it will mostly not work than with the IDE that is accepted by many.
And which they use to show off their applications .

One example is the Arduino IDE.
How good or bad it is, I cannot judge, but ask google for applications using it and compare that with the same search regarding Forth applications.

I have just started to play around with Python for fun and as there is a little project.
Thonny IDE I stumbled over, and start using it with the RPI Pico.
THERE IS NO FORTH IDE REALLY THAT I HAVE SEEN TO SUPPORT SIMILAR ASPECTS.
WHY NOT AFTER MORE THAN 50 YEARS ????
OK VFX has something.

Getting started with Forth?
When I started doing some consultancy work for MPE,
I realized how little is there for beginners,
or easily accessible.
And I put myself in this group,
I started a fun project to publish material
together with the people who generated the material.

Now there is my Forth Bookshelf on amazon, containing about 20 Forth books,
as ebook or as print book.
And people still seem to be interested
- 10 years of re-writing, checking, formatting and publishing work.
A lot more work and communication than I had expected, but still fun. https://www.amazon.co.uk/Juergen-Pintaske/e/B00N8HVEZM%3Fref=dbs_a_mng_rwt_scns_share
It forced me to play with some of them.

The ones I enjoyed most is the FORTH LITE TUTORIAL,
going through many Forth Words, trying to understan, write and try examples on my PC
https://www.amazon.co.uk/gp/product/1717970672/ref=dbs_a_def_rwt_bibl_vppi_i24

and the eFORTH AS ARDUINO SKETCH https://www.amazon.co.uk/gp/product/1717970672/ref=dbs_a_def_rwt_bibl_vppi_i24 where I later generated the "39 steps" to get started for absolute beginners https://wiki.forth-ev.de/doku.php/projects:430eforth:start

It is unfortunate, that Forth does not get the recognition it and especially Chuck deserves..
But look forward to Forth Day in November, where Greenarrays will bring us hopefully good news.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 6/11/2022 11:12 pm, [email protected] wrote:

One of the most interesting things about Forth is the lack of collaboration with in a community to excel and promote the language, while I see lots of individual efforts, lots of great intentions, it’s this lack of collaboration that creates greater

fragmentation and in the end and a deterrent reason for new uptake in the language IMO.

IMO Forth is aimed squarely at the experienced individual. Consider Moore himself. It's
the attempts to popularize it that have failed. If one wants a 'batteries included' language,
then IMO look at something like 8th where the developer seems to be catering to users who
a) are happy to go along and b) have faith in what he's doing.

From an embedded perspective, I firmly believe that FORTH really does have something that should greatly appeal commercial application, provided it is wrapped into a set of tools that enable commercialization and collaboration with in a community. IMHO

the is is so much wasted effort into trying to build “ my forth is better than your’s “ with the right intent, yet this does not serve the community to capture new adoption of users or commercial applications.

ISTM embedded is exactly where you've got your experienced individual and the existing
vendors are catering for them with appropriate tools. That said, it's not an Arduino
embedded-for-the-masses where supplied libraries are massively over-protected and users
freak out if their bootloader gets overwritten. Forth is - above all - about extracting
performance, not selling an experience. And that takes individual effort.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 07/11/2022 2:50, dxforth wrote:

On 6/11/2022 11:12 pm, [email protected] wrote:

One of the most interesting things about Forth is the lack of
collaboration with in a community to excel and promote the language,
while I see lots of individual efforts, lots of great intentions, it’s
this lack of collaboration that creates greater fragmentation and in
the end and a deterrent reason for new uptake in the language IMO.

IMO Forth is aimed squarely at the experienced individual.  Consider
Moore himself.  It's
the attempts to popularize it that have failed.  If one wants a
'batteries included' language,
then IMO look at something like 8th where the developer seems to be
catering to users who
a) are happy to go along and b) have faith in what he's doing.

I approve this message.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Monday, November 7, 2022 at 6:11:20 AM UTC+1, Ron AARON wrote:

On 07/11/2022 2:50, dxforth wrote:

On 6/11/2022 11:12 pm, [email protected] wrote:

One of the most interesting things about Forth is the lack of
collaboration with in a community to excel and promote the language,
while I see lots of individual efforts, lots of great intentions, it’s >> this lack of collaboration that creates greater fragmentation and in
the end and a deterrent reason for new uptake in the language IMO.

IMO Forth is aimed squarely at the experienced individual. Consider
Moore himself. It's
the attempts to popularize it that have failed. If one wants a
'batteries included' language,
then IMO look at something like 8th where the developer seems to be catering to users who
a) are happy to go along and b) have faith in what he's doing.

I approve this message.

So do I, I never it said this has to be an Arduino for the masses, I said, here is an idea that could bring two factors as outcomes:
- Remove the fragmentation to improve repeatability. * I can take most an code in C and make it behave as advertise, something that does not happen easily in Forth.
- Unison of a community would drive adoption. Spend a day on this forum and you see what I mean, lots of rhetoric and old unsettled differences seen to take up most of the time in the discussion.

No pain not gain, but gain non the less has to be a factor of predictable outcome and pain no gain is many times the outcome for new comers * myself included.

The outcome is a higher adoption ratio.
When you look say ADA (a lower adoption language in embedded,) sure, early on it had a limited number of targets available, but those in favor of it’s adoption did not build different paths to each target, rather they added the support to enable those
targets. * subtle add-ons to target the new platforms, not in the forms of HAL or drivers, you still have to do the heavy lifting and bare-metal write register programing to make things work. And yes, that is a principle IMO that is an important aspect
of embedded development and learning path. Very unlike the Arduino framework.

I learned this early when I used the STM32 HAL, wrote code that looked liked it conformed to the HAL, then spent weeks filling errors on the their support site. It’s a lot better now, but I still see issues popping up that the HAL changed and
something that previously worked now does not, so I stay aways 100% of the time.

I’m still disappointed that there is no unison in the Forth community to help build up adoption and find truly viable commercial applications for the language. I’m not inferring on the commercialization of the concept of the IDE, but like many other
project, funding could be an important thing once it’s adopted commercially viable.

Most here would argue in favor of Forth in the embedded space, so why not make the argument in a directed voice in the way it’s collaborative to help make FORTH greater and leverage the amazing talent of everyone in the Forth Community?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Moving to a stack based programing does take effort and application for the programmer, it has taken me about two to three months to really begin to understand the return stack and how to best use it to grasp some of the more advanced ways of

implementing forth to solve problems. It’s a fun language once you start, but the fragmentation and the lack of repeatability is the hardest barrier to grasp some of these concepts IMO, specially from those that learn by reading the code, testing it,
the making changes to experiment with the reinforcement of expected outcomes *repeatability of the code*.

I personally did not find the return stack to be difficult to understand
or manipulate, but I would recommended this video by Samuel Falvo for
anyone that does:

https://www.youtube.com/watch?v=mvrE2ZGe-rs

He goes through a lot of things and he uses the return stack for control
flow towards the end.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, November 10, 2022 at 3:49:37 PM UTC+1, shtps wrote:

He goes through a lot of things and he uses the return stack for control
flow towards the end.

Although my own compiler (4tH) does allow it, I'm not quite a fan of manipulating
the control stack for flow control. First, any word called has its own return address
on the TORS. Usually, you have to take it off do do stuff and put it on later in order
not to break things. IMHO this results in very murky code. Second, it's not portable.
compilers may use a different mechanism to do flow control.

Can't say I never used it, but I'm hesitant to do it - and only as a last resort. I'd rather
inline such code - since at least then it remains WITHIN a definition.

That doesn't mean I never use the return stack for my own purposes - quite the opposite.
It's a useful temporary storage. A technique I often use is to store constant terms there
- so they can be fetched with a single R@. It's quite useful when implementing routines
with LOTS of parameters. You store the more constant ones on the return stack, TORS
is perfect for stuff that RARELY changes - like "R> 1+ >R".

For that reason 4tH supports R@, R'@ and R"@. They act like a kind of R/O registers. And
it doesn't cause much overhead, since they're equivalent (in 4tH) to I, I' and J.

Hans Bezemer

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tuesday, December 6, 2022 at 3:37:53 PM UTC+5:30, Hans Bezemer wrote:

On Thursday, November 10, 2022 at 3:49:37 PM UTC+1, shtps wrote:

He goes through a lot of things and he uses the return stack for control flow towards the end.

Although my own compiler (4tH) does allow it, I'm not quite a fan of manipulating
the control stack for flow control. First, any word called has its own return address
on the TORS. Usually, you have to take it off do do stuff and put it on later in order
not to break things. IMHO this results in very murky code. Second, it's not portable.
compilers may use a different mechanism to do flow control.

Can't say I never used it, but I'm hesitant to do it - and only as a last resort. I'd rather
inline such code - since at least then it remains WITHIN a definition.

That doesn't mean I never use the return stack for my own purposes - quite the opposite.
It's a useful temporary storage. A technique I often use is to store constant terms there
- so they can be fetched with a single R@. It's quite useful when implementing routines
with LOTS of parameters. You store the more constant ones on the return stack, TORS
is perfect for stuff that RARELY changes - like "R> 1+ >R".

For that reason 4tH supports R@, R'@ and R"@. They act like a kind of R/O registers. And
it doesn't cause much overhead, since they're equivalent (in 4tH) to I, I' and J.

Hans Bezemer

https://www.quickbookintegration.com

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Friday, 28 December 2018 at 21:59:17 UTC+5:30, Ilya Tarasov wrote:

Trying to reproduce 40-years old approach with Forth, we are really going to nowhere. However, why we need to do it? I mean why we need to write OS, smartphone applications, GUI etc. There are a lot of applications where key Forth features as scripting,

language flexibility and compactness may be used.

I cannot agreed there is no Forth for <technology name>. We can script TensorFlow, OpenCV or something like this. We can deal with API with a help of Forth shell. The only questions is are we really need Forth features, or it is just an attempt to

highlight well-known technology? As I can see, agressive pushing Forth has almost zero productivity, with predictable answers (or just laughing). As a glueware or embedded tool, Forth is a good approach and will be alive for a long time.
https://www.youtube.com/channel/UCgobzHAPlW3lu6CR_TNNeyA

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

The Fitness Idea schrieb am Sonntag, 8. Oktober 2023 um 16:53:47 UTC+2:

On Friday, 28 December 2018 at 21:59:17 UTC+5:30, Ilya Tarasov wrote:

Trying to reproduce 40-years old approach with Forth, we are really going to nowhere. However, why we need to do it? I mean why we need to write OS, smartphone applications, GUI etc. There are a lot of applications where key Forth features as

scripting, language flexibility and compactness may be used.

I cannot agreed there is no Forth for <technology name>. We can script TensorFlow, OpenCV or something like this. We can deal with API with a help of Forth shell. The only questions is are we really need Forth features, or it is just an attempt to

highlight well-known technology? As I can see, agressive pushing Forth has almost zero productivity, with predictable answers (or just laughing). As a glueware or embedded tool, Forth is a good approach and will be alive for a long time.

You forgot the world of MCUs and embedded devices, that surpass the
PC world by order of magnitudes, and wherein Forth really shines.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I cannot agreed there is no Forth for <technology name>. We can script TensorFlow, OpenCV or something like this. We can deal with API with a help of Forth shell. The only questions is are we really need Forth features, or it is just an attempt to

highlight well-known technology? As I can see, agressive pushing Forth has almost zero productivity, with predictable answers (or just laughing). As a glueware or embedded tool, Forth is a good approach and will be alive for a long time.

You forgot the world of MCUs and embedded devices, that surpass the
PC world by order of magnitudes, and wherein Forth really shines.

It's just a spammer (both posts before yours) who found new way
of posting his spam: instead of creating new thread — chaining to
exisiting ones.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 10/10/2023 12:57 am, Zbig wrote:

I cannot agreed there is no Forth for <technology name>. We can script TensorFlow, OpenCV or something like this. We can deal with API with a help of Forth shell. The only questions is are we really need Forth features, or it is just an attempt to

highlight well-known technology? As I can see, agressive pushing Forth has almost zero productivity, with predictable answers (or just laughing). As a glueware or embedded tool, Forth is a good approach and will be alive for a long time.

You forgot the world of MCUs and embedded devices, that surpass the
PC world by order of magnitudes, and wherein Forth really shines.

It's just a spammer (both posts before yours) who found new way
of posting his spam: instead of creating new thread — chaining to
exisiting ones.

Sad. Even spammers end up here.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Sad. Even spammers end up here.

But at least „the G” (don't write that name to not summon him
even by accident) somehow gave up. ;)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Never thought that chatgpt was that bad..

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

minforth wrote:

Never thought that chatgpt was that bad..

According to https://www.zerogpt.com/ : "Your Text is AI/GPT Generated : 86.27%"

-marcel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)