I appreciate Yossi's plain honesty in this article, and it's a fun and interesting read; I've read it before.
I can relate to, but not endorse, designing a CPU and dialect for an interesting language you've never properly used. This turned out to be very painful, and Yossi argues convincingly that it is essentially not practical to use Forth at all, debating Jeff Fox's position. However, there is some evidence[1] that Forth actually might be practical, and it certainly seemed to have a niche in the 80's.
Yossi made some errors I've seen among new Forth programmers. A lot of people, before writing real programs, think Forth is like lisp from another universe. They visualise Forth primarily as a sort-of functional, concatenative, highly refactor-focused language. They likewise tend to throw out all the normal Forth defining words and use Forth as 'lisp without parentheses'. They try and put all their data on the stack, 'point-free', rather than using variables. And often their projects eventually devolve into C envy, every line with stack comments and equivalent C code to help, as shown in the article.
But go look at real, working, classic Forth code, of which there is much, and you'll see that there is a prevailing style that's easy to read and not actually that 'smart', or 'academic'. No more than 1-2 stack items need to be mentally 'juggled' for 99% of code, lots of variables and buffers are used whenever it's easier. Yes the classic variables are 'global', but it doesn't matter if the relevant code isn't recursing or touched in interrupts, and is only used by a cluster of related words. Newer Forths do have local variables, in spite of Jeff Fox's disapproval!
The classic code I'm talking about matches what I think Jeff Fox is trying to coerce you towards. Ultimately I disagree with Yossi's views because I think if he had actually tried to implement what Jeff Fox proposes, and got some practice first on a more realistic project, he would have had a much better shot. It's impressive how well the project turned out in spite of the approach, and how Yossi wrote a backend for his architecture in a week: a testament to both his skills and LLVM's design; but it's worth reflecting as engineers how arrogant (yet relatable) it is to make a CPU and compiler for a language you've never properly used.
I can relate to, but not endorse, designing a CPU and dialect for an interesting language you've never properly used. This turned out to be very painful, and Yossi argues convincingly that it is essentially not practical to use Forth at all, debating Jeff Fox's position. However, there is some evidence[1] that Forth actually might be practical, and it certainly seemed to have a niche in the 80's.
Yossi made some errors I've seen among new Forth programmers. A lot of people, before writing real programs, think Forth is like lisp from another universe. They visualise Forth primarily as a sort-of functional, concatenative, highly refactor-focused language. They likewise tend to throw out all the normal Forth defining words and use Forth as 'lisp without parentheses'. They try and put all their data on the stack, 'point-free', rather than using variables. And often their projects eventually devolve into C envy, every line with stack comments and equivalent C code to help, as shown in the article.
But go look at real, working, classic Forth code, of which there is much, and you'll see that there is a prevailing style that's easy to read and not actually that 'smart', or 'academic'. No more than 1-2 stack items need to be mentally 'juggled' for 99% of code, lots of variables and buffers are used whenever it's easier. Yes the classic variables are 'global', but it doesn't matter if the relevant code isn't recursing or touched in interrupts, and is only used by a cluster of related words. Newer Forths do have local variables, in spite of Jeff Fox's disapproval!
The classic code I'm talking about matches what I think Jeff Fox is trying to coerce you towards. Ultimately I disagree with Yossi's views because I think if he had actually tried to implement what Jeff Fox proposes, and got some practice first on a more realistic project, he would have had a much better shot. It's impressive how well the project turned out in spite of the approach, and how Yossi wrote a backend for his architecture in a week: a testament to both his skills and LLVM's design; but it's worth reflecting as engineers how arrogant (yet relatable) it is to make a CPU and compiler for a language you've never properly used.
[1] https://www.hardware-x.com/article/S2468-0672(22)00025-6/ful...