Forth is the premier language for programming embedded systems. There are a number of distinct and well-known advantages to Forth that make this so, and few subtle advantages that escape popular notice. There are also certain difficulties unique to Forth programming, mostly in the realm of programmer selection, education and qualification.
We will examine both the “light side of the Forth” and the “dark side of the Forth” today. Forth is, in the words of creator Charles Moore, “more of an approach to problem solving than specification for a programming language.”
While the emblematic quirk of syntax variance between Forth systems which gave rise to the quip that “if you've seen one Forth, you've seen … one Forth” has been largely ironed out by successive standards, with dpANS for Forth apparently having been reached in August, 1991, there is a bewildering variety of implementations of the Forth engine itself which help make it difficult to characterize Forth.
Forth is both a compiler and an intepreter. What the compiler compi les is the crux of the variance in implementations. In some systems, Forth compiles optimized machine code. In others, it compiles assembly source code for use with MASM. In others, it compiles execution tokens, and in the most classic of Forths it compiles lists of subroutine addresses.
Forth was created with its own specification for console input and output, virtual storage face, multitasker, etc. As such, it is more of a programmable operating system plus shell than it is a programming language, yet Forth programs exhibit a fine granularity of structure and an efficiency of execution, more far beyond that which one experienced with other standalone programming environments such as BASIC, APL or LISP might expect.