I love Forth, but for me it is not a viable programming language to do general
purpose work in. It is not even particularly good in the niches it once served
in either, such as in the embedded realm and memory constrained systems.
Learning the language, and more importantly implementing my own Forth, has made
me a better programmer, but I do not think I would ever use it professionally.
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.
I learned Forth specifically to get a posted job shortly after this book was published but my first exposure to the language was through a port someone in my local computer club did onto the ZX-81 (he also built a raster graphics system!). There are concepts in Forth that are included in some modern languages/environments but I agree that it's really not suited for much today. We used it in control systems and today would probably choose something like Erlang instead - it was perfect for this type of application.
Those who want to read more might enjoy Leo Brodie's book "Starting FORTH", complete with hand-drawn illustrations and retro monospaced font. I never worked with the language, but found the book an enjoyable read in the 1980s when it came out, as much from seeing how he went about explaining things as from the things being explained.
Unfortunately my copy was eaten by a rat. But a scanned and OCRed version of that 1st edition is available as a PDF here:
Ahh Forth .. I remember after I finally got a disk drive for my TI-99/4a, I ordered some software and they included TI Forth. This was around 1985 or so. In 1990 I ended up writing a small Forth kernel to run a micro-controller in one of my EE lab classes.
Teacher took away points not using assembly or C and because "you shouldn't be able to add code on the fly".
And after forth, there's Tcl. And lisp. These three are the most easily implementable, for which we have so many dialects of them. What other languages are so small, simple and easy to implement?
It's slightly interesting to me that neither object-oriented nor functional-in-the-Backus-sense languages are represented here.
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.
The core of Prolog (Horn clause resolution) is not terribly difficult to implement, IMO. Learning how to implement unification with backtracking is an edifying experience!
I did that, and it was. :) I wrote some (incomplete) type inference code for Joy (a Forth-like functional language) and that (among other things) led me to Prolog. I was surprised how simple it is both syntax and semantics. ( https://joypy.osdn.io/notebooks/Types.html ) I eventually reimplemented Joy in Prolog and discovered that the type inference code was identical to the interpreter code! ( https://git.sr.ht/~sforman/Thun/tree/master/source/thun.pl )
> For anyone looking to implement a Prolog Paul Tarau has an interesting approach:
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.
With the current proliferation of structured file formats (xml, json, yaml, toml, protobuf, messagepack) I got wondering if there is room for a format based on one of these stack/list based languages that could be easily implemented even on microcontrollers or on some locked-down corporate machine with only a decade-old IDE and no third-party libraries. My original thought was something that was a subset of Forth, though I get the impression that vanilla Forth is a headache dealing with data types other than ints and the result would be sufficiently custom that it wouldn't be worth it.
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.
The limitation in crossing the boundary from a data language to an executable language is mostly down to contrasts between "divisions" within and "bindings" across data.
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.
BASIC is another simple-to-implement language, especially if you go for something like tinybasic.
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.
The language core of SmallTalk seems pretty straightforward and lots of people have built their own. But then there is all those standard objects to implements...
This is true. However, the language, the core objects, and the virtual machine implementation are described in the Blue Book well enough for someone to implement all of it. Like Oberon it's a description of a complete computing system that fits in a single book
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
sidtran, which Sid Meier used to use in the 8bit days (and maybe 16 bit). I don't know if there is any spec or sample anywhere on the net but was forth like stack based with DUP, SWAP, POP, etc. It had to be small since it ran on machines with 32k-64k
"Winter is coming and Collapse OS aims to soften the blow. It is a Forth operating system and a collection of tools and documentation with a single purpose: preserve the ability to program microcontrollers through civilizational collapse."
Factor might be a more interesting option than Forth nowadays.
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.
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.