> One such property is the use of reverse polish notation
and the lack or eschewal of local variables.
What do you gain by eschewing local variables in favor of reverse polish notation that throws values onto a stack?
Thoughts on Forth Programming
21–30 of 97 posts
Re: Thoughts on Forth Programming
#22Re: Thoughts on Forth Programming
#23Earlier quoted context omitted.
Chuck Moore wrote a VLSI tool in 500 lines of colorForth that he's used for multiple chips that he's put on production lines: (Site mirror as the original site is gone.) https://colorforth.github.io/vlsi.html John Earnest has a lot of cool things (his work is incredibly underrated), but an example of something he wrote in Forth is Mako, an entire console: https://github.com/JohnEarnest/Mako During the days of the U.S…
Do you know of any good code repositories for DSSP?
DSSP is effectively a dead language. There are a few interpreters, but for a long time there weren't, so there hasn't been much code for decades now. It died with the U.S.S.R., like many innovations in computing did.
Re: Thoughts on Forth Programming
#24Earlier quoted context omitted.
Chuck Moore wrote a VLSI tool in 500 lines of colorForth that he's used for multiple chips that he's put on production lines: (Site mirror as the original site is gone.) https://colorforth.github.io/vlsi.html John Earnest has a lot of cool things (his work is incredibly underrated), but an example of something he wrote in Forth is Mako, an entire console: https://github.com/JohnEarnest/Mako During the days of the U.S…
Do you know of any good code repositories for DSSP?
I wondered too (first I've heard of this) but all I find is in Cyrillic: https://github.com/trinarium/DSSP-C
I did find one short paper in English: http://www.complang.tuwien.ac.at/anton/euroforth/ef00/lyakin...
Re: Thoughts on Forth Programming
#25[deleted]
I would've agreed, but there are annoyingly arbitrary line breaks in the middle of sentences. A more minimalist approach would call for breaking only at the end of sentences, and letting the user's browser wrap in whichever way they preferred their window size + custom stylesheets + plugins to be
[deleted]
Re: Thoughts on Forth Programming
#26I have been looking at Forth programming and one thing I would like to figure out is how to use gforth under Linux in a pipeline of shell and awk. I haven't yet found a practical use for Forth in this environment yet...
Re: Thoughts on Forth Programming
#27Earlier quoted context omitted.
Do you know of any good code repositories for DSSP?
I wondered too (first I've heard of this) but all I find is in Cyrillic: https://github.com/trinarium/DSSP-C I did find one short paper in English: http://www.complang.tuwien.ac.at/anton/euroforth/ef00/lyakin...
Here's an interpreter with docs in English:
Re: Thoughts on Forth Programming
#28Earlier quoted context omitted.
In FORTH there is a distinction between the compiler and the interpreter. Each function in FORTH is called a "word". You define a word by giving it a name (historically only the first X characters counted -- often 8). The compiled words are stored in a "dictionary" which is essentially a key value pair with the name of a compiled word and a pointer to its compiled code. When you are compiling a word, you add a new en…
It the kernel and interpreter typically single threaded? I'm curious how it handles UARTs, IRQs and atomics.
Here's a good doc on multitasking in FORTH: https://www.bradrodriguez.com/papers/mtasking.html
Re: Thoughts on Forth Programming
#29Earlier quoted context omitted.
This can work, but it's incredibly tedious and not worth the trouble. Writing in Forth is like writing in pure CIL or JVM bytecode (they're both stack machines like Forth). Sure, you can do it, but if it was so rewarding, people wouldn't be using Java or C#.
That's not true at all. I know multiple people who are incredibly productive in Forth environments, though I don't use it myself. Pretending that it's like writing in JVM bytecode (despite some overlap between the two) is completely unfounded. Your claim that C# and Java won based on merits is similarly unfounded: they won because they have major corporate backing. There are countless languages before and after that…
I've met a couple of really good FORTH programmers over the years. They were humble about it, were also happy to use other tools in their work, and they just happened to be working on projects that were really good fits for FORTH's strengths.
I've met a lot more FORTH fanatics, people for whom FORTH was the answer no matter the problem; people who just would not shut up about how superior and fantastic it was, and have you seen the light, brother? Okay, most of them weren't that bad, but a few were (one guy I worked with got fired because (a) he told his boss that FORTH was all he was going to use, (b) the FORTH runtime was over half of his code budget and he had kinda been keeping that secret, and (c) none of that fantastically FORTH code was compatible with the ROM it needed to run on . . . so you can imagine that fun little tete a tete).
Whatever the languages's wins or faults, it's still a great idea to write your own FORTH at some point. It's a ton of fun, and quite instructive when you've gotten a fully functional programming environment that fits in a few tens of kilobytes.
Re: Thoughts on Forth Programming
#30I have been looking at Forth programming and one thing I would like to figure out is how to use gforth under Linux in a pipeline of shell and awk. I haven't yet found a practical use for Forth in this environment yet...
Forth isn't super practical in such an environment; gForth in particular is a bit "large". (Not that this is bad, but it's of the second school the article mentions.)
If you wanted, you could cobble together a Forth implementation that played nicely with pipes. I did this, it works fine, but it's not the type of environment that matches Forth very well.
Forth's design is to give you the machine and let you compute with it rather than to act as part of a pipeline.