Chuck Moore: Geek of the Week

Charles Moore is one of the greatest ever programmers. The 'Forth' language he invented is still in use today, particularly by NASA, and has never been bettered for instrumentation and process control. He still argues persuasively that the only way we can develop effective software quickly is to embrace simplicity. Like Niklaus Wirth, he remains a radical whose views have become increasingly relevant to current software development

A descendant of the language that Charles Moore developed was, at one time, the most widely implemented of all computer languages; it was not so much the language of commercial applications but of process control, instrumentation, and of computer peripherals. Forth was extraordinarily advanced for its time, and is still being developed. It spawned other languages such as STOIC and PostScript, and proved so versatile that even a commercial spreadsheet was written in it. In a sense, if you use a PostScript printer, or send .psf or .eps files, you’re using a software technology that Charles Moore first developed.

“I despair. Technology, and
our very civilization, will get
more and more complex until
it collapses. There is no
opposing pressure to limit
this growth.”

It may sound hard to believe but four decades ago, when computing was almost exclusively the province of a handful of scientists, giant corporations, and the military,  it was the Governments that were the chief funders of personal computing research. They bought the machines on which the early researchers worked and were visionary advocates who imagined that technology held far-reaching economic implications, way beyond the immediate military uses.

It was the era in which ideas being pursued at two laboratories located on opposite sides of Stanford University would re-shape the way we communicate.


At one end of the Stanford campus was Doug Englebart’s Augmented Human Intellect Research Institute, dedicated to the concept that powerful computing machines would be able to substantially increase (augment) the power of the human mind. In contrast John McCarthy’s Artificial Intelligence Laboratory at the other end of the university began with the goal of creating a simulated human intelligence.

Charles ‘Chuck’ Moore, best known for the work in developing the Forth software language, was a disciple of McCarthy and his development of simple but powerful languages and applications owes a lot to his tutor’s clear mind.

Born in McKeesport Pennsylvania, near Pittsburgh, in 1938, Moore grew up in Flint Michigan he was granted a National Merit scholarship to MIT where he joined Kappa Sigma fraternity.

Awarded a degree in physics he arrived at Stanford where he studied mathematics for 2 years from 1961. He then worked on Fortran II for the IBM 704 to predict Moonwatch satellite observations at Smithsonian Astrophysical Observatory. Around this time he began learning Algol for the Burroughs B5500 to optimize and as Charles H Moore and Associates, he wrote a Fortran-Algol translator to support a timesharing service.

“Get a bare-bones application running quickly.
 Demonstrate it and get feedback from users.
Then modify and expand capability: much
more satisfactory than planning in advance”

Moore co-founded Forth Inc. in 1971 with Elizabeth Rather, after which he developed the Forth-based chip that was taken to market in the mid 1980s by Harris Corporation as the RTX2000, derivatives of which are still being widely used by NASA. At Computer Cowboys, he designed the wonderfully named Sh-Boom microprocessor, and then co-founded iTV, an Internet Appliance manufacturer.

During the1990s, Moore used his own CAD software to design several custom VLSI chips, including the F21 processor with a network interface. More recently, he invented ColorForth and ported his VLSI design tools to it. His software is still in widespread use today.

“Chuck, I am right in saying Forth came out of Fortran? What was the background to developing Forth because designing a language in the 1960s was not something to be done lightly was it?”
“Fortran was the principal language in the late 60’s. But the work I did on my pre-Forth interpreter was done in Algol at Stanford. The first Forth was indeed written in Fortran on an IBM 1130 at Mohasco Industries. But the second Forth was written in Cobol, again at Mohasco. And the third Forth in assembler at NRAO.
The name Forth derived from fourth (as in generation) not from Fortran.
Forth became a language, not just an interpreter, at NRAO when I wrote a compiler for it. I was indeed intimidated by doing that since industrial-scale teams wrote compilers. But Forth was a very simple language and I approached it bottom-up, making sure I could add features as they became necessary.
The reason for writing a compiler was to make Forth faster. Not that it was too slow, but the scale of projects kept growing. I very much wanted an interactive language, so didn’t want the classic sequence of edit, compile, link and load. Forth simplified that to edit and load. That meant that library routines such as FFT had to be efficiently described in Forth. Forth has always been a language that compiles directly to RAM. The only object code is the kernel.”
“How did you get to work at the National Radio Astronomy Observatory (NRAO) and was your success down to Forth?”
“I met George Conant while I was working at SAO (Smithsonian Astrophysical Observatory) in Cambridge. I had a part time job computing predictions for the first artificial satellites. I learned Fortran to do this and wrote an input interpreter to avoid recompiling the program.
George was impressed and some years later, when I left Mohasco, he hired me to work for him at NRAO. I had since expanded that interpreter into Forth and proceeded to use it to program data collection and telescope control. He was disturbed by this because all other programming was done in Fortran.
Was my success do to Forth? Absolutely it was. Your characterization of weeks instead of years is correct: not only fast development of an application, but quick and easy modification of it.
The environment was particularly conducive to this. I spent several months during each thunderstorm season in Tucson, testing software on the radio telescope. I had to be productive to get anything done before observing resumed.
I’ve retained that style: Get a bare-bones application running quickly. Demonstrate it and get feedback from users. Then modify and expand capability: much more satisfactory than planning in advance.”
“Space-related applications of Forth include an amazing array of applications which include use in: the Shuttle, Rosetta and Deep Impact missions as, spacecraft flight system controllers, on-board payload experiment controllers, ground support systems and hardware or software used to build or test either flight or ground systems.
What’s your favourite application and why? It must have been an enjoyable time at the NRAO?”
“You seem to know more about Forth’s space-related applications than I do. I’m very pleased with them.
I think the reason is that Forth is well suited to resource-constrained situations. It doesn’t need lots of memory and doesn’t have much overhead. It can take full advantage of whatever hardware or interfaces exist. Moreover its inherently interactive nature shortens development time and improves reliability. So it’s appropriate for portable or mobile applications.
I was told of one application with synthetic aperture radar. Forth allowed debugging while on orbit.
I liked working for NRAO. It was fun because I could produce quick, impressive results. On the other hand, that was never a requirement. NRAO was associated with universities. Its headquarters was on the University of Virginia campus and the Tucson office at the University of Arizona. It was a very academic environment. That became frustrating because there was no pressure for results. I thought commercial applications would be more rewarding. But since then I’ve met too many people who want to make a career out of a project instead of completing it. That’s life.
My favorite application has to be OKAD, my VLSI design tools. I’ve spent more time with it that any other; have re-written it multiple times; and carried it to a satisfying level of maturity.
It’s an ambitious undertaking involving some 1400 blocks (Kilobytes) of source. The dictionary has to hold a thousand definitions. Actually there are many more, but not resident at the same time. With that many words, they can’t all be short, mnemonic English. So there are spelling conventions for naming things, which is generally unsatisfactory. But it works, with a little help from comments.
It’s an excellent example of factoring: breaking a problem into smaller pieces. This is very much a fractal process, with the lowest level being the machine-coded words that make everything else work.”
“After Forth came colorForth. Why did you develop it?”
“In about 2001 I was starting off on a new project: designing a multi-computer chip. I wasn’t real happy with OKAD 1. In particular, John Rible had been urging me to switch to a hierarchical design with asymmetric tiles. To do this I needed to sharpen the tools I was using. A simple version of Forth would do what I wanted, but I thought to try some new ideas. In particular, a smart editor that would simplify the compiler. Move some of the interpreter to the editor where it needn’t be repeated for each compile. This led to adding a tag to each word, preparsing words, packing characters, displaying in color. I have written many Forths and it doesn’t take long. A few weeks and I had not only colorForth, but the basic design of OKAD 2 and the chip. Of course, it took years to perfect.”
“What are the chief differences between Forth and colorForth.”
“ColorForth is a dialect of Forth. If you’ve mastered Forth, the transition to colorForth is quick and easy. The hard things about Forth are managing the parameter stack and factoring the application. These are the same. But there are significant differences. Charley, an enthusiastic supporter, recently said that colorForth is to Forth as Forth is to C. It’s simpler, prettier and more efficient.
Forth has some ugly punctuation that colorForth replaces by coloring source code. Each word has a tag that indicates function; it also determines color. This seems a small point, but it encourages the use of functions, such as comments or compile-time execution, that would be inconvenient in Forth.
By having words preparsed, the compiler is twice as fast. Another small point, since compiling is virtually instantaneous, but this encourages recompiling and overlaying the modules of an application. Smaller modules are easier to code, test and document than a large one.
There is a great similarity between colorForth and classic Forth: 1024-byte blocks. Factoring source code into blocks is equivalent to creating paragraphs in English. It breaks a wall of text into pieces that highlight related ideas. Many Forth implementations abandoned this advantage and organized source into files of arbitrary length. Bad idea. Hugely debated.
In addition, the text in a block can be displayed on a monitor without scrolling. A quantized unit of source code all visible at once. With that text in color, it’s easily readable and a joy to work with.
Forth has gradually become more complicated to suit the taste of contemporary programmers and the complexity of modern computers. ColorForth resets the style to simpler times. A good idea? Not many users yet.”
“Would you consider developing a new language from scratch?”
“No. I develop languages all the time. Each application requires one. But they’re all based on Forth. Forth has been called a language tool-kit. It is the starting point for an application language, much as the infant brain has the ability to learn any human language. Forth can do anything, but some things are easy. For example postfix notation. Many people, including me, have implemented infix notation. That’s not hard, but it doesn’t lead to any useful result. I believe in simple. I believe in efficient. And Forth embodies these.”
“Do you think education is the answer to developing better software and that somehow we will get away from the ‘we must do it first and ship it now no matter how buggy it is’ way of thinking?”
“Education is a good thing. But its lack is not the root cause of buggy software; lack of experience is. Software is never rewritten. Projects last longer than expected; programmers get bored or burned out; management moves on the newer challenges. The attitude of ‘good enough’ reflects reality.
Instead of being rewritten, software has features added. And becomes more complex. So complex that no one dares change it, or improve it, for fear of unintended consequences. But adding to it seems relatively safe. We need dedicated programmers who commit their careers to single applications. Rewriting them over and over until they’re perfect. Such people will never exist. The world is too full of more interesting things to do.
The only hope is to abandon complex software. Embrace simple. Forget backward compatibility. A simple word processor is easy. Would anyone learn to use it? It seems that there’s a window of willingness to learn to type. Once learned, people are not willing to relearn.”
“The technology industry has developed out of all recognition since you began your career what do you think are the good things about this sea-change and what are the bad?”
“I learned to type on a key-punch. The keystrokes were long and slow and noisy. For a while I had an IBM Electric typewriter. The touch was superb: soft and quiet with real tactile feedback. When I tried an IBM keyboard, I was bitterly disappointed. It clattered. Keystrokes were vague and noisy. Feedback was a joke. Didn’t cost much, though. Technology seems to be a random walk. Some things get better, some worse. It’s like evolution, not goal-directed. Cell phones get smaller, ’till you can’t use them; then they get bigger.
An example is USB, the Universal Serial Bus. It’s a success that people must cope with. It’s also a disaster. The universal protocols it dictates require a huge amount of software to support. To develop such software requires reading thousands of pages of specs. Which are neither complete nor accurate. So what happens? Someone develops an interface chip that encapsulates the complexity. And then you must learn to use that chip, which is at least as complex.
Complexity is the problem. Moving it from hardware to software, or vice versa, doesn’t help. Simplicity is the only answer. There was a product many years ago called the Canon Cat. It was a simple, dedicated word processor; done very nicely in Forth. Didn’t succeed commercially. But then, most products don’t.
I despair. Technology, and our very civilization, will get more and more complex until it collapses. There is no opposing pressure to limit this growth. No environmental group saying: Count the parts in a hybrid car to judge its efficiency or reliability or maintainability.
All I can do is provide existence proofs: Forth is a simple language; OKAD is a simple design tool; GreenArrays offers simple computer chips. No one is paying any attention.”
Tags: , , , ,


  • Rate
    [Total: 223    Average: 4.8/5]
  • Anonymous

    Nitpicking comment
    Interesting article – thanks – but it’s ‘descendAnt’, not ‘descendEnt’.

  • Andrew Clarke

    Re Nitpicking comment
    We fixed it, just to show we cared!

  • Greg Schmidt

    Forth as a philosophy for building things
    I share Chuck’s point of view. I work in a corporate software development environment where complexity rules. We continue to pile on features rather than propose simple models. Sadly, this style of development seems to be common in the industry. I use Forth, but only as a hobby for creating abstract games and puzzles with my Forth based meta-game system called “Axiom”. I find Forth ideal for that purpose, and find it very much to be a “building block” approach. It fits my personality well. Forth can also be viewed as a philosophy toward problem solving (See the book “Thinking Forth” available free on the web). It doesn’t seem to be for everyone though as it requires an open mind and willingness to abandon some things that have been drilled into you by the mainstream computing community (e.g. type safety).

  • Maria

    Memory Modules
    I recently came across your blog and have been reading along. I thought I would leave my first comment. I don’t know what to say except that I have enjoyed reading. Nice blog. I will keep visiting this blog very often.


  • Dean

    BTW Chuck has a Blog
    and other interesting tidbits on his web page at For example you can follow the progress of his latest effort in the Haypress Creek Blog.

  • Anonymous

    I was introduced to Forth almost 30 years ago and I still find it to be the finest language for developing and expressing ideas. For instrumentation and process control it is still unmatched. I feel so sorry for today’s students who have to wrestle with C++ and Ada just to connect a computer to the real world. Chuck was so right when he said “Complexity is wrong. It is wrong in human terms. It is wrong in computer terms”. Keep up the fine work Chuck!

  • Anonymous

    Forth is not all that it is cracked to be
    I have worked in very complex. Life saving related technologies. All the above sounds fine in principle but when you need redundancy, alerts, cross referencing. Things become irreducibly complex. Code is like life, inherently complex. Simple behaviour is hard to model let alone program, that is why we have complex systems. When you have interrelated systems with 10s of thousands of business rules, there are simply no shortcuts. I appreciate the thought but in practice I will stick to the megacomplex. Hard to map yes, but we there are still people out there with working brains that can make it happen.

  • Chuck C.

    That is my development philosophy, too…
    “Get a bare-bones application running quickly. Demonstrate it and get feedback from users. Then modify and expand capability: much more satisfactory than planning in advance.”

    I agree completely.

  • Greg Schmidt

    Re: Forth is not all that it is cracked to be
    No doubt the real world imposes complexities that just can’t be ignored and some of Chuck’s points may come across as overly idealistic. For me, the takeaway is that we should make every effort to limit software complexity to *essential* complexity (i.e. that which is inherent in the problem) and not add unnecessary complexity because we haven’t done our due dilligence in matching the software to the problem. Oftentimes, but not always, this may involve novel approachs to the problem.

  • D. Sandler

    Re: Forth is not all that it is cracked to be
    The problem with Forth is that it works and works well. I personally have used it in instrumentation and year long projects were completed in a week. Yes I agree that Forth is not a panacea, but I dont think Chuck ever said that. There are many applications that are inherently complex, but there are very few applications that will not benefit from ruthless pruning of complexity. As Chuck said “Simplicity provides power, compactness and speed.”

  • Anonymous

    Another language and environment that’s simple and productive specially when compared with the abomination that is C++ and that java is transforming into.

    Unfortunately I got spoiled by it and now developing in anything else most of the time is a pain.

  • Sam Jew

    The C++ Abomination
    The abominable aspects all stem from the fact that people keep lobbying to have *their* implementation be part of the language standard.

    I highly recommend Walter Savitch’s excellent book on C++. Template programming and operator overloading are listed in the appendix, I presume because they’re optional extras that you don’t really need to be an effective C++ programmer.

  • Mike O.

    Programmed in a 4GL for 20 years (NOMAD).
    While not everything is as promised, we were marching toward a simplified programming domain with NOMAD, RAMIS and FOCUS in the 80s and 90s. The idea was to get away from the “ivory towers”, and make programming available to the masses (well, somewhat). MVS JCL was the straw dog.

    Well, it worked…I taught engineers and secretaries how to program NOMAD (which was the first relational database around). SQL came out and crushed NOMAD, and returned programming to the mystic realm, as we moved from the mainframe to the client/server model.

    It will recycle again, I am sure. We sold NOMAD to Marketing and Sales, who needed quicker answers than traditional programming could give, they wanted RAD (Rapid Application Development). It is not long before peeps will get fed up with the time/money demanded by the new paradigm. Go FORTH…and yes…rapid prototyping is the only way to develop great software…and you have to love interacting with the users…I did and do.

  • Anonymous

    principal vs. principle
    “Fortran was the principle language in the late 60’s!” Principal, not principle. Please correct. The error makes Chuck look like an idiot.

  • Richard Morris

    principal or principle
    It could be either. Principal is normally an adjective meaning ‘main or most important’, whereas principle is normally used as a noun meaning ‘a basis of a system of thought or belief’.
    The problem is that the two words sound the same and automatic spell checkers can’t tell the difference.

  • Joerg Plewe

    This man is right!
    I really appreciate what Charles is saying and I feel the same very deep in my tortured mind!

  • Anonymous

    Vectored Execution
    I highly urge anyone who does realtime programming to study Forth’s use of vectored execution. Talk about power!

  • Bluebee

    Chuck Moore and Forth
    Thirty years ago I was developing microprocessor systems using a monitor program controlled by a hex keypad with 6 digits 7 segment LED’s. I had to program totally structured writing little modules each completely tested to achieve high goals like developing database software with a real keyboard and CRT. To ease my work I wrote a list with the modules addresses and made up the top program module as a list of these modules index numbers arbitrated by a little parser.

    This gave pretty nice and astonishing fast results, and I thought to further evaluate. But then I got the Byte magazine covering Forth.
    That changed my life. Chuck Moore had it all ready, much, much better than I ever could have done it. Since then I am using Forth for all my applications. Since the arrival of visualFORTH all my programming tools are up to date.

    Thanks, Chuck!

  • the Beez’

    Always a pleasure to listen to Chuck
    It’s always a pleasure to listen to Chuck although most interviews repeat the obvious. I’ve had my own Forth compiler for over 15 years now and although it uses files (blocks are the default for the builtin editor though) I still try to keep my definitions down to just a few lines. It’s fun to see how a complex program can be made with definitions that do not exceed a function prototype in C. A sysadmin once asked me to make a converter from an LDIF file to CSV. I wrote one in a matter of minutes. He wanted the source, so I printed it for him. It was about three quarters of a page. Then he checked the printer to see if the paper was out. That’s Forth.

  • the Beez’

    Always a pleasure to listen to Chuck
    It’s always a pleasure to listen to Chuck although most interviews repeat the obvious. I’ve had my own Forth compiler for over 15 years now and although it uses files (blocks are the default for the builtin editor though) I still try to keep my definitions down to just a few lines. It’s fun to see how a complex program can be made with definitions that do not exceed a function prototype in C. A sysadmin once asked me to make a converter from an LDIF file to CSV. I wrote one in a matter of minutes. He wanted the source, so I printed it for him. It was about three quarters of a page. Then he checked the printer to see if the paper was out. That’s Forth.

  • bpayne37

    Forth reliability
    VM type OSes appear to be more reliable than C/assembler OSes. Windows is an example of C/assembler.