Moving Forth, Part 1: Design Decisions in the Forth Kernel (1993)

It'd be nice to be wrong, since I'd love to work in a system where every bit is handcrafted and known to me. I didn't quite get there back in the 80s in my summer job at FORTH, Inc. but it did teach me a bunch and I enjoyed scrounging out a few bytes here and there.

Not going to happen. People these days are interested in how to make things work, rather than how things works. They want easy memory management, they want easy concurrency, they want easy safety.

Despite the standardization efforts, Forth has always been about figuring out and design things yourself. It's meant to be your a personal tool that you make and shape for yourself. It means that if Forth is your thing, you won't write just one interpreter and be done with it; you'll write a bunch of them depending on your needs (fully standalone for embedded systems, C-based under Linux/Windows, as a scripting language embedded in an application, etc.)

That's why it has to be tiny and simple. That's why standards and popularity are irrelevant in this case.