29 ms·

I try to avoid them too, but sometimes business requirements are just too particular to do so.

astrobe_ 11y ago
It sure can be a problem when you have to deal with "business requirements" that you can't change, because in Forth you look for simplifications at every level. Dealing with that may require to thing out of the box a bit, and forget about what is "good" and "bad" in other languages. Maybe you can use table-driven programming? Maybe you can do some dirty tricks with the return stack to get the control-flow you want? Maybe you really have to put that data in a variable? There's no single answer, and it can get ugly at times. Not, BTW, ugly like in the article. This: > : apply2 rot dup rot dip rot apply swap ; ... is an abomination. "dip" is questionable already. "rot", thought part of the standard, is best avoided. Because one should only deal with the top two elements of the stack. And of course "apply2" itself is suspicious. Why the author showed this, even though he seems knowledgeable enough to know that he shouldn't? Because he picked a simplified Forth that did not let him use the return stack. The author sure talks a lot about the "Forth philosophy" but apparently missed one or two things about it. If one wants to talk about philosophy, one should at least include in the bibliography what his inventor says about Forth (http://www.ultratechnology.com/forth0.htm http://www.ultratechnology.com/forth0.htm - a lot of stuff there, the main piece being 1xForth). I believe it's Moore that said something like "The important thing is not what you add, but what you remove". The return stack is a core component of Forth; picking a "simplified" Forth that won't let you use it ... well that language shouldn't be called Forth to begin with. That's a bad choice. There are also other questionable choices like using [ ] for "quotations" when they are used for something totally different in standard Forth. Introducing "quotations" is also questionable in itself. It only looks easily implemented because Ruby provides all the memory management; but in reality implementing an interpreter on top of an interpreter is not viable (that makes like at least a x1000 slowdown relative to C); Forth interpreters are typically written in low level compiled languages (typically C), which don't provide garbage collection. And in the end, those "quotations" only look cute. What really helps is currying. Forth is ugly, stupid and mean. It's up to you to find clever ways to write nice-looking programs.

It sure can be a problem when you have to deal with "business requirements" that you can't change, because in Forth you look for simplifications at every level. Dealing with that may require to thing out of the box a bit, and forget about what is "good" and "bad" in other languages. Maybe you can use table-driven programming? Maybe you can do some dirty tricks with the return stack to get the control-flow you want? Maybe you really have to put that data in a variable? There's no single answer, and it can get ugly at times. Not, BTW, ugly like in the article. This: > : apply2 rot dup rot dip rot apply swap ; ... is an abomination. "dip" is questionable already. "rot", thought part of the standard, is best avoided. Because one should only deal with the top two elements of the stack. And of course "apply2" itself is suspicious. Why the author showed this, even though he seems knowledgeable enough to know that he shouldn't? Because he picked a simplified Forth that did not let him use the return stack. The author sure talks a lot about the "Forth philosophy" but apparently missed one or two things about it. If one wants to talk about philosophy, one should at least include in the bibliography what his inventor says about Forth (http://www.ultratechnology.com/forth0.htm http://www.ultratechnology.com/forth0.htm - a lot of stuff there, the main piece being 1xForth). I believe it's Moore that said something like "The important thing is not what you add, but what you remove". The return stack is a core component of Forth; picking a "simplified" Forth that won't let you use it ... well that language shouldn't be called Forth to begin with. That's a bad choice. There are also other questionable choices like using [ ] for "quotations" when they are used for something totally different in standard Forth. Introducing "quotations" is also questionable in itself. It only looks easily implemented because Ruby provides all the memory management; but in reality implementing an interpreter on top of an interpreter is not viable (that makes like at least a x1000 slowdown relative to C); Forth interpreters are typically written in low level compiled languages (typically C), which don't provide garbage collection. And in the end, those "quotations" only look cute. What really helps is currying. Forth is ugly, stupid and mean. It's up to you to find clever ways to write nice-looking programs.