I have a theory that the best forth programs for a domain approach a optimal Huffman encoding for the problem. This explains why Chuck Moore (who probably had the IQ to spare) could do amazing things such as design a chip design language in forth. Unfortunately Forth programs are about as hard to grok as manually decoding a Huffman encoding. ;)
Real-world FORTH code has lots of non-trivial stack operations which are quite far from 'optimally' encoded, in fact they're quite unintuitive. You could get quite a bit closer by somehow extending the language with direct representations of data flow and control flow/dispatch, but that of course loses the FORTH property of all composition being represented as simple concatenation of tokens.
> Real-world FORTH code has lots of non-trivial stack operations which are quite far from 'optimally' encoded, in fact they're quite unintuitive.
I guess it depends on what you consider to be "real-world".. but usually when I see a ton of stack manipulation, it's from a newer forth programmer who thinks that they should be programming that way, i.e. forth is stack based, so I should be putting everything on it.
I went back and looked at an old SHA1 implementation I did[0], and I think the "worst" stack manipulation was a -rot in one place, and maybe the handful of overs.
