Stack languages present a troublesome problem for documentation. Forth in particular is untyped, but my own experience was with a small compiler/interpreter I w

Stack languages present a troublesome problem for documentation. Forth in particular is untyped, but my own experience was with a small compiler/interpreter I wrote over a dynamic language(haXe). The language was easy to implement, and it solved one domain problem very well(in-game dialogue) and another not so well(choreographing two-dimensional movement patterns). I've filed it away as "cool experiment." My implementation allowed the same syntax to be used with different semantics - a batch compiled word, or words sliced up into lists of function calls, which made them usable in continuation-passing style - very useful for my in-game dialogue. The debugging I encountered mostly revolved around correcting stack manipulations so that things lined up with the right parameters. The brevity of these languages comes from the stack allowing implicit parametrization; just list your data and then the word you want to use. The downside comes from this property also allowing the stack to leak when under or over-parametrized - enabling mystery behavior or crashes that you wouldn't see with C-style calling conventions. On the other hand, a major plus: Working with the stack lets you avoid littering your code with named variables. This is what enables Forth words to have extremely high density and readability, and I've incorporated more of this style into my coding elsewhere, so that in the most extreme case, I might go ahead and set up a stack in(for example) an object, and then list out method calls like a high-level Forth operation: obj.wordA(); obj.wordB(); obj.wordC(); Blending this with more imperative or functional constructs, I can get the best of both worlds: something compact and readable but also self-documenting, with decent type and parameter safeness.