Of all the people who have influenced how I think about programming, Chuck Moore stands above the rest. Even when I'm not using Forth, the programming language he created, his approach to software design continues to guide me.
Moore developed Forth in the 1960s, and it remains a remarkable departure from conventional programming. Forth is a compact, interactive, stack-based language in which programs are constructed from small definitions called words. These words build on one another, gradually forming a vocabulary suited to the problem being solved. The language itself is extensible, and a useful Forth system can be implemented with remarkably little code.
Forth was not simply an interesting experiment. It found practical applications in astronomy, industrial control, embedded systems, and spacecraft. Moore himself went on to develop sophisticated software for designing microprocessors, along with the processors themselves. His work demonstrated that very small, thoughtfully designed systems could accomplish serious work while being significantly smaller than mainstream offerings.
But what interests me most about Moore is not Forth's syntax or even its technical achievements. It is his persistent questioning of complexity.
Most of us learn to accept certain layers of software infrastructure as necessary. We reach for operating systems, file systems, frameworks, libraries, elaborate abstractions, and increasingly sophisticated development environments. Moore's work raises a more fundamental question: How much of this is actually required to solve the problem?
He advocates understanding the problem deeply, breaking it into small pieces, and eliminating anything that does not serve a clear purpose or help solve the problem at hand. He often comes from a place of what can we remove rather than we can we add.
Moore takes these principles further than most programmers would be comfortable with. I don't agree that all of his choices would be appropriate for every project. I make comprises he never would. His choices are right for him and have let him do things that no one else has done. But if you're in a standard corporate environment having to work within a team, then you're likely better served by conventional options. Unless you're a radical startup willing to go places no else goes.
His work provides something very valuable: a concrete demonstration of how much simplicity is possible when we reconsider our assumptions rather than accept them. And he simplified the software-hardware stack as considered together, to produce the simplest combination of the two. You may not want the radical simplicity that he employs but it's good to have awareness of its existence.
That is why I consider Chuck Moore my greatest influence. I don't need to write Forth to benefit from his thinking. His example continually reminds me to question complexity, to understand what I'm actually trying to accomplish, and to resist writing more software than the problem requires.
For me, that is the enduring significance of Forth. It changes one's sense of what is possible. But as I am not yet qualified to explain Forth in depth, I will refer you to my favorite essay on the subject.
-Matthew/Austere Code on October 26th, 2026