well, forth does have lessons, largely about a general way to structure
forth does not present itself that well as a programming language, but it
does at least look like a good alternative to assembler. a high level
language can be made, and can be compiled directly to something resembling
many common bytecode interpreters bear similarity to the general design of
forth with a fixed set of words, a few things missing, and a few things that
go outside it (eg: occasional bytecodes with fixed arguments or whatever).
forth itself would not be that effective for bytecode, the bytecode needs a
little more cooking, but the differences are minor...
however, like assembler, many programmers will generally refuse to code in
it directly, so other languages are needed, even if in many cases they are
not technically an improvement...
(once again are the idle thoughts that it would be cool as a misc project to
write a standalone bytecoded forth interpreter in assembler, and then maybe
writing other interpreters and the drivers in the bytecoded forth, but there
is little reason really, the only real use would probably be as a
the real use wouldn't really show up until one wrote pretty much an
interpreted unix, and performance would likely be worse than one written in
maybe a completely different architecture could be done, but there is little
point to this either...