My history with Forth and stack machines (2010)
&gt;&quot;To this day, I find it shocking that you can define defining words like CONSTANT, FIELD, CLASS, METHOD – something reserved to built-in keywords and syntactic conventions in most languages – and you can do it so compactly using such crude facilities so trivial to implement. Back when I first saw this, I didn&#x27;t know about DEFMACRO and how it could be used to implement the defining words of CLOS such as DEFCLASS and DEFMETHOD (another thing about Lisp they don&#x27;t teach in schools). So Forth was completely mind-blowing.&quot;<p>It is, isn&#x27;t it?<p>Forth is sort of &quot;the next level up&quot; from assembler, in the language abstraction hierarchy...<p>First you have switches...<p>Then you have punched cards...<p>Then you have a simple assembler that converts files of numbers into machine code.<p>Then you have a simple assembler that converts files of instruction symbols (operands&#x2F;mnemonics) and numbers into machine code.<p>From there, you might have assemblers that understand global variables and labels&#x2F;addresses in memory (necessary for function calls), etc.<p>Forth starts to come into existence when you take a later (in evolution&#x2F;time) assembler&#x27;s symbol (aka &quot;function name&quot;) address look-up table for functions -- and implement it dynamically (with the ability to add to it) at run-time.<p>That&#x27;s because the initial Forth tokens&#x2F;symbols (it&#x27;s &quot;primitives&quot;) -- are CALLs to static pre-defined assembler routines (or would have been in the first version of forth) -- with the ability to define new tokens&#x2F;symbols -- in terms of combinations of executions the previous ones...<p>To make all of this magic happen, you need to separate the &quot;CPU provided&quot; single stack (well, at least if we&#x27;re thinking Intel, which may have not been the case with early CPU&#x27;s) -- into two stacks, one for data, one as a call (function return) stack, and this is exactly what Forth does.<p>Forth exposes the data stack to do whatever you want with, to you the programmer.<p>Now, when we get to Lisp (the next level up from Forth, in my opinion) -- Lisp does two additional things, which are<p>A) Takes the ability to monkey with any stack, away from the programmer.<p>B) Implements the management of LISTS -- whose management (memory management, pointers, etc.) the programmer no longer needs to worry about (think of this as a pattern from mathematics, N, that is, &#x27;multiples&#x27;, &#x27;batches&#x27;, &#x27;vectors&#x27; (&quot;more than one thing of&quot;) -- meets Forth&#x27;s ability to work with single symbols -- well there has to be a convenient data structure to work with multiple symbols (and data, which now there is a demarcation of in LISP) at a time -- and that way LISP provides, with it&#x27;s &quot;I&#x27;ll manage the stack and the lists (at least the memory&#x2F;structure&#x2F;pointers of the list) for you, so you the programmer don&#x27;t need to worry about any of that!<p>So yes, Forth is brilliant and fascinating in its simplicity...<p>I wouldn&#x27;t write million-line business applications in it, because as a programmer, I am not perfect, I make mistakes, and I tend to like type-checking, automatic stack management, and other things that modern compilers provide.<p>But Forth is utterly brilliant from a &quot;how did Computer languages evolve&quot; &#x2F; &quot;how could a computer &#x27;pull itself up by its bootstraps&#x27; perspective&quot;...<p>It&#x27;s highly worthwhile for any programmer to learn about...