info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Forth is the programming language of the future
2,608 views
Skip to first unread message
Manuel Rodriguez
Dec 28, 2018, 3:35:44 AM12/28/18
to
If somebody is trying to program a computer or a smartphone he has the
choice between many programming languages. The latest example of a well
working language is Golang which was introduced in 2009 and provides some
new features. In contrast to C++ and Python, the Go language looks very
modern and future ready. The reason is, that the language was designed
from scratch and provides a lot of libraries which makes it suitable
for developers who wants to create their first apps. Go was developed
similar to C++ for practical usage.
If the mainstream ecosystem is working great, why the world needs
Forth? It's a good question. On the first look, Forth can't be compared
with modern programming languages and it's hard to do simple things. In
go, it is very easy to create a GUI, a webbrowser or a primenumber
generator, while Forth lacks in everything. It has no garbage collector,
no GUI libraries, and no nothing at all. Understanding Forth is only
possible if the expectation of the developer will change. The strength of
Forth is, that no standard is there. Instead the developer has to invent
everything from scratch. If he want's to program with object-oriented
style nobody will hold him back. If he want's to allocate lots of
memory, he is welcome. The reason why Forth is working better than
managed languages like C++ is, that only with Forth the programmer
has control over his computer. He isn't forced to follow anybody. That
means, there is no compiler which is used by everybody, and there is no
collection of libraries which allows him to write the first gui app in
under a minute. The missing features in Forth are the main strength of the
language. If the language comes without guidelines and without predefined
functions, the developer is in charge to deliver the missing parts.
Forth is a programming language not invented yet. It's very similar to
the book “Linux from scratch” which is not an operating system but
a guideline how to create an operating system. Forth can be seen as
a true metalanguage. Even the well known Forth primitives like swap,
dup and mod are not standardized, which means they have to be invented
in each Forth system by it's own.
Mainstream computer languages like Java or Python can be seen as the
answer to a problem. Java, for example answers the question of how to
program platform independent code. The programmer has to read the manual,
understands the concepts behind Java and follows the community. Forth is
working the other way around. It doesn't provide knowledge, Forth asks
for knowledge. In mainstream programming languages, the newbie gets a
shiny compiler for running the sourcecode. In Forth, the newbie has to
write the compiler as his first project. That is the reason, why Forth
is loved by computer professionals. It gives them the opportunity to
learn, to make mistakes and to bring technology forward. My prediction
is simple: in 20 years, all the mainstream languages are gone. C# will
become obsolete and nobody will remember the PHP scripting language,
but Forth will become the industry standard.
* How to get started *
The Forth language makes it hard for newbies to get started. .The reason
is, that Forth doesn't provide sourcecode and the available Forth Virtual
machines can't be recommended anymore. But if nothing is there, what
should the newbie learn? What are the do's and dont's? The reason why
Forth is nearly invisible has to do with, that it's a virtual machine. A
VM is a game similar to a cardgame. The rules of the Forth game can be
written down in a single sheet of paper. But for playing the game right,
this description is not sufficient. What the beginner needs are additional
information about Forth. I can't recommend a single book. The inventor
is Chuck Moore and he has written some books about Forth, but they are
not the best starting point. What i recommend is to use a search engine
like google and search in the existing fulltext of all publications.
Here is my recommended Google search string, it contains of some keywords
which reduce the internet to Forth related information. At the end of
the string, the user can put his own topic of interesting for example he
can add “Forth CPU” if he is interested in Forth in Hardware, or he
can add “benchmark” if he is interested in a performance comparison
with a classical programming language.
["Rochester Forth Conference" OR "Journal of Forth Application and
Research" OR "Forth assembly" OR "Forth programming" OR "ACM SIGFORTH"
OR "Forth Dimensions" OR "euroForth" OR "figForth" OR "euroFORML" OR
“FORML Conference” OR “SVFIG” OR site:forth.org OR site:forth.com]
filetype:pdf
Forth itself can't described in a book or in software. But the
literature around Forth can be collected and searched by a fulltext
search engine. That means, the amount of blogs, pdf papers and books
about Forth is forming the corpus. And what is available in the corpus
is similar to Forth. Something in the collection is wrong or outdated,
but this is normal in every community. If we are searching for information
about robotics, we will notice the same problem. What is special in the
Forth corpus is, that the total amount of information is limited. It is
very common, that Google doesn't find a single result for a keyword. That
means, the information is simply not there, it was not written down. Let
us take a detailed look into the keyword list. They are about academic
journals like the “Journal of Forth Applications”, it contains the
famous forth.org website and also the Forth Dimension journal. I would
guess, that most of available Forth literature will be found with that
searchstring. Some Forth related information are only available as printed
books, some are out of print and no longer available. So it's important
to write new Forth tutorials from scratch to add the missing information.
choice between many programming languages. The latest example of a well
working language is Golang which was introduced in 2009 and provides some
new features. In contrast to C++ and Python, the Go language looks very
modern and future ready. The reason is, that the language was designed
from scratch and provides a lot of libraries which makes it suitable
for developers who wants to create their first apps. Go was developed
similar to C++ for practical usage.
If the mainstream ecosystem is working great, why the world needs
Forth? It's a good question. On the first look, Forth can't be compared
with modern programming languages and it's hard to do simple things. In
go, it is very easy to create a GUI, a webbrowser or a primenumber
generator, while Forth lacks in everything. It has no garbage collector,
no GUI libraries, and no nothing at all. Understanding Forth is only
possible if the expectation of the developer will change. The strength of
Forth is, that no standard is there. Instead the developer has to invent
everything from scratch. If he want's to program with object-oriented
style nobody will hold him back. If he want's to allocate lots of
memory, he is welcome. The reason why Forth is working better than
managed languages like C++ is, that only with Forth the programmer
has control over his computer. He isn't forced to follow anybody. That
means, there is no compiler which is used by everybody, and there is no
collection of libraries which allows him to write the first gui app in
under a minute. The missing features in Forth are the main strength of the
language. If the language comes without guidelines and without predefined
functions, the developer is in charge to deliver the missing parts.
Forth is a programming language not invented yet. It's very similar to
the book “Linux from scratch” which is not an operating system but
a guideline how to create an operating system. Forth can be seen as
a true metalanguage. Even the well known Forth primitives like swap,
dup and mod are not standardized, which means they have to be invented
in each Forth system by it's own.
Mainstream computer languages like Java or Python can be seen as the
answer to a problem. Java, for example answers the question of how to
program platform independent code. The programmer has to read the manual,
understands the concepts behind Java and follows the community. Forth is
working the other way around. It doesn't provide knowledge, Forth asks
for knowledge. In mainstream programming languages, the newbie gets a
shiny compiler for running the sourcecode. In Forth, the newbie has to
write the compiler as his first project. That is the reason, why Forth
is loved by computer professionals. It gives them the opportunity to
learn, to make mistakes and to bring technology forward. My prediction
is simple: in 20 years, all the mainstream languages are gone. C# will
become obsolete and nobody will remember the PHP scripting language,
but Forth will become the industry standard.
* How to get started *
The Forth language makes it hard for newbies to get started. .The reason
is, that Forth doesn't provide sourcecode and the available Forth Virtual
machines can't be recommended anymore. But if nothing is there, what
should the newbie learn? What are the do's and dont's? The reason why
Forth is nearly invisible has to do with, that it's a virtual machine. A
VM is a game similar to a cardgame. The rules of the Forth game can be
written down in a single sheet of paper. But for playing the game right,
this description is not sufficient. What the beginner needs are additional
information about Forth. I can't recommend a single book. The inventor
is Chuck Moore and he has written some books about Forth, but they are
not the best starting point. What i recommend is to use a search engine
like google and search in the existing fulltext of all publications.
Here is my recommended Google search string, it contains of some keywords
which reduce the internet to Forth related information. At the end of
the string, the user can put his own topic of interesting for example he
can add “Forth CPU” if he is interested in Forth in Hardware, or he
can add “benchmark” if he is interested in a performance comparison
with a classical programming language.
["Rochester Forth Conference" OR "Journal of Forth Application and
Research" OR "Forth assembly" OR "Forth programming" OR "ACM SIGFORTH"
OR "Forth Dimensions" OR "euroForth" OR "figForth" OR "euroFORML" OR
“FORML Conference” OR “SVFIG” OR site:forth.org OR site:forth.com]
filetype:pdf
Forth itself can't described in a book or in software. But the
literature around Forth can be collected and searched by a fulltext
search engine. That means, the amount of blogs, pdf papers and books
about Forth is forming the corpus. And what is available in the corpus
is similar to Forth. Something in the collection is wrong or outdated,
but this is normal in every community. If we are searching for information
about robotics, we will notice the same problem. What is special in the
Forth corpus is, that the total amount of information is limited. It is
very common, that Google doesn't find a single result for a keyword. That
means, the information is simply not there, it was not written down. Let
us take a detailed look into the keyword list. They are about academic
journals like the “Journal of Forth Applications”, it contains the
famous forth.org website and also the Forth Dimension journal. I would
guess, that most of available Forth literature will be found with that
searchstring. Some Forth related information are only available as printed
books, some are out of print and no longer available. So it's important
to write new Forth tutorials from scratch to add the missing information.
jpit...@gmail.com
Dec 28, 2018, 4:34:47 AM12/28/18
to
https://www.mpeforth.com/books.htm
https://www.forth.com/forth-books/
https://github.com/ForthHub/ForthFreak/wiki/Forthfreak-wiki
I am rather surprised to read that 50 years of Forth has not produced sufficient material to learn Forth.
We all learn differently – so none of the material might fit how you learn
– but the successes of Forth over the years must have been achieved by people who had to learn Forth – and then applied it successfully.
I tried the link given, but it did not show what I wanted – google sees everybody’s demands differently.
Instead I just asked google about “Books about Forth”.
And ended up at what the Forth Compiler Suppliers suggest for example.
And you can always look at the Forth Bookshelf.
The classic being Starting Forth.
The one I would recommend from the bookshelf is A Start With Forth – to my knowledge the most recent Forth overview – and a lot for download and try out at
https://wiki.forth-ev.de/doku.php/en:projects:a-start-with-forth:start0.
Try Invent A Language
12 Words as Start
35 words – A training I gave to a group – 2 hours and the basics were understood.
Easyforth with no installation – just try it in your browser.
VFXTESTAPP – a VFX targeted as easy download and to learn with – SAVE to keep what you have done.
Regarding Learning Forth there is a starting point – and there is a target,
and this was unfortunately not defined in this post – so how can you define a route to get there?
Mark Wills
Dec 28, 2018, 5:02:35 AM12/28/18
to
On Friday, 28 December 2018 08:35:44 UTC, Manuel Rodriguez wrote:
become obsolete to be replaced by Forth is not backed up
with any supporting arguments or evidence.
5/10.
Liang Ng
Dec 28, 2018, 6:09:01 AM12/28/18
to
On Friday, 28 December 2018 18:02:35 UTC+8, Mark Wills wrote:
> It's a nice essay, but your main point, that C# etc. will
> become obsolete to be replaced by Forth is not backed up
> with any supporting arguments or evidence.
>
> 5/10.
What you wanted is here, in another thread:
> It's a nice essay, but your main point, that C# etc. will
> become obsolete to be replaced by Forth is not backed up
> with any supporting arguments or evidence.
>
> 5/10.
https://groups.google.com/d/msg/comp.lang.forth/cAZURahAnzg/4KdMNH3pDAAJ
NN
Dec 28, 2018, 6:36:45 AM12/28/18
to
On Friday, 28 December 2018 08:35:44 UTC, Manuel Rodriguez wrote:
> If somebody is trying to program a computer or a smartphone he has the
> choice between many programming languages.
..... The only "persons" programming computers or smartphones in the future will be other computers and smartphones.
> choice between many programming languages.
In fact we wont have smartphones in the future because we will have smart watches.
So what were you saying ...?
peter4...@gmail.com
Dec 28, 2018, 7:50:33 AM12/28/18
to
you can find here :
https://sites.google.com/view/win32forth/books-on-forth
a modern Forth with GUI ANSI is Win32forth , free and with full sources :
read my opinion about it here : https://sites.google.com/view/win32forth/home
videos how to install it, and some tricks : look for Win32forth on Y2B
my channel is Peter Forth , start here :
https://www.youtube.com/watch?v=5MnUkdNTq6s
peter4...@gmail.com
Dec 28, 2018, 7:52:35 AM12/28/18
to
the site of Jos Ven is the best.
https://sites.google.com/site/win324th/
Albert van der Horst
Dec 28, 2018, 7:58:39 AM12/28/18
to
In article <4d3acddf-29fd-4e87...@googlegroups.com>,
Go is a rehash of algol68.
http://cowlark.com/2009-11-15-go/index.html
It misses the mistakes that are added in the way to C++/Java.
It is probably better, it should be with 50 years (!) of hindsight.
Interestingly, modern Forth or lisp have no fundamental edge over
'68 vintage Forth or Lisp either.
It is hard to come up with something really new.
By all means, use Golang. It would be progress if it replaced Mycropython.
I'll stick with Forth.
Groetjes Albert
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
Manuel Rodriguez <a...@gmx.net> wrote:
>If somebody is trying to program a computer or a smartphone he has the
>choice between many programming languages. The latest example of a well
>working language is Golang which was introduced in 2009 and provides some
>new features. In contrast to C++ and Python, the Go language looks very
>modern and future ready. The reason is, that the language was designed
>from scratch and provides a lot of libraries which makes it suitable
>for developers who wants to create their first apps. Go was developed
>similar to C++ for practical usage.
Go is modern?
>If somebody is trying to program a computer or a smartphone he has the
>choice between many programming languages. The latest example of a well
>working language is Golang which was introduced in 2009 and provides some
>new features. In contrast to C++ and Python, the Go language looks very
>modern and future ready. The reason is, that the language was designed
>from scratch and provides a lot of libraries which makes it suitable
>for developers who wants to create their first apps. Go was developed
>similar to C++ for practical usage.
Go is a rehash of algol68.
http://cowlark.com/2009-11-15-go/index.html
It misses the mistakes that are added in the way to C++/Java.
It is probably better, it should be with 50 years (!) of hindsight.
Interestingly, modern Forth or lisp have no fundamental edge over
'68 vintage Forth or Lisp either.
It is hard to come up with something really new.
By all means, use Golang. It would be progress if it replaced Mycropython.
I'll stick with Forth.
Groetjes Albert
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
Albert van der Horst
Dec 28, 2018, 8:07:32 AM12/28/18
to
In article <50eea968-74c7-486e...@googlegroups.com>,
<peter4...@gmail.com> wrote:
<SNIP>
>home
win32forth is nice, but it is doomed. Married to Microsoft and 32 bits
only. It will be extinct with the next mass-extinction.
Only bacterial-size Forth's like ciforth will survive.
In the first place they have no problem migrating between eco-systems
and actually have.
<peter4...@gmail.com> wrote:
<SNIP>
>
>a modern Forth with GUI ANSI is Win32forth , free and with full sources :
>
>read my opinion about it here : https://sites.google.com/view/win32forth/=
>a modern Forth with GUI ANSI is Win32forth , free and with full sources :
>
>home
win32forth is nice, but it is doomed. Married to Microsoft and 32 bits
only. It will be extinct with the next mass-extinction.
Only bacterial-size Forth's like ciforth will survive.
In the first place they have no problem migrating between eco-systems
and actually have.
peter4...@gmail.com
Dec 28, 2018, 9:09:21 AM12/28/18
to
On Friday, December 28, 2018 at 6:35:44 AM UTC-2, Manuel Rodriguez wrote:
With Forth actually you go nowhere in the professional programming world.
There are no toolchains for Forth in any OS. So I really doubt you will
progress with your search of Forths for a smartphone.
The only I have found as I went back to forth 3 years ago, was Win32forth(for PCs).
(since I am using it for hobby , and learning, I did not want to use
VFX or Swift, they do not provide the sources, I tried them out but I did not
like theirs IDE and were not complete for easy GUI development or out of reach for hobby applications)
On Win32forth you have the complete sources of any single byte on the code you are
running, and you can create turnkey applications on windows snapping your fingers.
There are tons of examples for any kind application you want to create, from
GUI Interface at all levels, console applications, to simple graphics, file access,
dbase interface , wordprocessing, editors,asm, disassembler, more complex graphics over OpenGL, serial IO, net etc... There is even not only the Form
designer , but also the VisualForth from Dirk to help you creating attractive
modern interefaces.
And there is still an active community working on it,and creating some new programs
and examples . I am doing that and I am also creating some VIDEOS teaching some tricks
and showing what Forth is able to do.
One of the last projects, I showed an interface to the Nodemcu an IOT device, and examples
how you can do that very easily (much better than any Python or C++ stuff) with Win32forth
and using Punyforth another modern forth for IOT. I still have some unfinished work (newer programs
on Win32forth) and will do some videos, hope I get time free during 2019 to publish them on Y2B.
Mr. Pintaske, may have much knowledge on trolling or how to humillate forth programmers with his insults on public Forth forums, using the great master names of the community like Mr. Moore or Dr. Ting, as shield for his felonies.
But on Forth programming he is a complete ignorant, promoting
40 or 50 year old texts, out of modern programming reality to a group of colletctors of antiquity, without index, and with a foreword written by
an 8 year old child.
For example :
Recommending a 35 words forth for a newby is an affront to the intelligence of the poor man.
Nobody can go nowhere with a 40 year old Forth today written for 8 bit cpus, except ridicularize yourself, when we have at 0.50- 1,00 U$S CPU with MMU on board, GPU, 1000 registers, and DSP barrel multiplier on board, and 64 bits.
This is a dead road, that only ends in frustration. Therefore, the insults
and the irratibility are on top of the list. There are no tools, there is no simple
float math in it, it has no OS interface, so you can do absolutly nothing
and worser you have to learn RPN to work with that old shoe !
Take for example the RPI, if you offer to the newbies that wants to learn a programming
language , a 35 words Forth , they can´t simply light a led on an off ! They
will laugh at you, or comparing this to Python they will think he is completly mad. If you can´t print
"Hello world" to the screen, or you can´t program a simple RC servo for a toy Robot, as
the own Pintaske could not (even using VFX he is so proud to recommend), and was asking for help on the forums.
And as I inocently asked him : "Why don´t you
ask this to Phelc *" he went mad,because he has no clue in Forth programming, and started
using pejorative terms offesive slang and insulting a lot letting everybody know
(outside and inside the Forth community)
how impotent and frustrated he feels with forth 35 words or VFX, he using both
Forths unable to program a Toy for an 8 year old child ! :)
Unsing the above example, you can extrapolate the rest.. and see why
Forths are not used any more as programming language at all. You have not the right tools.
With all my respect to the great master Dr. Ting.
But he offered an ESP8266 eforth without the wifi words. So a modern chip (one of the easiest to access and buy today) born for IOT and WIFI , had to be used without Wifi(the purpose of its existance) because of incomplete Forth implementations...
The question is for what somebody would enter into that sinking ship ?
My nephew has an Arduino IDE
(for free) that has WIFI libraries, and he is able to program the ESP8266 in flat 2 minutes and make a web-server or an IOT device to run like a clp...
(Of course I triyed to convince him of forth, but he laughed at me ! )
Modern CPUs need an OS they are too complicated devices to be used without them. OSes are written
by teams of hundreds of programmers (like mPhyton, like Expressif, like Rtos, etc etc etc). Expressif for Nodemcu had 600 programmers writing the routines
for Wifi and MMU, etc.
If you look at Go or Android you see monster software companies with 10thausend 20thausend programmers
behind those gigantic projects. Nowadays we can not put together 5 Forth programmers to work on the same project.
So the rest is only illusions or fantasy.
I know there are some retroprogrammers that still continue to see the world
with eyes of 8 Bit CPU of 1978. I do not talk to the ones they still like
Forth as a hobby and program backwards on old platforms.
For them all my respect ! I like your work very much.
But there are other dreamers, without clue, talking on 2018-19, with the same
concepts of 1970 they seem to live in a parallel world.
In the universe where we live with our actual laws of physics acting normally
day by day, as we know and studied, there will be no Forth for Smartphones, no Forths in future for AI or for the tensor programming model, because it would be absolutely inproductive to program in Forth such applications.
Ilya Tarasov
Dec 28, 2018, 11:29:17 AM12/28/18
to
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.
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.
jpit...@gmail.com
Dec 28, 2018, 1:11:18 PM12/28/18
to
Stating Forth
stating quite clearly :
The original print edition of Starting FORTH is copyrighted by FORTH, Inc. and all rights are reserved. Permission has been granted to Juergen Pintaske to make this PDF of the on-line version of the work available and to make
certain modifications to the original printed work.
Further reproduction (except for the printing of single copies for
personal use), modification, distribution, posting on other web sites, or unauthorized use of either the printed or online version of Starting FORTH by any party other than Juergen Pintaske is expressly forbidden without prior written permission from: FORTH, Inc. 5959, W. Century Blvd. Suite 700, Los Angeles, CA 90045 USA,
www.forth.com
For personal print out formatted from web .
Enjoy. Download from www.exemark.com Juergen Pintaske 2013_12_24
And this seems to be his major work - stealing another of my prepared books - and he is silly enough to boast with this on his website -
What a wonderful day - he fell into the trap.
And by the way - the Forth Books I have published are the only ones visible on the amazon Compiler Bestseller list https://www.amazon.com/gp/bestsellers/books/3970/ref=pd_zg_hrsr_b_1_5_last#5
About 10% there for Forth - not too bad ...
Well, at least normal people do appreciate the work - clf is a completely different story - and my published books are for people who are interested in the theme - proven to be helpful for the last 5 years. And probably for the next 20 years.
jpit...@gmail.com
Dec 28, 2018, 1:56:08 PM12/28/18
to
On Friday, 28 December 2018 16:29:17 UTC, 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.
Ilya, I mostly did these eBooks and Print Books to promote Forth, for fun and to learn a bit about Forth myself.
> 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.
The market decides anyway about any interest - and there are people buy them. ( sorry to use the word market here )
And I assume that many of the people here have learnt Forth using similar material.
So nothing has really changed except that new people use it for the same purpose.
I would prefer the availability of more modern Forth books as well - but it seems there are none.
minf...@arcor.de
Dec 28, 2018, 2:41:30 PM12/28/18
to
Am Freitag, 28. Dezember 2018 19:56:08 UTC+1 schrieb jpit...@gmail.com:
> And I assume that many of the people here have learnt Forth using similar material.
I think most have learnt it the hard way: by DOING s.th. with Forth.
> And I assume that many of the people here have learnt Forth using similar material.
Not by reading books, that came later. Trying to understand code listings
was the way, sometimes sparsely documented by shadows blocks.
> So nothing has really changed except that new people use it for the same purpose.
> I would prefer the availability of more modern Forth books as well - but it seems there are none.
IMO the "changes" since Forth-79 are rudimentary. No dumb bashing intended,
it only shows that the programming requirements for small/est devices have
also not changed much over the years. Many manufacturers of small boards
offer C compilers plus driver libraries along with the boards. That hasn't
changed either.
peter4...@gmail.com
Dec 28, 2018, 4:06:41 PM12/28/18
to
What does it mean "criminality", are you threatening me because I write the
words "Starting Forth" in a public programming forum ?
What criminality are you talking about, are you stupid, crazy , or both things ?
You are making yourself a full time idiot of the Forth forums.
I regret so much, such prestigious Forth authors have fallen in your
trap. The trap of an ignorant without manners , that helps to destroy
Forth a bit more each day.
And now pretends to put under copyright all the history of forth.
You are totally out of your mind !
dxf...@gmail.com
Dec 28, 2018, 7:58:14 PM12/28/18
to
has seen many times before. They come with yet another plan to
save Forth with high hopes and much rhetoric and invariably leave
disillusioned.
dxf...@gmail.com
Dec 28, 2018, 8:23:33 PM12/28/18
to
On Saturday, December 29, 2018 at 12:07:32 AM UTC+11, Albert van der Horst wrote:
> In article <50eea968-74c7-486e...@googlegroups.com>,
> <peter4...@gmail.com> wrote:
> <SNIP>
> >
> >a modern Forth with GUI ANSI is Win32forth , free and with full sources :
> >
> >read my opinion about it here : https://sites.google.com/view/win32forth/=
> >home
>
> win32forth is nice, but it is doomed. Married to Microsoft and 32 bits
> only. It will be extinct with the next mass-extinction.
Commercial systems too. Big and bulky they serve their clients
> In article <50eea968-74c7-486e...@googlegroups.com>,
> <peter4...@gmail.com> wrote:
> <SNIP>
> >
> >a modern Forth with GUI ANSI is Win32forth , free and with full sources :
> >
> >read my opinion about it here : https://sites.google.com/view/win32forth/=
> >home
>
> win32forth is nice, but it is doomed. Married to Microsoft and 32 bits
> only. It will be extinct with the next mass-extinction.
for as long as the latter exist. Standards, which are there to
support the interests of the mega-forths, are similarly doomed.
>
> Only bacterial-size Forth's like ciforth will survive.
> In the first place they have no problem migrating between eco-systems
> and actually have.
and rebuilt from scratch. In contrast we want our forths and standards
to go on forever as absurd as such notions are.
"Look back over the past, with its changing empires that rose and
fell, and you can foresee the future, too."
hughag...@gmail.com
Dec 28, 2018, 9:51:35 PM12/28/18
to
On Friday, December 28, 2018 at 6:23:33 PM UTC-7, dxf...@gmail.com wrote:
> Standards, which are there to
> support the interests of the mega-forths, are similarly doomed.
This makes no sense!
> Standards, which are there to
> support the interests of the mega-forths, are similarly doomed.
1.) The purpose of a standard is to allow programs and code-libraries to be portable between different compatible systems.
For this to work, there obviously have to be more than one system in use.
So a standard is more useful for multiple small systems, rather than a few "mega-Forths."
2.) Neither Forth Inc. nor MPE are mega-sized companies.
They are both very small companies.
Even small plumbing companies employ an order of magnitude more people,
and make an order of magnitude more money.
For Forth to grow, there needs to be a meaningful standard
that supports general-purpose data-structures (real quotations are needed),
and allows programs and code-libraries to be portable.
In this case, there will arise multiple Forth systems that adhere to the standard,
and the Forth community will grow.
This is the future that Forth Inc. and MPE are striving to prevent.
Bob Armstrong
Dec 28, 2018, 10:01:27 PM12/28/18
to
Albert van der Horst
Dec 29, 2018, 8:37:38 AM12/29/18
to
In article <66b64e7b-2b72-4a51...@googlegroups.com>,
Ilya Tarasov <ilya74....@gmail.com> wrote:
>Trying to reproduce 40-years old approach with Forth, we are really going t=
>o nowhere. However, why we need to do it? I mean why we need to write OS, s=
>martphone applications, GUI etc. There are a lot of applications where key =
>Forth features as scripting, language flexibility and compactness may be us=
>ed.
>
>I cannot agreed there is no Forth for <technology name>. We can script Tens=
>orFlow, 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, agres=
>sive pushing Forth has almost zero productivity, with predictable answers (=
>or just laughing). As a glueware or embedded tool, Forth is a good approach=
micropython. Our niche has been taken.
Ilya Tarasov <ilya74....@gmail.com> wrote:
>Trying to reproduce 40-years old approach with Forth, we are really going t=
>o nowhere. However, why we need to do it? I mean why we need to write OS, s=
>martphone applications, GUI etc. There are a lot of applications where key =
>Forth features as scripting, language flexibility and compactness may be us=
>ed.
>
>I cannot agreed there is no Forth for <technology name>. We can script Tens=
>orFlow, 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, agres=
>sive 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.
I agree wholeheartedly, but the ultimate glueware at this moment is
micropython. Our niche has been taken.
hughag...@gmail.com
Dec 29, 2018, 10:02:04 AM12/29/18
to
On Saturday, December 29, 2018 at 6:37:38 AM UTC-7, Albert van der Horst wrote:
> In article <66b64e7b-2b72-4a51...@googlegroups.com>,
> Ilya Tarasov <ilya74....@gmail.com> wrote:
> >I cannot agreed there is no Forth for <technology name>. We can script Tens=
> >orFlow, 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, agres=
> >sive 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.
>
> I agree wholeheartedly, but the ultimate glueware at this moment is
> micropython. Our niche has been taken.
In 1994 when I was at Testra, I should have told them:
> In article <66b64e7b-2b72-4a51...@googlegroups.com>,
> Ilya Tarasov <ilya74....@gmail.com> wrote:
> >I cannot agreed there is no Forth for <technology name>. We can script Tens=
> >orFlow, 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, agres=
> >sive 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.
>
> I agree wholeheartedly, but the ultimate glueware at this moment is
> micropython. Our niche has been taken.
"Before the MiniForth processor can be used,
we need to wait for MicroPython to be invented, so it can be glueware
for C code written by somebody smarter than us!" ;-)
That would have certainly marked my last day on the job.
Of course, it can be argued that my last day on the job did come eventually,
although that was after I wrote MFX for the MiniForth.
Any application that uses MicroPython is going to be soft real-time at best.
You aren't going to do hard real-time with a dynamic-OOP language featuring GC.
Also, you are going to need a 32-bit ARM Cortex for your application,
although a 16-bit Forth processor would have been adequate.
I haven't really looked at Ilya Tarasov's processors.
He's competing on the basis of performance and price though,
so I assume they are 16-bit.
hughag...@gmail.com
Dec 29, 2018, 10:49:17 AM12/29/18
to
a lot more interested in writing papers than in writing code that works.
Manuel Rodriguez is almost certainly a sock-puppet of Rod Pemberton.
He writes very lengthy posts that are entirely nonsense,
which is the exact same style as Rod Pemberton who seems to have disappeared.
On Friday, December 28, 2018 at 1:35:44 AM UTC-7, Manuel Rodriguez wrote:
> On the first look, Forth can't be compared
> with modern programming languages and it's hard to do simple things.
> ...
> with modern programming languages and it's hard to do simple things.
> Understanding Forth is only
> possible if the expectation of the developer will change. The strength of
> Forth is, that no standard is there. Instead the developer has to invent
> everything from scratch.
This guy is not trying to save Forth. He is mocking Forth.
> possible if the expectation of the developer will change. The strength of
> Forth is, that no standard is there. Instead the developer has to invent
> everything from scratch.
He is playing the "Devil's Advocate" by pretending to praise Forth while
ridicularizing Forth by saying that it lacks all useful features
(note that "ridicularize" isn't a real word; Peter coined the term).
The goal of "Manuel" is to convince everybody that C is the "god language"
(note that Rod Pemberton coined the term "god language" for C).
I admit though, that the 32-bit processors are pretty inexpensive nowadays.
In 1994, the competition in the laser-etching business was using an
MC68000 programmed in C. The MiniForth beat that on both price and performance.
Those days are past. The MC68000 evolved into the ColdFire that is now obsolete.
Beating the ARM Cortex on price or performance is much more difficult.
I don't know of any application in which Forth would be a win on both
price and performance (maybe one or the other though).
If I knew this, I would be working as a programmer rather than a plumber.
foxaudio...@gmail.com
Dec 29, 2018, 11:43:41 AM12/29/18
to
On Friday, December 28, 2018 at 10:01:27 PM UTC-5, Bob Armstrong wrote:
> Forth is the foundation . Everyday use is why I've built a reference counted APL in it .
Here here!
> Forth is the foundation . Everyday use is why I've built a reference counted APL in it .
I have always felt that after the first page or two, one should not be programming in Forth but
rather in the new language that you create for the problem domain.
You Bob, have taken this concept to completion.
There is nothing preventing the creation of other language abstractions from being loaded
onto to Forth to simplify coding in different domains.
Perhaps, just perhaps, we have fallen into a trap by of thinking of "libraries" rather than
languages as the correct way to extend Forth's usefulness.
Ilya Tarasov
Dec 29, 2018, 12:48:56 PM12/29/18
to
> Ilya, I mostly did these eBooks and Print Books to promote Forth, for fun and to learn a bit about Forth myself.
> The market decides anyway about any interest - and there are people buy them. ( sorry to use the word market here )
>
> And I assume that many of the people here have learnt Forth using similar material.
> So nothing has really changed except that new people use it for the same purpose.
> I would prefer the availability of more modern Forth books as well - but it seems there are none.
hughag...@gmail.com
Dec 29, 2018, 1:53:12 PM12/29/18
to
Peter makes a good point:
On Friday, December 28, 2018 at 7:09:21 AM UTC-7, peter4...@gmail.com wrote:
> Recommending a 35 words forth for a newby is an affront
> to the intelligence of the poor man.
I've never seen any Forth book that got past novice-level programming.
All books on C describe structs. Most are still novice-level though.
A few books on C, Python, etc. that delve into intermediate-level topics.
There are very few Forth programmers delving into anything very advanced.
I'm not aware of any c.l.f. enthusiast who is beyond intermediate-level.
Ilya Tarasov may be at the advanced level.
I would have to examine his Forth system to verify this.
He seems reasonably intelligent though. He is not just blowing hot air.
Ilya: If you want to corroborate on a Forth book with me, contact me by email.
I've already thought of a good title: "Intermediate-Level Forth Programming."
There would be a heavy emphasis on meta-compiling, including a cross-compiler.
Publish both English and Russian versions to double the market!
The market may still be less than 20, so don't expect to get rich doing this.
Certainly, only advanced-level Forth programmers are qualified to write a book
on intermediate-level Forth.
When intermediate-level Forth programmers try to write a book, they invariably
come up with yet-another novice-level book.
When novice-level Forth programmers try to write a book, they invariably
come up with a pile of nonsense (https://www.forth.com/forth-books/).
m...@iae.nl
Dec 29, 2018, 3:26:22 PM12/29/18
to
On Saturday, December 29, 2018 at 5:43:41 PM UTC+1, foxaudio...@gmail.com wrote:
> On Friday, December 28, 2018 at 10:01:27 PM UTC-5, Bob Armstrong wrote:
[..]
> On Friday, December 28, 2018 at 10:01:27 PM UTC-5, Bob Armstrong wrote:
> Here here!
>
> I have always felt that after the first page or two, one should not
> be programming in Forth but rather in the new language that you
> create for the problem domain.
>
> You Bob, have taken this concept to completion.
>
> There is nothing preventing the creation of other language
> abstractions from being loaded onto to Forth to simplify
> coding in different domains.
>
> Perhaps, just perhaps, we have fallen into a trap by of thinking
> of "libraries" rather than languages as the correct way to extend
> Forth's usefulness.
I think you are onto something. A "word" in Forth is vastly
>
> I have always felt that after the first page or two, one should not
> be programming in Forth but rather in the new language that you
> create for the problem domain.
>
> You Bob, have taken this concept to completion.
>
> There is nothing preventing the creation of other language
> abstractions from being loaded onto to Forth to simplify
> coding in different domains.
>
> Perhaps, just perhaps, we have fallen into a trap by of thinking
> of "libraries" rather than languages as the correct way to extend
> Forth's usefulness.
more powerful than a conventional subroutine that is meant to be
combined with other subroutines in some linear fashion.
A small segment of Forth source may look familiar, but that
does not give you *any* guarantee of what will happen when it is
executed. It is not just that we do not know what each individual
word does, it could be that words compile or parse other words
on the fly, construct a mini program with it, and use it to
further modify the flow of execution.
I'm not saying we can't do this in other languages, anything
can be done in any language. Forth just makes it extremely easy.
Making something extremely easy is more enabling than it may
seem -- ask any Python programmer.
-marcel
hughag...@gmail.com
Dec 29, 2018, 10:10:20 PM12/29/18
to
On Saturday, December 29, 2018 at 11:53:12 AM UTC-7, hughag...@gmail.com wrote:
> Certainly, only advanced-level Forth programmers are qualified to write a book
> on intermediate-level Forth.
> When intermediate-level Forth programmers try to write a book, they invariably
> come up with yet-another novice-level book.
> When novice-level Forth programmers try to write a book, they invariably
> come up with a pile of nonsense (https://www.forth.com/forth-books/).
That webpage (https://www.forth.com/forth-books/) has this title:
> Certainly, only advanced-level Forth programmers are qualified to write a book
> on intermediate-level Forth.
> When intermediate-level Forth programmers try to write a book, they invariably
> come up with yet-another novice-level book.
> When novice-level Forth programmers try to write a book, they invariably
> come up with a pile of nonsense (https://www.forth.com/forth-books/).
"Forth Books by the Experts"
I really don't know why the ANS-Forth cult puts up with such gross arrogance.
Apparently they just don't have any pride.
Certainly, when sales-people are considered to be experts, there is no future.
Here is a fun quote from the self-proclaimed "expert" at Forth Inc.:
On Sunday, August 9, 2015 at 7:30:10 PM UTC-7, Elizabeth D. Rather wrote:
> Here's [an array definer] presented in my Forth Application Techniques that I think is
> far more useful than the FSL version:
>
> : ARRAY ( n -- ) CREATE DUP , CELLS ALLOT
> DOES> ( n -- a) SWAP OVER @ OVER < OVER
> 1 < OR ABORT" Out of Range" CELLS + ;
This code is really below novice-level.
Her array definer is limited to cell-size elements.
If she needs another size of element, such as for an array of floats,
she would copy-and-paste the array definer, tweaking it for the new element size.
Also, her COBOL background is showing through.
She has the bottom element indexed by 1 rather than by 0.
Note that this is the only example I am aware of in which Elizabeth Rather
wrote code herself from scratch.
Normally she posts code snippets copied directly out of "Starting Forth."
Her ARRAY is almost the same as the "Starting Forth" array but slightly tweaked
to provide range-checking, and screwed up with the lower index being 1.
Here is another example Elizabeth Rather gives of code from her book:
"Forth Application Techniques."
This STARS code-snippet is actually from: "Starting Forth."
On Friday, September 20, 2013 at 8:52:47 PM UTC-7, Elizabeth D. Rather wrote:
> Chuck basically invented stack comments, and insisted on
> their use when he was doing applications. FORTH, Inc. requires them, and
> the best programmers I've worked with for many years (alas, I haven't
> worked with Chuck since 1982) always include stack comments.
>
> For learners, stack comments are especially helpful, since by having to
> state them at the beginning of the definition they're led to focus on
> the stack going in and coming out, and the comment is there to remind
> them. One of the early simple exercises in Forth Application Techniques
> involves printing out [n] stars, which many define as:
>
> : STARS ( n -- ) 0 DO ." * " LOOP DROP ;
>
> The ones who include the stack comment are far less likely to just type
> STARS without an argument or forget the DROP at the end. But the
> consequences of forgetting the number are also a good teaching moment. ;-)
>
> Cheers,
> Elizabeth
Notice that the code doesn't work. The DROP at the end causes a stack underflow.
Elizabeth Rather just makes the Forth community look stupid!
I could write a better book on Forth than anything Forth Inc. has provided.
Actually, anybody with one week of training in Forth could do this,
assuming that the person has a three-digit I.Q..
It is not really worth my time to write a book on Forth programming.
I am not aware of anybody in the English-speaking world
who would be interested in learning Forth.
I would write a book if I could get it translated into another language.
Russian, Japanese or Spanish are all reasonable choices.
There are intelligent people who speak those languages.
I think Forth Inc. has ruined Forth's reputation in the English-speaking world.
Forth may have a future elsewhere though.
dxf...@gmail.com
Dec 30, 2018, 7:43:49 PM12/30/18
to
On Saturday, December 29, 2018 at 1:51:35 PM UTC+11, hughag...@gmail.com wrote:
> On Friday, December 28, 2018 at 6:23:33 PM UTC-7, dxf...@gmail.com wrote:
> > Standards, which are there to
> > support the interests of the mega-forths, are similarly doomed.
>
> This makes no sense!
>
> 1.) The purpose of a standard is to allow programs and code-libraries to be portable between different compatible systems.
> For this to work, there obviously have to be more than one system in use.
> So a standard is more useful for multiple small systems, rather than a few "mega-Forths."
What 'standard' systems are there today - probably less than came
> On Friday, December 28, 2018 at 6:23:33 PM UTC-7, dxf...@gmail.com wrote:
> > Standards, which are there to
> > support the interests of the mega-forths, are similarly doomed.
>
> This makes no sense!
>
> 1.) The purpose of a standard is to allow programs and code-libraries to be portable between different compatible systems.
> For this to work, there obviously have to be more than one system in use.
> So a standard is more useful for multiple small systems, rather than a few "mega-Forths."
into being immediately after ANS. If there's any new blood here,
it's systems that aren't aligned to a Forth standard.
>
> 2.) Neither Forth Inc. nor MPE are mega-sized companies.
> They are both very small companies.
> Even small plumbing companies employ an order of magnitude more people,
> and make an order of magnitude more money.
which they can't easily change and would have others implement,
right or wrong, via a standard to the extent they can each agree.
Vendors will always have the upper hand in a standard as they
can assert they have paying users to support. Your only choice
here is whether or not you accept what is being handed to you.
Anton Ertl
Dec 31, 2018, 1:08:27 PM12/31/18
to
alb...@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>I agree wholeheartedly, but the ultimate glueware at this moment is
>micropython. Our niche has been taken.
Well, two days ago I listened to a talk by an employee of the
>I agree wholeheartedly, but the ultimate glueware at this moment is
>micropython. Our niche has been taken.
Micropython company (George Robotics)
<https://fahrplan.events.ccc.de/congress/2018/Fahrplan/events/9648.html>,
and MicroPython is certainly trying to eat into that niche. One of
the early points she made is that MicroPython compiles on the target
and has a text interpreter (called REPL in the Lisp and Python
communities) for interactive work. But I did not find the rest of the
talk very threatening for Forth.
They offer their own boards, which may be a good approach to avoid
portability problems and also good for having a revenue stream.
And the Q&A part pretty much showed the limitations of MicroPython.
When asked about memory, she mentioned 128KB, when asked about speed,
she could not really decide what to say, talked quite a bit, mentioned
"100 times slower than C" once, and later mentioned "4 times", but
that speed is often not that important. When asked about ports to
AVR, she had to ask several times to repeat the name (I understood it
on first hearing, and I am not a microcontroller person).
My conclusion is that Micropython is a well-hyped language
implementation that is probably useful for teaching and to attract
Pythonheads to microcontrollers. For industrial usage, I guess it can
be useful for C projects that want some interactivity, but the cost in
RAM usage may be prohibitive for that role.
The overlap with Forth is relatively small: Forth does not offer
garbage collection and dynamic type-checking, MicroPython does not
offer speed and low memory consumption. Still, someone
marketing-minded might want to address the people who come to
microcontrollers thanks to the hype, and show them how much more one
can do on the same hardware with Forth. Most won't like Forth (too
strange, too uncivilized), but a few might convert.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2018: http://www.euroforth.org/ef18/
Manuel Rodriguez
Dec 31, 2018, 2:35:19 PM12/31/18
to
Am Montag, 31. Dezember 2018 19:08:27 UTC+1 schrieb Anton Ertl:
> <https://fahrplan.events.ccc.de/congress/2018/Fahrplan/events/9648.html>,
boring lecture, and the English was not that good. But with the correct
host, the situation is changing. Here, Siraj Raval himself explains what
Python really is, “Introduction - Learn Python for Data Science #1”
https://www.youtube.com/watch?v=T5pRlIbr6gg This guy has the right
attitude, he is motivated and has an army of 1 million followers at
youtube.
> <https://fahrplan.events.ccc.de/congress/2018/Fahrplan/events/9648.html>,
> But I did not find the rest of the
> talk very threatening for Forth.
It's right, before this kind of talk nobody has to be in fear. It was a
> talk very threatening for Forth.
boring lecture, and the English was not that good. But with the correct
host, the situation is changing. Here, Siraj Raval himself explains what
Python really is, “Introduction - Learn Python for Data Science #1”
https://www.youtube.com/watch?v=T5pRlIbr6gg This guy has the right
attitude, he is motivated and has an army of 1 million followers at
youtube.
Albert van der Horst
Dec 31, 2018, 2:55:29 PM12/31/18
to
In article <2018Dec3...@mips.complang.tuwien.ac.at>,
I was sold on the small board I tried out.
>
>The overlap with Forth is relatively small: Forth does not offer
>garbage collection and dynamic type-checking, MicroPython does not
>offer speed and low memory consumption. Still, someone
>marketing-minded might want to address the people who come to
>microcontrollers thanks to the hype, and show them how much more one
>can do on the same hardware with Forth. Most won't like Forth (too
>strange, too uncivilized), but a few might convert.
Before long one can no longer live without gc and behaviour that
adapts to data types. Adding a Forth to a Micro python would allow
speed and flexibility. People are working on that. For the outside
world it would be python.
>
>- anton
Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>alb...@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>>I agree wholeheartedly, but the ultimate glueware at this moment is
>>micropython. Our niche has been taken.
>
<SNIP>
>alb...@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>>I agree wholeheartedly, but the ultimate glueware at this moment is
>>micropython. Our niche has been taken.
>
>
>My conclusion is that Micropython is a well-hyped language
>implementation that is probably useful for teaching and to attract
>Pythonheads to microcontrollers. For industrial usage, I guess it can
>be useful for C projects that want some interactivity, but the cost in
>RAM usage may be prohibitive for that role.
Surely it is well-hyped. I was not sold on the hype though,
>My conclusion is that Micropython is a well-hyped language
>implementation that is probably useful for teaching and to attract
>Pythonheads to microcontrollers. For industrial usage, I guess it can
>be useful for C projects that want some interactivity, but the cost in
>RAM usage may be prohibitive for that role.
I was sold on the small board I tried out.
>
>The overlap with Forth is relatively small: Forth does not offer
>garbage collection and dynamic type-checking, MicroPython does not
>offer speed and low memory consumption. Still, someone
>marketing-minded might want to address the people who come to
>microcontrollers thanks to the hype, and show them how much more one
>can do on the same hardware with Forth. Most won't like Forth (too
>strange, too uncivilized), but a few might convert.
adapts to data types. Adding a Forth to a Micro python would allow
speed and flexibility. People are working on that. For the outside
world it would be python.
>
>- anton
Paul Rubin
Dec 31, 2018, 3:42:35 PM12/31/18
to
an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> When asked about memory, she mentioned 128KB
MicroPython works ok on a BBC Micro:bit which has 256k of program flash
> When asked about memory, she mentioned 128KB
and 16k of ram, though they had to struggle to fit in that little ram.
It's reasonably comfortable with 32k of ram. 128k of program flash
sounds kind of minimal. The Adafruit Trinket M0 uses a ATSAMD21E18
(256k flash, 32k ram) which is a 2 euro MCU in quantity, and it's nice
to use. The 256k flash is enough for the Python interpreter
(CircuitPython, Adafruit's hardware-oriented fork of MicroPython), REPL,
FAT file system, some libraries, and some space for user code and files.
You just plug the board into a USB port and it appears as two devices
simultaneously: a USB flash disk (so you can drag and drop files to it)
and a USB serial port, so you can type to the REPL. It is really an
easy and friendly way to get started with microcontrollers.
MicroPython also works ok on the ESP8266: there's lots of 3-4 euro
boards that have the MCU (128k ram, mostly used by the wifi stack) and a
few MB of SPI flash. The fancier ESP32 costs a little more but has two
200MHz CPU cores and 520k of ram. But, I haven't tried it on any of
these.
> when asked about speed, she could not really decide what to say,
> talked quite a bit, mentioned "100 times slower than C" once, and
> later mentioned "4 times", but that speed is often not that important.
in simple tests I've found MicroPython to be comparable to CPython. So
maybe 50x on average depending, compared to maybe 20x for threaded
Forth. Still not too bad imho.
> When asked about ports to AVR
> For industrial usage, I guess it can be useful for C projects that
> want some interactivity, but the cost in RAM usage may be prohibitive
> for that role.
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, 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.
> The overlap with Forth is relatively small: Forth does not offer
> garbage collection and dynamic type-checking, MicroPython does not
> offer speed and low memory consumption.
scripting wrapper for a bunch of C libraries, so the pure interpreter's
speed is not that important even for cpu-heavy tasks. For example,
Python is a favorite for numerical computation and machine learning
because of Numpy (a numerical linear algebra package, more or less) and
interfaces for libraries like Tensorflow. Your application just doesn't
spend much time in Python itself. It's also easy to write C extensions
for CPython if you have to speed up some bottleneck. I haven't tried
extending MicroPython but I believe it's similar.
I'd expect interpreted MicroPython on today's 3 dollar Cortex-M to be at
least as fast as threaded Forth on yesteryear's 3 dollar 8-bitter. That
does leave the issue of much larger ram consumption and possible GC
pauses interfering with realtime response. Whether that matters will be
application specific. I think the ESP8266 implementation may run the
MicroPython interpreter as a task under some kind of RTOS, so that it
can be preempted by the wifi stuff.
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.
> Still, someone marketing-minded might want to address the people who
> come to microcontrollers thanks to the hype, and show them how much
> more one can do on the same hardware with Forth.
hardware. E.g. ESP8266 MicroPython apparently has good integration with
the ESP8266 wifi stack. You'd have to do the same thing for Forth, and
then deal with the increased pain of writing network applications in
Forth, protecting them from malicious input causing buffer overflows,
and all that sort of thing.
I agree it would be nice if someone sold cheap MCU boards with a nice
Forth system already on them, so you could just plug one into a USB port
and start typing Forth commands. Jurgen Pintaske's 4e4th board was
along those lines.
Paul Rubin
Dec 31, 2018, 4:00:46 PM12/31/18
to
alb...@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
> Surely it is well-hyped. I was not sold on the hype though,
> I was sold on the small board I tried out.
You have a lolin32 right? How do you like it? Do you use the bluetooth
> Surely it is well-hyped. I was not sold on the hype though,
> I was sold on the small board I tried out.
from micropython and does it work? I found the esp32 hardware to be
very exciting, but didn't buy an early one because the software was then
supposedly not really complete. I don't know the current state of it.
I know the Adafruit esp32 pages still have a disclaimer about the
software.
Anton Ertl
Jan 1, 2019, 5:44:09 AM1/1/19
to
Paul Rubin <no.e...@nospam.invalid> writes:
>an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> When asked about memory, she mentioned 128KB
>
>MicroPython works ok on a BBC Micro:bit which has 256k of program flash
>and 16k of ram, though they had to struggle to fit in that little ram.
>It's reasonably comfortable with 32k of ram. 128k of program flash
>sounds kind of minimal. The Adafruit Trinket M0 uses a ATSAMD21E18
>(256k flash, 32k ram) which is a 2 euro MCU in quantity, and it's nice
>to use. The 256k flash is enough for the Python interpreter
>(CircuitPython, Adafruit's hardware-oriented fork of MicroPython), REPL,
>FAT file system, some libraries, and some space for user code and files.
...
>an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> When asked about memory, she mentioned 128KB
>
>MicroPython works ok on a BBC Micro:bit which has 256k of program flash
>and 16k of ram, though they had to struggle to fit in that little ram.
>It's reasonably comfortable with 32k of ram. 128k of program flash
>sounds kind of minimal. The Adafruit Trinket M0 uses a ATSAMD21E18
>(256k flash, 32k ram) which is a 2 euro MCU in quantity, and it's nice
>to use. The 256k flash is enough for the Python interpreter
>(CircuitPython, Adafruit's hardware-oriented fork of MicroPython), REPL,
>FAT file system, some libraries, and some space for user code and files.
>Like Forth, the speed difference will depend on what you're doing, but
>in simple tests I've found MicroPython to be comparable to CPython. So
>maybe 50x on average depending, compared to maybe 20x for threaded
>Forth.
Last time I measured threaded-code Forth systems (on a 486, but then
>in simple tests I've found MicroPython to be comparable to CPython. So
>maybe 50x on average depending, compared to maybe 20x for threaded
>Forth.
the performance characteristics of embedded CPUs are more like that of
a 486 than a current desktop CPU), the slowdown compared to hand-coded
C was 3.77-7.22 for Gforth (in 2000, so Gforth ~0.5.0), 6.62-11.18 for
Win32Forth, and 5.32-12.63 for eforth. Data from
<http://git.savannah.gnu.org/cgit/gforth.git/plain/timings.sc?id=495fd3359331c1db8d1f7f6719e00bc7f62b40f8>.
Also, with Forth you are not limited to threaded code. There are a
number of native-code Forths that work on embedded controllers, both
from commercial vendors and as free software (e.g., Mecrisp).
>If that means 8-bit AVR, it is not really feasible.
>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,
>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.
are microcontrollers for them), but there is a lot of room between
0.5KB flash and 256KB, and between 32 bytes of RAM and 16KB.
Mecrisp, a native-code system with the compiler on the target fits
into 11KB flash and 512 bytes RAM on an MSP430, 16KB flash and 1KB RAM
on ARM (Mecrisp-Stellaris).
And then there are systems where the compiler is on the host, and yet
they are interactive. Forth, Inc. calls this "tethered", while MPE
calls this "umbilical". <https://www.forth.com/embedded/> gives an
example where the system functions take 5582 bytes program (flash?)
and 766 bytes data (RAM) on a 16-bit CPU.
Interestingly, AFAIK only commercial systems went there. Either this
technology is too much work, or not fascinating enough for a
spare-time project.
>I'd expect interpreted MicroPython on today's 3 dollar Cortex-M to be at
>least as fast as threaded Forth on yesteryear's 3 dollar 8-bitter.
microcontroller is faster, and moreover, it also runs on the 8-bitter,
which costs less today.
>It would be a lot of work to do even the same things on the same
>hardware. E.g. ESP8266 MicroPython apparently has good integration with
>the ESP8266 wifi stack. You'd have to do the same thing for Forth, and
>then deal with the increased pain of writing network applications in
>Forth, protecting them from malicious input causing buffer overflows,
>and all that sort of thing.
many others) is "C", MicroPython has the same problems; probably more,
because C has idioms such as strcpy() that encourage such problems.
Albert van der Horst
Jan 1, 2019, 7:31:36 AM1/1/19
to
In article <877efp5...@nightsong.com>,
I tried out the wifi stuff. Could see as much networks as on my
tablet with a few Python commands and was impressed. I've
not done much more with the board lately, can you guess why?
Groetjes Albert
tablet with a few Python commands and was impressed. I've
not done much more with the board lately, can you guess why?
Groetjes Albert
Paul Rubin
Jan 1, 2019, 7:41:17 PM1/1/19
to
an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> a 486 than a current desktop CPU), the slowdown compared to hand-coded
> C was 3.77-7.22 for Gforth (in 2000, so Gforth ~0.5.0), 6.62-11.18 for
> Win32Forth, and 5.32-12.63 for eforth.
That eforth figure is pretty good, better than I'd have expected.
> a 486 than a current desktop CPU), the slowdown compared to hand-coded
> C was 3.77-7.22 for Gforth (in 2000, so Gforth ~0.5.0), 6.62-11.18 for
> Win32Forth, and 5.32-12.63 for eforth.
Note that MicroPython by default includes bignum arithmetic (it is
disabled in CircuitPython). I don't know if that affects the speed
much. But my MicroPython timings have it enabled. I might try building
and timing MicroPython with bignums turned off.
>>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,
> C uses a stack, too, and typically more. What gives?
and/or programmer can statically figure out how space the hardware stack
needs, and the compiler can put function locals and intermediate results
in registers. With interactive, interpreted Forth you need enough space
to accomodate the data and return stack space that the programmer MIGHT
want to use, and they normally both have to go in memory.
> Forth can use bytes or wider cells, as needed. What gives?
use 16 or 32 bit cells. So you do use 2x or 4x the memory for 8-bit
intermediate results. Yes you can do byte memory operations but that is
slightly contorted.
> I don't know if there are Forth systems for these sizes (or if there
> are microcontrollers for them), but there is a lot of room between
> 0.5KB flash and 256KB, and between 32 bytes of RAM and 16KB.
0.5k of ram. Going in 64x increments you can basically classify ram as:
1) tiny (under 0.5k); 2) small (0.5k to 32k); 3) medium (32k to 2 meg);
and 4) large (above 2 meg).
The natural tools to use at those sizes look to me like 1) C or
assembler; 2) Forth; 3) MicroPython etc.; 4) "big" Python, embedded
Linux etc.
So Forth is attractive in just one layer of that cake, and that layer is
getting (economically) thinner all the time.
> <https://www.forth.com/embedded/> gives an example where the system
> functions take 5582 bytes program (flash?) and 766 bytes data (RAM)
> on a 16-bit CPU. Interestingly, AFAIK only commercial systems went
> there. Either this technology is too much work, or not fascinating
> enough for a spare-time project.
last year, but had to put it aside because of something urgent that came
up then. I might get back to it sometime. It was not going to be
anywhere near as fancy as the commercial systems. The host side is
written in Python and the target side in C. The target side code is
about 2k bytes compiled with SDCC.
>>I'd expect interpreted MicroPython on today's 3 dollar Cortex-M to be at
>>least as fast as threaded Forth on yesteryear's 3 dollar 8-bitter.
>
> Maybe, but why would that be relevant? Forth on today's $3
> microcontroller is faster, and moreover, it also runs on the 8-bitter,
> which costs less today.
development time by using a $3 32-bitter with 32k ram instead of a $1
8-bitter with 0.5k, they will pay the extra $2 to save the time. If a
product designer making something that will ship in high quantity can
spend extra time to use a 50-cent 8-bitter with 64 bytes of ram instead
of a $1 8-bitter with 0.5k, they will spend the time to save the 50
cents * N units. This is what I mean about Forth's layer getting
thinner.
> Well, given that MicroPython's answer to the performance question (and
> many others) is "C", MicroPython has the same problems; probably more,
> because C has idioms such as strcpy() that encourage such problems.
been "assembler", to the point where traditional Forths had built-in
assemblers and CODE words. Optimizing Forth compilers competitive with
C arrived fairly recently Forth's history. They do change the picture
somewhat though.
Actually it looks like micropython can generate native code for more
speed at the expense of code space, and optionally giving up bignums:
http://docs.micropython.org/en/latest/reference/speed_python.html#the-native-code-emitter
a...@littlepinkcloud.invalid
Jan 2, 2019, 6:30:24 AM1/2/19
to
Paul Rubin <no.e...@nospam.invalid> wrote:
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.
> an...@mips.complang.tuwien.ac.at (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
>
> 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,
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.
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.
something, you're quite likely to be at the sharp end of real
time.
Andrew.
Яна Коваленко
Oct 31, 2022, 9:44:27 AM10/31/22
to
середа, 2 січня 2019 р. о 11:30:24 UTC a...@littlepinkcloud.invalid пише:
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.
jem...@gmail.com
Nov 6, 2022, 7:12:48 AM11/6/22
to
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.
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.
Jurgen Pitaske
Nov 6, 2022, 9:44:55 AM11/6/22
to
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.
dxforth
Nov 6, 2022, 7:50:43 PM11/6/22
to
On 6/11/2022 11:12 pm, jem...@gmail.com 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
> 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.
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.
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.
Ron AARON
Nov 7, 2022, 12:11:20 AM11/7/22
to
On 07/11/2022 2:50, dxforth wrote:
> On 6/11/2022 11:12 pm, jem...@gmail.com 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.
jem...@gmail.com
Nov 7, 2022, 4:51:27 AM11/7/22
to
- 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?
shtps
Nov 10, 2022, 9:49:37 AM11/10/22
to
> 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.
Hans Bezemer
Dec 6, 2022, 5:07:53 AM12/6/22
to
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
> He goes through a lot of things and he uses the return stack for control
> flow towards the end.
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
The Daily Info
Sep 8, 2023, 1:29:39 AM9/8/23
to
The Fitness Idea
Oct 8, 2023, 10:53:47 AM10/8/23
to
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
> 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
minforth
Oct 9, 2023, 8:09:30 AM10/9/23
to
PC world by order of magnitudes, and wherein Forth really shines.
Zbig
Oct 9, 2023, 9:58:01 AM10/9/23
to
> > > 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
> You forgot the world of MCUs and embedded devices, that surpass the
> PC world by order of magnitudes, and wherein Forth really shines.
of posting his spam: instead of creating new thread — chaining to
exisiting ones.
dxf
Oct 9, 2023, 10:27:35 AM10/9/23
to
Zbig
Oct 9, 2023, 11:32:34 AM10/9/23
to
> 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. ;)
Message has been deleted
AssignmentOverflow Support (AssignmentOverflow.com)
Feb 2, 2024, 1:41:10 PMFeb 2
to
The idea that "Forth is the programming language of the future" presents an intriguing perspective on the evolution of programming languages. Forth, with its minimalist approach and emphasis on direct hardware control, indeed offers a stark contrast to more contemporary languages like Go, which prioritize ease of use and extensive standard libraries.
Forth's philosophy of providing a blank slate, free of predefined standards and libraries, empowers developers with unparalleled freedom. This environment encourages a deep, fundamental understanding of programming principles and hardware interaction. It's a throwback to the roots of computing, where programmers had to intimately understand every aspect of their machines.
However, the high degree of control and flexibility comes at the cost of accessibility. For newcomers, the steep learning curve and the lack of readily available resources can be daunting. This is where the concept of structured programming assistance becomes crucial. For those intrigued by the potential of Forth but unsure where to start, or for seasoned programmers looking to deepen their expertise, having access to a supportive community and expert guidance can make all the difference.
Our platform, https://assignmentoverflow.com, is designed to bridge this gap. We provide comprehensive support and resources for a wide range of programming challenges and languages, including niche ones like Forth. Whether you're tackling a complex Forth project, venturing into programming for the first time, or looking to expand your skill set, we offer personalized assistance to help you achieve your goals.
In embracing Forth's philosophy, we recognize the value of mastering the fundamentals and pushing the boundaries of what's possible. But we also understand the importance of accessibility and support in fostering innovation and growth in the programming community. As we look to the future, blending Forth's pioneering spirit with the collaborative, resource-rich environment of platforms like ours might just be the key to unlocking new technological frontiers.
Forth's philosophy of providing a blank slate, free of predefined standards and libraries, empowers developers with unparalleled freedom. This environment encourages a deep, fundamental understanding of programming principles and hardware interaction. It's a throwback to the roots of computing, where programmers had to intimately understand every aspect of their machines.
However, the high degree of control and flexibility comes at the cost of accessibility. For newcomers, the steep learning curve and the lack of readily available resources can be daunting. This is where the concept of structured programming assistance becomes crucial. For those intrigued by the potential of Forth but unsure where to start, or for seasoned programmers looking to deepen their expertise, having access to a supportive community and expert guidance can make all the difference.
Our platform, https://assignmentoverflow.com, is designed to bridge this gap. We provide comprehensive support and resources for a wide range of programming challenges and languages, including niche ones like Forth. Whether you're tackling a complex Forth project, venturing into programming for the first time, or looking to expand your skill set, we offer personalized assistance to help you achieve your goals.
In embracing Forth's philosophy, we recognize the value of mastering the fundamentals and pushing the boundaries of what's possible. But we also understand the importance of accessibility and support in fostering innovation and growth in the programming community. As we look to the future, blending Forth's pioneering spirit with the collaborative, resource-rich environment of platforms like ours might just be the key to unlocking new technological frontiers.
minforth
Feb 3, 2024, 3:05:54 AMFeb 3
to
Never thought that chatgpt was that bad..
mhx
Feb 3, 2024, 4:05:56 AMFeb 3
to
minforth wrote:
> Never thought that chatgpt was that bad..
According to https://www.zerogpt.com/ : "Your Text is AI/GPT Generated : 86.27%"
> Never thought that chatgpt was that bad..
-marcel
0 new messages