A Brief Introduction to Forth (1993)
users.ece.cmu.edu
users.ece.cmu.edu
It is quite a poor language for modern software development. The advantages of Forth are nearly never useful to a modern application, mobile or web developer. The advantages are; works well on a memory constrained system (think kilobytes not megabytes), it is good for writing assemblers and cross compilers for Forth (I think we can agree that most developers are not going to be porting a programming language to a new architecture in order to write a CRUD application), and poking hardware and hardware registers interactively which goes without saying - the vast majority of programmers will never do, only embedded and kernel developers on any regular basis.
Instead it has many disadvantages like poor string handling, global state being the default and not the exception, poor support for structures (I know you can make your own but that does not make them good), and even worse memory safety than C. That is just that language itself, the ecosystem around it is just as bad, there are few libraries for generic functions, and it is most likely that they will require some kind of porting to the Forth you are using, there is a saying within the Forth community - "If you have seen one Forth, you have seen one Forth", they are different in quite fundamental ways.
It just does not solve modern problems but ones that were relevant in the 1980s on microcomputers.
The reason I like Forth is because I like reinventing the wheel, understanding how systems are implemented, and puzzles. I do not like Forth because it is good at getting things done.
Michelson, the language for smart contract on the tezos blockchain is forth like.
It is a pleasure to work with and it is relaricely easy to prove non trivial properties of a specific program.
Unfortunately my copy was eaten by a rat. But a scanned and OCRed version of that 1st edition is available as a PDF here:
Teacher took away points not using assembly or C and because "you shouldn't be able to add code on the fly".
Still bugs me to this day.
Unless you call them plug-ins. :)
FP, I suppose I can understand, since ML started off with a plethora of discrete features, and things have only grown from there. Great paradigm, but not exactly something you'd want to even try to cram into a single file. But I might have expected to see some sort of Smalltalk- or Io-inspired language in the list.
I had fun recently writing something like forth. I'd probably like to try doing it properly next time - using a proper return-stack so that `if` and similar primitives can be implemented in the language itself, rather than in the hardcoded fashion I have at the moment.
For anyone looking to implement a Prolog Paul Tarau has an interesting approach: "A Hitchhiker’s Guide to Reinventing a Prolog Machine" https://www.cse.unt.edu/~tarau/research/2017/eng.pdf
Fascinating! I ended up designing my own Prolog virtual machine rather than mimicking the WAM, using a union-find address space to represent unified terms, with hopes to make it a persistent data structure and so implement backtracking over unification by cheap checkpointing. I never got around to it, but it left me with a fascination with Prolog internals.
http://web.engr.oregonstate.edu/~budd/Books/little/
http://rmod-files.lille.inria.fr/FreeBooks/LittleSmalltalk/A...
It was a bit different than the Blue Book, though version 3 was a lot closer to Smalltalk-76 and version 4 to Smalltalk-80. The number of classes and methods remained very small and the C code for the virtual machine is still simple and easy to understand. Several projects forked Little Smalltalk
There‘s also a Master‘s thesis about the implementation: https://verdich.dk/kasper/thesis.html
And another overview: https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.84...
Among other things, Lars Bak worked on the StrongTalk VM that became the Java VM. And he is/was behind the V8 JavaScript engine.
Something based on TCL or S-expressions sounds like it would give the needed flexibility, though maybe at the expense of being able to implement on microcontrollers. Has anyone played with parsing either of those? I know that the PCB designer tool in KiCAD uses S-expressions so it's been done before.
Some Forths include an additional floating point stack, and many implement types on top, but the basic nature of the thing is not to address division of data into sizes, fields and regions of memory directly, and instead to let the user define those things. Where Forth is powerful is in allowing layers of binding to build up, since the language can flip-flop between execution and compilation easily - that's why basic control flow words like IF - THEN - ENDIF can be bootstrapped, as can any desired type checker. But in the process, the binding format - the Forth dictionary - becomes one of the core dependencies.
The "just data" formats like JSON only approach the topic of binding in limited ways like key-value structures or a defined schema. The types are static during parsing, so the data is less tangled and context-driven and more approachable through a simple divide-and-conquer.
It's also a concatenative language, so it captures a lot of what's interesting about Forth, but with more of the niceties that we've come to expect in a programming language.