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

I find it both easier to implement than C and easier to develop in than C, while being nearly as fast as C, and often lower footprint than C. It's a really good language for "I really don't want to write in assembly, but there are no decent HLLs already implemented for my target"

(i'd say 'leads' but there don't seem to be a lot of people doing things in forth these days; duncan's 01988 estimate of 50000 'serious' forth programmers seems two orders of magnitude higher than seems likely today)

i think the appeal is that in 16k or 64k you get a repl which (unixlike) doubles as a scriptable ui, a sort of source-level debugging, interactive variable inspection (and i/o port poking, memory dumping, etc.), instant turnaround for changes (no 'my code's compiling'), multithreading, virtual memory, an assembler and disassembler, an extensible compiler with a turing-complete macro system, and dramatically better code density than machine code

all of that makes a pretty appealing package, especially for certain kinds of tasks, and it's only loosely coupled to the language qua language

as duncan points out, part of the appeal is that the development environment is a lot more integrated than something like turbo pascal

When I first used it I loved the way you could redefine the language, at run-time in the REPL. These days I just love the purity and cleanliness of the language.

I don't have a single compelling use-case for it, but over the years I've written my own implementation in C, Java, and Perl.

Having recently started playing with hardware it is nice to see you can even run it on ESP8266 / Arduino hardware.

Current micros are a bit big for Forth, though. You can run C or C++ on them. If you have only 4K or 8K of code space and 128–512 bytes of RAM the case for C over Forth gets a lot weaker. Maybe we'll see a resurgence of Forth when we get nanobots.

Forth and C are low-level languages. I can (and do) use them to develop firmware.

Lisp and Java are for "big-iron" system.

But you are right, one of the strength of Forth and Lisp is the availability of a REPL.

[1] This isn't saying much [2] Only by a few months

Forth tends to be one step in bootstrapping a system, or it is so small that it is correct by observation. Forth is powerful, but the systems that use it should be held to a small size.

I think for the most part, Python/MicroPython now occupies the same place Forth once did in the embedded world. As MCUs get more capable and default to more memory, not only will higher level interpreted languages become the norm, low level languages can be integrated via Wasm, either compiled or interpreted on device.

In my experience it does not appear to scale very well to medium-sized projects (2-3 engineers for 3+ months).

The best FORTH programmers I knew were pretty pragmatic about the language, and were frank about its limitations. The worst FORTH programmers thought it was totally wonderful for absolutely everything, which is of course a recipe for disaster with any language.

* Forth is tiny. You don't need a preprocessor, a compiler, a linker. Your entire programming environment, beside the text editor, can live directly on the target MCU.

* Forth is interactive. You can run your code, examine the results, define and redefine words, run again, etc right on the target machine (which may be a tiny controller). Yes, you likely will remove the REPL-related words from the final image (or not), but C can't hold a candle to the interactive development experience of Forth.

* Unlike in C, you can build an economical DSL in Forth to closely match your target domain. What Forth takes away in readability due to the need to think in stack terms, it more than pays back in expressiveness and abstraction, provided certain skill and taste.

While Forth does have an execution overhead and thus cannot obviate C completely in some cases, I've seen e.g. an injection controller for an internal combustion engine which did hard realtime completely in Forth. Hard realtime here means that all computations were clocked by the rotation of the shaft, with precise timing of different phases along the way.

All the embedded work I have done has mostly been C with a little more C++ in the recent years, outside of some machine level stuff for highly specialized devices. So just from that, at least in my experience C is the more common, portable and easily worked with language.

I'm currently writing an ML derivative language for smaller systems and I hope that'll be practical while at the same time being a better alternative to C.

I would say Forth is easier to use than assembly, and perhaps much more flexible/extensible than C, although in some senses lower level since C gives you a very nice, ordered way of specifying what are the arguments to your functions/etc.