3 ms·
It's a bit unfortunate that this article is one of the most circulated accounts of a "failure" of applying Forth to a real-world problem. The author learned a l
by RodgerTheGreat 7y ago
It's a bit unfortunate that this article is one of the most circulated accounts of a "failure" of applying Forth to a real-world problem. The author learned a little about Forth and was fascinated. He then wrote his own implementation and struggled mightily with it. Ultimately he was disenchanted.
I think the heart of the problem is that the rudimentary ideas of forth- a stack, some stack-shuffling words, some arithmetic, control flow, and that's about it- are appealingly simple, but not enough of the language:
>"I figured I didn't need the more interesting metaprogramming stuff for my first prototype programs, and I could add it later if it turned out that I was wrong. It was wierd to throw away everything I originally liked the most, but I was all set to start writing real programs. Solving real problems in the real world. It was among the most painful programming experiences in my life."
Imagine reading the first chapter of SICP without prior exposure to Lisp, excitedly writing an interpreter for the parts of the language you'd seen so far, and then feeling your enthusiasm slowly slip away into dismay as you attempted to use that stunted fragment of a language to get work done.
Forth can be small, and simple, but the real gems of the language are a bit subtle. The many implications of CREATE>/DOES. Abuses of manipulating the rstack. Striking a balance between parsing words, named locals, global variables, vocabularies, and other tools to minimize twisty stack shuffling. Bending the rules at the right times.
- sifar 7y agoI am fascinated by forth and stack machines. It reminds me of Donella Meadows' Leverage Points, when you change your paradigm from data in registers to that in stack, the architecture becomes simpler. Can you please suggest any reference which explores forth in depth and goes into the subtleties. I am starting out on the Leo Brodie books.
- RodgerTheGreat 7y agoThe Brodie books are both excellent. "Object Oriented Forth" by Dick Pountain is a succinct and practical exploration of applying Forth's metaprogramming capabilities to extend the language with various features. The best aspect of the book is that it works through many alternatives rather than taking a direct path. It's more about data structures and abstraction than OOP. Julian Noble (https://www.taygeta.com/fsl/docs/NobleArchive.html https://www.taygeta.com/fsl/docs/NobleArchive.html) also wrote a number of very interesting articles and books about Forth. There's an apparently ongoing project to re-typeset his "Scientific Forth": https://github.com/Josefg/Scientific_FORTH https://github.com/Josefg/Scientific_FORTH.
- emptybits 7y agoThese are "old" references, as a lot of Forth references seem to be but I enjoyed them during a Forth phase. The standard advice, and I agree with it, is write your own Forth, maybe more than one. If you're comfortable in any platform's assembly language I would recommend starting there, even if it's "old". This depends on your own history in computing but I found a C64 emulator convenient for this. Old PC emulators have load/save abilities to the host file system, and what I loved was a simple memory model, memory-mapped hardware features, and a simple ISA. i.e. a system you can hold in your head all at once, contrasted with modern handhelds or desktops. Two books: (I really enjoyed the first one, multiple times) "Threaded Interpretive Languages", by R. G. Loeliger. "Stack Computers: The New Wave", by Philip Koopman. Two short papers: (maybe not profound, but they're short and available online) "Handling Multiple Data Types in Forth", by John J Wavrik. https://www.math.ucsd.edu/~jwavrik/pub/11_jfar.pdf https://www.math.ucsd.edu/~jwavrik/pub/11_jfar.pdf "Literate Programming in Forth", by Peter Knaggs. https://rigwit.co.uk/papers/literate.html https://rigwit.co.uk/papers/literate.html