It's a high level language compared to Assembler. Like a lot of those early experimental languages it's worth learning a bit. It's also a pretty much complete failure other than a few standout uses (the main one I can think of is that the boot loader on Sun SPARC machines was written in Forth).

To me it fits in an odd place. It was much hyped/replicated on Micros in the 1980s as it made the Basic implementations on those machines seem very old fashioned. For most users who were already working on minicomputers in languages like C or Lisp, Forth was just a weird riff on stack based languages that had already been considered and discarded. So the general impression on whether Forth was any good or not depended entirely on what else you had programmed in.

Having said that, stack based languages like Forth, PostScript or even xslt are challenging and thought provoking.

Personally, if I wanted to play with a stack based language I'd play with PostScript or xslt as at least you'd have half a chance to use it professionally.

edit: yeah xslt isn't a stack based language but I always thought it helped when learning it to consider it that way

I've wanted to write some retro computer games for awhile, but I really hate mucking with Assembly language. It would be cool to have something faster than BASIC but higher level than raw assembly.

Depending on which platform interests you it might or might not be avaialable. A quick search for the Commodore 64 brings up a lot of info:

https://www.c64-wiki.com/wiki/Forth

Seems like there might be good hardware support for Forth on the C64

There was a really neat looking FORTH for the C64 focused on game programming: White Lightning[0]. oh - it runs on Zx80 too... I always wanted to play with it as a kid, but never got around to it :-/

0: https://www.forth.org/lightning.html

I got it loading in a Commodore 64 emulator. It seems cool but I don't really know what I'm doing just yet.

The download I found had a full manual so I might see if I can figure out how to do some kind of graphical stuff.

Good Luck!

There are new versions of the classical 80s computers such as the Commander X16, Zx Spectrum Next, and C65. They're pricey, but I think at least two of them have Forths. It might all be easier to go with an emulator too.

As of right now, I'm happy enough to play with emulators and/or the MiSTer. I was initially excited about the Commander X16, butI've been a little disappointed with the concessions that the 8BitGuy made, and I feel I'll have enough fun with emulation.

I would call it critically endangered, but would never call it a failure. Forth landed on a comet, and ran most astronomy labs and telescope control systems back in the day. For a couple decades there was a large amount of productive and unsexy work getting done in Forth, much of it under the radar in control systems for manufacturing, scientific tooling, waldos. It wasn't really until the mid 80s that it started drying up.

i think the great appeal of forth is that it's a great repl for interacting with hardware and assembly code. c kind of sucks at this even though c is a better language for programming as such

it's the minimal amount of extra stuff you need to add on top of assembly language to give you recursive subroutines with parameters; structured control flow constructs like if-then-else (ahem, if-else-then), for-next (uh, do loop), and while; user-defined data types; closures (does>); turing-complete compile-time metaprogramming; embedded domain-specific languages; multitasking; and paged virtual memory. all this costs you about 4k of ram and (usually) a 5× slowdown compared to assembly. nowadays some of those are commonly provided by hardware, but forth has them even on hardware and operating systems that don't

in forth you can very easily invoke your assembly code interactively, look at the results, hex-dump parts of memory, script your assembly code, script your hex dumping, script your scripts, and so on. and it makes a fantastic macro assembler if you can get used to the syntax. the built-in repl gives you a built-in user interface, and it also serves as a sort of interactive debugger; you can't step through your code line by line, but you can invoke it word by word, which is pretty close to the same thing

i did this screencast of debugging an integer square root routine in gforth three months ago https://asciinema.org/a/621404 but i should ofer two cautions:

- i'm no forth expert

- if you actually need square roots in gforth you should probably just use fsqrt. 1024 0 d>f fsqrt f>d d. gives you 32 as ahura mazda intended

three instruction Forth for embedded

https://pygmy.utoh.org/3ins4th.html

If you have new hardware with zero tools, I think it is still possibly the quickest path to more sophisticated options.

you might be right

i haven't tried the 'three-instruction forth' approach myself (which i had misremembered as being due to brad rodriguez rather than frank sergeant) but that paper was definitely a major factor in forming my viewpoint that forth is not really a programming language but rather an interactive environment that happens to have a programming language (a language the 'three-instruction forth' omits!)

you probably do need a fourth 'instruction' in practice: reset, or at least some kind of interrupt that returns you to the interpreter when you're in an infinite loop. usually there's a separate reset pin, though, which leaves memory intact so you can debug what went wrong — or, at worst, set up the thing so you can power-cycle it. usually that goes without saying, but sometimes hardware is physically far away these days...

Forth's niche was embedded control using small 8- and 16- bit computers with from 8 or 16 kilobytes up to 64 kilobytes of memory. Its heyday was the 1970s and 80s when those were the largest, most powerful computers that were economical for embedded control applications. As larger, more powerful computers with more elaborate software became affordable, Forth's niche shrunk away and the language became an obscure curiosity.

In its heyday Forth delivered impressive functionality on very small systems. You could have an interactive development system with a command interpreter, editor, assembler, compiler and the application on an 8 bit microcomputer with less, sometimes much less, than 64 kilobytes of memory.

Playing with it on a Commodore 64 emulator, I can kind of see the appeal. Writing equivalent programs in BASIC vs White Lightning Forth, the Forth version is substantially faster, without being that much more difficult than BASIC once you figure RPN out.

I used an HP calculator in high school and use an HP emulator on my iPhone, so I'm already pretty good with RPN, so the weird syntax is coming fairly natural to me, and it's substantially easier than doing everything in raw assembly.

It's a very good language to play with to get a glimpse of "just the computer". It's still an interpreter environment, but it's one that crashes spectacularly because you accidentally swapped your arguments and wrote to address 3.

The most fundamental difference in feel when programming Forth for an application vs C is that you don't have a stack frame. A stack frame is what lets you throw 10 arguments and 20 local variables into a function, because the compiler binds them all to names and you fire away and then it's cleaned up automatically when you're done.

In Forth, you do not want to do that because every stack variable you use, you have to manually bring to the front with stack manipulation words(e.g. SWAP to flip the position of the top-most and second, ROT and -ROT to shuffle the top three). It's a pretty big deal, and if you let that define your application, you're cooked. You can define temporary buffer or register spaces instead and do some load and store from those to the stack to get through the nastier bits of computation.

But in exchange for that, you get some fascinating possibilities to do tacit(point-free) programming instead. That is, because you've removed names from everything except word definitions(which are just sequences of calls to other words), your stack operations now compose together without needing any additional ceremony. And because you can instruct the interpreter to switch modes between "compile" and "execute" at will, you have a Lisp's degree of metaprogramming, so things like strings and formatted numbers are implemented as modes that jump out of the regular interpreter and wait for an end character to show up in the buffer. This extends even to stuff like IF ELSE THEN(control flow is negotiated with the help of a separate stack).

So it's wildly powerful in particular ways, but boring algorithmic code is often just as hard to write as the metaprogramming stuff, because every time, you have to work through your stack positions and try to break it down to a reasonable composition. And by the time you do that, you have a ton of confidence in having written a very exact spec, but also, the thing you did was probably something like "print a fixed point number".

So it's a very good language to use to make you detail-oriented and build up a personalized way of working. It really doesn't lend itself to flinging things around and telling the rest of the team "the code is self-documenting".