It's a bit of a shame that Forth has become almost synonymous with indirect threading implemented in assembly. This is true and somewhat interesting of most implementations, but obfuscates the deeper philosophy of Forth. For me, this is about self-reliance and building your own tools that are suited for the specific task at hand.
I don't care for a lot of the standard forth-isms, such as the way branching and recursion are handled. But I make extensive use of the threaded execution model. One quickly notices that anything that can be pipelined naturally fits into this model. Programming in forth style is often similar to programming with unix pipes except you aren't restricted to string input and output and you do not need to fork subprocesses (though you certainly can!).
Learning how to program in forth, which as so many have pointed out is best done by implementing your own, will fundamentally change the way you program in all languages. Chaining method calls in data pipelining is somewhat forth-like.
As far as implementing a forth, the main interpreter can be written in 14 lines of lua (using lua varargs as the parameter stack):
local thread thread = function(first, next, ...)
if first then
if next then
local cont = thread(next, ...)
return function(...)
return cont(first(...))
end
else
return first
end
else
error "require at least one task"
end
end
Here is how to use it:
local push = function(value)
return function(...)
return value, ...
end
end
local print = function(msg, ...)
print(msg)
return ...
end
local hello_world = thread(push "Hello, world!", print)
hello_world()
And for fun, here is dup:
local dup = function(top, ...) return top, top, ... end
The value of these constructs may not be immediately obvious, but I have built a nice compiler in lua on top of it. (I copied the thread definition above directly from my compiler source code).