5 ms·

My history with Forth and stack machines (2010)

95 points by panic 6y ago

veltas 6y ago
> ...it is scripting that is the best trojan horse for pushing a language into an organization. Scripting is usually mission-critical without being acknowledged as such, and many scripts are small and standalone. Look how many popular "scripting languages" there are as opposed to "systems programming languages". Then normalize it by the amount of corporate backing a language got on its way to popularity. Clearly scripting is the best trojan horse.
jstanley 6y ago
This was a really interesting article. I appreciate the author's matter-of-fact style, and the way he communicates his own thoughts without trying to say they're the only correct thoughts. And despite the author's own experiences, I came away thinking that I would actually like to try writing something in Forth myself. Even though I like "C". This description really resonated with me: > being able to do what at least 3 people in their respective areas normally do, and concentrating on those 3 things at the same time. Doing the cross-layer global optimization. I at least desire to be competent at that level, and think I'd enjoy having a go.
- jacquesm 6y ago
  Forth is an interesting language but if you are used to modern stuff it is likely going to be an exercise in frustration to get 'something done' unless 'something' happens to be a small soft real time project. So I suggest you start with that and then take it from there.
macintux 6y ago
This really is an interesting article, and much of the introduction aligns with my experience: I love the concept, wish I had a reason to use Forth, but also I'm not and never have been a hardware person and haven't the foggiest clue what to do with it. For anyone who isn't familiar with the language, Thinking Forth[1] and Starting Forth[2] are (as far as I know) well-regarded books on the subject. [1]: http://thinking-forth.sourceforge.net http://thinking-forth.sourceforge.net [2]: https://www.forth.com/starting-forth/ https://www.forth.com/starting-forth/ Also, for anyone like me who dearly misses W. Richard Stevens, he wrote a Forth primer in the 70s. You can find it any several other documents on forth.org[3]. [3]: http://forth.org/tutorials.html http://forth.org/tutorials.html Previous discussions of this post over the years: https://news.ycombinator.com/item?id=3963896 https://news.ycombinator.com/item?id=3963896 https://news.ycombinator.com/item?id=8146306 https://news.ycombinator.com/item?id=8146306 https://news.ycombinator.com/item?id=8869150 https://news.ycombinator.com/item?id=8869150 https://news.ycombinator.com/item?id=21153555 https://news.ycombinator.com/item?id=21153555
- jlg23 6y ago
  > I love the concept, wish I had a reason to use Forth, but also I'm not and never have been a hardware High level & easy: chat bots. I have implemented a forth interpreter in several bots I wrote (admins only, for obvious reasons ;). Since they are running within the bot's code, you have as much access to the client's state as you allow/implement.
- mumblemumble 6y ago
  re:factor is a nice blog for seeing how higher-level things can be done in a concatenative language. It's been dormant for a couple years, but the archives have some interesting examples of redoing well-known stuff in Factor. https://re-factor.blogspot.com/ https://re-factor.blogspot.com/ For example, here's a gopher server: https://re-factor.blogspot.com/2016/10/gopher-server.html https://re-factor.blogspot.com/2016/10/gopher-server.html
- ranma42 6y ago
  In that context, mecrisp forth on a small micro[1] for doing simple embedded/sensor programming sounds like something I should try sometime... [1] https://jeelabs.org/article/1705c/ https://jeelabs.org/article/1705c/
vok 6y ago
Does anyone know of other places where the word "flow" is used like this?: > Good Forth programmers arrange things so that they flow on the stack. I think this concept of "flow" applies elsewhere, for example when creating tacit programs in J. But I haven't seen "flow" used like this anywhere except this article.
- guerrilla 6y ago
  At the same time it reminds me of tacit programming/point-free style[1] in general and dataflow[2] programming. 1. https://en.wikipedia.org/wiki/Tacit_programming https://en.wikipedia.org/wiki/Tacit_programming 2. https://en.wikipedia.org/wiki/Dataflow_programming https://en.wikipedia.org/wiki/Dataflow_programming
peter_d_sherman 6y ago
>"To this day, I find it shocking that you can define defining words like CONSTANT, FIELD, CLASS, METHOD – something reserved to built-in keywords and syntactic conventions in most languages – and you can do it so compactly using such crude facilities so trivial to implement. Back when I first saw this, I didn't know about DEFMACRO and how it could be used to implement the defining words of CLOS such as DEFCLASS and DEFMETHOD (another thing about Lisp they don't teach in schools). So Forth was completely mind-blowing." It is, isn't it? Forth is sort of "the next level up" from assembler, in the language abstraction hierarchy... First you have switches... Then you have punched cards... Then you have a simple assembler that converts files of numbers into machine code. Then you have a simple assembler that converts files of instruction symbols (operands/mnemonics) and numbers into machine code. From there, you might have assemblers that understand global variables and labels/addresses in memory (necessary for function calls), etc. Forth starts to come into existence when you take a later (in evolution/time) assembler's symbol (aka "function name") address look-up table for functions -- and implement it dynamically (with the ability to add to it) at run-time. That's because the initial Forth tokens/symbols (it's "primitives") -- are CALLs to static pre-defined assembler routines (or would have been in the first version of forth) -- with the ability to define new tokens/symbols -- in terms of combinations of executions the previous ones... To make all of this magic happen, you need to separate the "CPU provided" single stack (well, at least if we're thinking Intel, which may have not been the case with early CPU's) -- into two stacks, one for data, one as a call (function return) stack, and this is exactly what Forth does. Forth exposes the data stack to do whatever you want with, to you the programmer. Now, when we get to Lisp (the next level up from Forth, in my opinion) -- Lisp does two additional things, which are A) Takes the ability to monkey with any stack, away from the programmer. B) Implements the management of LISTS -- whose management (memory management, pointers, etc.) the programmer no longer needs to worry about (think of this as a pattern from mathematics, N, that is, 'multiples', 'batches', 'vectors' ("more than one thing of") -- meets Forth's ability to work with single symbols -- well there has to be a convenient data structure to work with multiple symbols (and data, which now there is a demarcation of in LISP) at a time -- and that way LISP provides, with it's "I'll manage the stack and the lists (at least the memory/structure/pointers of the list) for you, so you the programmer don't need to worry about any of that! So yes, Forth is brilliant and fascinating in its simplicity... I wouldn't write million-line business applications in it, because as a programmer, I am not perfect, I make mistakes, and I tend to like type-checking, automatic stack management, and other things that modern compilers provide. But Forth is utterly brilliant from a "how did Computer languages evolve" / "how could a computer 'pull itself up by its bootstraps' perspective"... It's highly worthwhile for any programmer to learn about...
picks_at_nits 6y ago
"When you're holding a Shunting Yard Algorithm, every Domain-Specific Expression Language looks like a compile-to-RPN-and-evaluate-with-a-stack-machine nail." https://en.wikipedia.org/wiki/Shunting-yard_algorithm https://en.wikipedia.org/wiki/Shunting-yard_algorithm
gsmecher 6y ago
I return to this essay about once a year, when I hear the siren-song of minimalism and am tempted to implement a Forth CPU. It's situated exactly in the no-mans'-land between FORTH and "C" camps and effortlessly slides between pragmatic and idealistic considerations. It emphasizes the distinction between the lure of toolbuilding (making a Forth, making a CPU) and actually solving the problems these tools are intended to solve. The comments on word sizes and problem-shifting are spot-on. It's an excellent essay, and I wish there were more like it. By day, I'm an FPGA coder. (The ASIC situation rhymes, more or less.) From the perspective of implementing small CPU architectures: register files are not the problem in the way you'd expect. A modern FPGA has primitives that implement 32- or 64-register files with remarkable efficiency, in 2-, 4-, or 8-port varieties. Midrange FPGAs are now fast enough that a lightly pipelined RISC CPU performs well enough; there's no need to aggressively pipeline a CPU for normal clock rates (100 to 250 MHz) any more, and little motivation for exotic architectures. The MicroBlaze (Xilinx) or NIOS-II (Altera) soft core CPUs are so boringly effective they've forced ARM to license their designs for FPGAs for free. For smaller state-machine-class problems, the PicoBlaze is an interesting, minimal RISC. For most of us, CPUs are solved problems and the frontier has shifted towards cache-coherency, networking and other more interesting arenas. I love the idea of stack machines in the right contexts (PostScript, FORTH, Java, you name it), but it's hard to disagree with the essay's conclusions.
deleted 6y ago
[deleted]
tailrecursion 6y ago
I wrote a couple Forth compilers for the Forth chips of the 80s. Yossi (the author) does a great job conveying how attractive Forth can be, and also how it fails to encode algorithms that are less than dead simple. I wonder how much of the stack manipulation problem could be solved with say four register words A, B, C, D (and A!, B!, C!, and D!) that access registers understood not to be trashed by primitives (CODE words) but might be trashed by definitions (COLON words). Otherwise, once you start trying to fix these problems, you end up with Scheme.

95 points by panic 6y ago

> ...it is scripting that is the best trojan horse for pushing a language into an organization. Scripting is usually mission-critical without being acknowledged as such, and many scripts are small and standalone. Look how many popular "scripting languages" there are as opposed to "systems programming languages". Then normalize it by the amount of corporate backing a language got on its way to popularity. Clearly scripting is the best trojan horse.

jstanley 6y ago

This was a really interesting article. I appreciate the author's matter-of-fact style, and the way he communicates his own thoughts without trying to say they're the only correct thoughts. And despite the author's own experiences, I came away thinking that I would actually like to try writing something in Forth myself. Even though I like "C". This description really resonated with me: > being able to do what at least 3 people in their respective areas normally do, and concentrating on those 3 things at the same time. Doing the cross-layer global optimization. I at least desire to be competent at that level, and think I'd enjoy having a go.

jacquesm 6y ago
Forth is an interesting language but if you are used to modern stuff it is likely going to be an exercise in frustration to get 'something done' unless 'something' happens to be a small soft real time project. So I suggest you start with that and then take it from there.

macintux 6y ago

This really is an interesting article, and much of the introduction aligns with my experience: I love the concept, wish I had a reason to use Forth, but also I'm not and never have been a hardware person and haven't the foggiest clue what to do with it. For anyone who isn't familiar with the language, Thinking Forth[1] and Starting Forth[2] are (as far as I know) well-regarded books on the subject. [1]: http://thinking-forth.sourceforge.net http://thinking-forth.sourceforge.net [2]: https://www.forth.com/starting-forth/ https://www.forth.com/starting-forth/ Also, for anyone like me who dearly misses W. Richard Stevens, he wrote a Forth primer in the 70s. You can find it any several other documents on forth.org[3]. [3]: http://forth.org/tutorials.html http://forth.org/tutorials.html Previous discussions of this post over the years: https://news.ycombinator.com/item?id=3963896 https://news.ycombinator.com/item?id=3963896 https://news.ycombinator.com/item?id=8146306 https://news.ycombinator.com/item?id=8146306 https://news.ycombinator.com/item?id=8869150 https://news.ycombinator.com/item?id=8869150 https://news.ycombinator.com/item?id=21153555 https://news.ycombinator.com/item?id=21153555

jlg23 6y ago
> I love the concept, wish I had a reason to use Forth, but also I'm not and never have been a hardware High level & easy: chat bots. I have implemented a forth interpreter in several bots I wrote (admins only, for obvious reasons ;). Since they are running within the bot's code, you have as much access to the client's state as you allow/implement.
mumblemumble 6y ago
re:factor is a nice blog for seeing how higher-level things can be done in a concatenative language. It's been dormant for a couple years, but the archives have some interesting examples of redoing well-known stuff in Factor. https://re-factor.blogspot.com/ https://re-factor.blogspot.com/ For example, here's a gopher server: https://re-factor.blogspot.com/2016/10/gopher-server.html https://re-factor.blogspot.com/2016/10/gopher-server.html
ranma42 6y ago
In that context, mecrisp forth on a small micro[1] for doing simple embedded/sensor programming sounds like something I should try sometime... [1] https://jeelabs.org/article/1705c/ https://jeelabs.org/article/1705c/

vok 6y ago

Does anyone know of other places where the word "flow" is used like this?: > Good Forth programmers arrange things so that they flow on the stack. I think this concept of "flow" applies elsewhere, for example when creating tacit programs in J. But I haven't seen "flow" used like this anywhere except this article.

guerrilla 6y ago
At the same time it reminds me of tacit programming/point-free style[1] in general and dataflow[2] programming. 1. https://en.wikipedia.org/wiki/Tacit_programming https://en.wikipedia.org/wiki/Tacit_programming 2. https://en.wikipedia.org/wiki/Dataflow_programming https://en.wikipedia.org/wiki/Dataflow_programming

peter_d_sherman 6y ago

>"To this day, I find it shocking that you can define defining words like CONSTANT, FIELD, CLASS, METHOD – something reserved to built-in keywords and syntactic conventions in most languages – and you can do it so compactly using such crude facilities so trivial to implement. Back when I first saw this, I didn't know about DEFMACRO and how it could be used to implement the defining words of CLOS such as DEFCLASS and DEFMETHOD (another thing about Lisp they don't teach in schools). So Forth was completely mind-blowing." It is, isn't it? Forth is sort of "the next level up" from assembler, in the language abstraction hierarchy... First you have switches... Then you have punched cards... Then you have a simple assembler that converts files of numbers into machine code. Then you have a simple assembler that converts files of instruction symbols (operands/mnemonics) and numbers into machine code. From there, you might have assemblers that understand global variables and labels/addresses in memory (necessary for function calls), etc. Forth starts to come into existence when you take a later (in evolution/time) assembler's symbol (aka "function name") address look-up table for functions -- and implement it dynamically (with the ability to add to it) at run-time. That's because the initial Forth tokens/symbols (it's "primitives") -- are CALLs to static pre-defined assembler routines (or would have been in the first version of forth) -- with the ability to define new tokens/symbols -- in terms of combinations of executions the previous ones... To make all of this magic happen, you need to separate the "CPU provided" single stack (well, at least if we're thinking Intel, which may have not been the case with early CPU's) -- into two stacks, one for data, one as a call (function return) stack, and this is exactly what Forth does. Forth exposes the data stack to do whatever you want with, to you the programmer. Now, when we get to Lisp (the next level up from Forth, in my opinion) -- Lisp does two additional things, which are A) Takes the ability to monkey with any stack, away from the programmer. B) Implements the management of LISTS -- whose management (memory management, pointers, etc.) the programmer no longer needs to worry about (think of this as a pattern from mathematics, N, that is, 'multiples', 'batches', 'vectors' ("more than one thing of") -- meets Forth's ability to work with single symbols -- well there has to be a convenient data structure to work with multiple symbols (and data, which now there is a demarcation of in LISP) at a time -- and that way LISP provides, with it's "I'll manage the stack and the lists (at least the memory/structure/pointers of the list) for you, so you the programmer don't need to worry about any of that! So yes, Forth is brilliant and fascinating in its simplicity... I wouldn't write million-line business applications in it, because as a programmer, I am not perfect, I make mistakes, and I tend to like type-checking, automatic stack management, and other things that modern compilers provide. But Forth is utterly brilliant from a "how did Computer languages evolve" / "how could a computer 'pull itself up by its bootstraps' perspective"... It's highly worthwhile for any programmer to learn about...

picks_at_nits 6y ago

"When you're holding a Shunting Yard Algorithm, every Domain-Specific Expression Language looks like a compile-to-RPN-and-evaluate-with-a-stack-machine nail." https://en.wikipedia.org/wiki/Shunting-yard_algorithm https://en.wikipedia.org/wiki/Shunting-yard_algorithm

gsmecher 6y ago

I return to this essay about once a year, when I hear the siren-song of minimalism and am tempted to implement a Forth CPU. It's situated exactly in the no-mans'-land between FORTH and "C" camps and effortlessly slides between pragmatic and idealistic considerations. It emphasizes the distinction between the lure of toolbuilding (making a Forth, making a CPU) and actually solving the problems these tools are intended to solve. The comments on word sizes and problem-shifting are spot-on. It's an excellent essay, and I wish there were more like it. By day, I'm an FPGA coder. (The ASIC situation rhymes, more or less.) From the perspective of implementing small CPU architectures: register files are not the problem in the way you'd expect. A modern FPGA has primitives that implement 32- or 64-register files with remarkable efficiency, in 2-, 4-, or 8-port varieties. Midrange FPGAs are now fast enough that a lightly pipelined RISC CPU performs well enough; there's no need to aggressively pipeline a CPU for normal clock rates (100 to 250 MHz) any more, and little motivation for exotic architectures. The MicroBlaze (Xilinx) or NIOS-II (Altera) soft core CPUs are so boringly effective they've forced ARM to license their designs for FPGAs for free. For smaller state-machine-class problems, the PicoBlaze is an interesting, minimal RISC. For most of us, CPUs are solved problems and the frontier has shifted towards cache-coherency, networking and other more interesting arenas. I love the idea of stack machines in the right contexts (PostScript, FORTH, Java, you name it), but it's hard to disagree with the essay's conclusions.

deleted 6y ago

[deleted]

tailrecursion 6y ago

I wrote a couple Forth compilers for the Forth chips of the 80s. Yossi (the author) does a great job conveying how attractive Forth can be, and also how it fails to encode algorithms that are less than dead simple. I wonder how much of the stack manipulation problem could be solved with say four register words A, B, C, D (and A!, B!, C!, and D!) that access registers understood not to be trashed by primitives (CODE words) but might be trashed by definitions (COLON words). Otherwise, once you start trying to fix these problems, you end up with Scheme.