If you love HP-RPN calculators, you may love Forth as well.
Forth is a very interesting language, I find it a bit too complex for my little brain but give it a spin if, you have 2 free hours
It's not complex, it is just that it requires a different mental model because of the lack of named parameters. Stack offsets are harder to remember than things with names, more so because they change all the time as you push and pull data.
Like many languages, Forth can get complicated if you really get into the weeds. These 2 papers [0][1] (both by one of Gforth's creators) illustrate the sorts of intricacies you can run into. The trickier subtleties have to do with Forth concepts like interpretation and compilation (which have their own meanings in Forth), and have little to do with Forth's use of stacks.
In Forth's defence, other languages also have tricky subtleties, e.g. C++. Neither language prioritises theoretical purity, of course. They would be very different languages, with different drawbacks and advantages, if they did.
Both papers touch on whether the behaviours of certain unusual Forth constructs are well-defined according to the ANS Forth language standard. This sort of discussion should be quite familiar to C++ programmers.
I just implemented an ANSI compatible Forth so I'm reasonably familiar with those nasty bits, the 'DOES>' and 'DEFER' words in particular were interesting and caused me to have to rewrite some stuff that I had assumed was already stable.
That’s because Gforth is a threaded-code VM that saves dictionary images rather than compiling to native code.
As you prolly know, Forth blurs compile time and run time in general, and there’s no so-called clean compile, then link boundary like in C.
SwiftForth, VFX Forth, and iForth do emit real executables, and there are smaller native-code Forths for Linux too, but then the opportunity cost is losing Gforth’s portability and its standards-heavy library ecosystem.
> That’s because Gforth is a threaded-code VM that saves dictionary images rather than compiling to native code.
That's not correct. Gforth features a JIT compiler, although they don't call it that, they call it dynamic superinstructions. It will be enabled if you run gforth-fast. If I understand correctly, the native code sequences are always generated at runtime, and cannot be baked into an image file.
The standard library is lacking some really nice conveniences. I'm working on correcting this and teaching Forth as a "grassroots" language for people who want to go back to the joy of programming as an art. The 100rabbits folks have already done a lot of work around proliferating that idea but I want to work outside of the Uxn machine that they use. Mark my words, us programmers are not phased by AI stealing the joy of programming :) The day job business programming, sure. But that was only fun sometimes. Forth will continue to exercise our brains and work through logic and data flow problems - skills we can bring to guiding agents for the day job.
Have you considered factor? Its from the joy-inspired branch of the forth/concatenative family, but its a heavily underrated, batteries included language. Which has a bit of a smalltalk feel given its image-based deployment and the "live" nature of its tools (graphical repl, object inspectors, etc)
Factor looks like a more conventional language, with dynamic typing, automatic memory management, etc. It sounds quite far from Forth's roots as a compact assembly sequence that enables interpretation of a minimal language just barely atop the bare metal.
fallat said they were interested in teaching a 'grassroots' language. By that I think they mean something with a minimal core language and compact interpreter, so Forth seems like the better fit.
Since you're working on your own thing that may or may not be like a traditional Forth at all, and also mention Uxn, you might find some ideas in Ben Bridle's Bedrock worth stealing:
I just did a big project using Forth and it is every bit as useful as it was in the past. Yes, there no security model, and you're going to have to work to manage your project, no fancy IDE or editor. I took a piece of code I wrote in 1988 and built it out to pass the Forth standard core words test and some extensions as well, then added all of the Raspberry Pi io devices as primitives. This makes it a super useful little toolkit (6K loc, 0 dependencies) to build embedded systems with in the robotics space.
I did consider using Gforth and another one that Don Hopkins pointed me to but I the end the familiarity with my own code won out over first reading myself into a large project. It all worked pretty well, the device I built with it is performing way beyond my expectations and I'm really happy I chose Forth even though it is a choice that I think only very few people would have made because it feels so old-fashioned. What especially pleased me is the lack of superstructure and the ease with which the whole thing could be moved between machines of varying word-size and underlying CPU architecture.
Forth still has a place. Now I need to get my grubby hands on some GA 144s.
> [Gforth is] a free, fast, featureful and portable implementation of the Forth 2012 language.
> Gforth runs under GNU, BSD, and similar systems, MS Windows and MacOS X and should not be hard to port to other systems supported by GCC.
In Forth's defence, other languages also have tricky subtleties, e.g. C++. Neither language prioritises theoretical purity, of course. They would be very different languages, with different drawbacks and advantages, if they did.
Both papers touch on whether the behaviours of certain unusual Forth constructs are well-defined according to the ANS Forth language standard. This sort of discussion should be quite familiar to C++ programmers.
[0] State-smartness - Why it is Evil and How to Exorcise it (Ertl, 1998) http://www.euroforth.org/ef98/ertl98.pdf
[1] State-smartness: Applications, Pitfalls, Alternatives (Ertl, 2001) https://www.complang.tuwien.ac.at/papers/ertl01state.pdf
BTW, on the other side, looks like gforth still lacks the ability to create native OS executable, something like:
gcc myprog.c -o myprog
?
As you prolly know, Forth blurs compile time and run time in general, and there’s no so-called clean compile, then link boundary like in C.
SwiftForth, VFX Forth, and iForth do emit real executables, and there are smaller native-code Forths for Linux too, but then the opportunity cost is losing Gforth’s portability and its standards-heavy library ecosystem.
That's not correct. Gforth features a JIT compiler, although they don't call it that, they call it dynamic superinstructions. It will be enabled if you run gforth-fast. If I understand correctly, the native code sequences are always generated at runtime, and cannot be baked into an image file.
• Dynamic Superinstructions https://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Dyn...
• [PDF] Code-Copying Compilation in Production An Experience Report (2025) http://www.euroforth.org/ef25/papers/ertl.pdf
https://github.com/ncw/ccforth
I wrote it as an experiment in having both a forth interpreter and compiler running at the same time.
Forth can have comments and doesn't need to be all at one line:)
also labels works as functions etc.
Its way more tradable language in real life than people think
fallat said they were interested in teaching a 'grassroots' language. By that I think they mean something with a minimal core language and compact interpreter, so Forth seems like the better fit.
https://benbridle.com/projects/bedrock
In particular the reasoning for what he changed compared to Uxn might be insightful:
https://benbridle.com/articles/bedrock-differences-from-uxn
We will also compile them, and reference their execution tokens from the dictionary.
I did consider using Gforth and another one that Don Hopkins pointed me to but I the end the familiarity with my own code won out over first reading myself into a large project. It all worked pretty well, the device I built with it is performing way beyond my expectations and I'm really happy I chose Forth even though it is a choice that I think only very few people would have made because it feels so old-fashioned. What especially pleased me is the lack of superstructure and the ease with which the whole thing could be moved between machines of varying word-size and underlying CPU architecture.
Forth still has a place. Now I need to get my grubby hands on some GA 144s.
And what I meant was I want the actual hardware. I may have to make it myself.