Forth was invented by Charles H. (Chuck) Moore. A direct outgrowth of Moore's work in the 1960's, the first program to be called Forth was written in about 1970 [Moore, 1970a]. This section covers the early work leading to Forth.

Moore's programming career began in the late 1950's at the Smithsonian Astrophysical Observatory with programs to compute ephemerides, orbital elements, satellite station positions, etc. [Moore, 1958], [Veis, 1960]. His source code filled two card trays. To minimize recompiling this large program, he developed a simple interpreter to read cards controlling the program. This enabled him to compose different equations for several satellites without recompiling. This interpreter featured several commands and concepts that survived into modern Forth, principally a command to read "words" separated by spaces and one to convert numbers from external to internal form, plus an IF ... ELSE construct. He found free-form input to be both more efficient (smaller and faster code) and reliable than the more common Fortran practice of formatting into specific columns, which had resulted in numerous re-runs due to mis-aligned columns.

In 1961, Moore received his BA in Physics from MIT and entered graduate school at Stanford. He also took a part-time programming position at the Stanford Linear Accelerator (SLAC), writing code to optimize beam steering for the (then) pending two-mile electron accelerator, using an extension of some of his prior work with least-squares fitting. A key outgrowth of this work was a program called CURVE, coded in Algol (1964), a general-purpose non-linear differential-corrections data fitting program. To control this program, he used an enhanced version of his interpreter, extended to manage a push-down stack for parameter passing, variables (with the ability to explicitly fetch and store values), arithmetic and comparison operators, and the ability to define and interpret procedures.

In 1965, he moved to New York City to become a free-lance programmer. Working in Fortran, Algol, Jovial, PL/I and various assemblers, he continued to use his interpreter as much as possible, literally carrying around his card deck and recoding it as necessary. Minicomputers appeared in the late 60's, and with them teletype terminals, for which Moore added operators to manage character input and output. One project involved writing a Fortran-Algol translator and file-editing utilities. This reinforced for him the value of spaces between words, which were not required in Fortran source.

Newly married and seeking a small town environment, Moore joined Mohasco Industries in Amsterdam, NY, in 1968. Here he developed computer graphics programs for an IBM 1130 minicomputer with a 2250 graphic display. This computer had a 16-bit CPU, 8K RAM, his first disk, keyboard, printer, card reader/punch (used as disk backup!), and Fortran compiler. He added a cross-assembler to his program to generate code for the 2250, as well as a primitive editor and source-management tools. This system could draw animated 3-D images, at a time when IBM's software for that configuration drew only static 2-D images. For fun, he also wrote a version of Spacewar, an early video game, and converted his Algol Chess program into the new language, now (for the first time) called FORTH. He was impressed by how much simpler it became.

The name FORTH was intended to suggest software for the fourth (next) generation computers, which Moore saw as being characterized by distributed small computers. The operating system he used at the time restricted file names to five characters, so the "U" was discarded. FORTH was spelled in upper case until the late 70's because of the prevalence of upper-case-only I/O devices. The usage "Forth" was generally adopted when lower case became widely available, because the word was not an acronym.

Moore found the Forth-based 1130 environment for programming the 2250 superior to the Fortran environment in which the 1130 software was developed, so he extended it into an 1130 compiler. This added looping commands, the concept of keeping source in 1024-byte blocks and tools for managing them, and most of the compiler features we recognize in Forth today.

Most important, there was now a dictionary. Procedures now had names, and the interpreter searched a linked list of names for a match. Names were compiled with a count and three characters, a practice learned from the compiler writers of Stanford and which prevailed in Forth until the 1980's. Within a dictionary entry was a "code field" containing the address of code to be executed for that routine. This was an indirect threaded code implementation (see Section 5.2) and was in use five years before Dewar's paper on indirect threaded coded appeared in Communications of the ACM [Dewar 1975]. The use of indirect threaded code was an important innovation, since an indirect jump was the only overhead once a word had been found. Dictionary entries could consist either of pointers to other "high level" routines or of machine instructions.

Finally, in order to provide a simple mechanism for nesting routines, a second stack called the "return stack" was added. The benefit of having a stack reserved for return addresses was that the other stack could be used freely for parameter passing, without having to be "balanced" before and after calls. The first paper on Forth was written at Mohasco [Moore, 1970a]. In 1970 Mohasco assigned Moore to an ambitious project involving a new Univac 1108 handling a network of leased lines for an order-entry system. He ported Forth onto the 1108, and arranged for it to interface to COBOL modules that did the transaction processing. The 1108 Forth was coded in assembler. It buffered input and output messages and shared the CPU among tasks handling each line. It also interpreted the input and executed the appropriate COBOL modules. This version of Forth added mechanisms for defining and managing tasks, and also an efficient scheme for managing disk block buffers similar to schemes in use today. Unfortunately, an economic downturn led Mohasco to cancel the 1108 project before completion. Moore immediately gave notice, then wrote an angry poem and a book on Forth [Moore, 1970b] that was never published. It described how to develop Forth software and encouraged simplicity and innovation.

To Moore, Forth was a personal response to his frustration with existing software tools, which he viewed as a sort of "tower of Babel" [Moore, 1970a]:

The software provided with large computers supplies a hierarchy of languages: the assembler defines the language for describing the compiler and supervisor; the supervisor the language for job control; the compiler the language for application programs; the application program the language for its input. The user may not know, or know of, all these languages: but they are there. They stand between him and his computer, imposing their restrictions on what he can do and what it will cost.

And cost it does, for this vast hierarchy of languages requires a huge investment of man and machine time to produce, and an equally large effort to maintain. The cost of documenting these programs and of reading the documentation is enormous. And after all this effort the programs are still full of bugs, awkward to use and satisfying to no one.

Moore conceived of Forth as replacing the entire "vast hierarchy" with a single layer, requiring only two elements: a programmer-to-Forth interface, consisting of minimal documentation (minimal because the interface should be simple and natural), and the Forth-machine interface, consisting of the program itself. His view was entirely personal, considering his own needs in the light of his own experience. The following excerpts from his unpublished book [Moore, 1970b], describe this view:

I've written many programs over the years. I've tried to write good programs, and I've observed the manner in which I write them rather critically. My goal has been to decrease the effort required and increase the quality produced.

In the course of these observations, I've found myself making the same mistakes repeatedly. Mistakes that are obvious in retrospect, but difficult to recognize in context. I thought that if I wrote a prescription for programming, I could at least remind myself of problems. And if the result is of value to me, it should be of value to others....

Above all, his guiding principle, which he called the "Basic Principle," was, "Keep it simple!" Throughout his career he has observed this principle with religious dedication.

As the number of capabilities you add to a program increases, the complexity of the program increases exponentially. The problem of maintaining compatibility among these capabilities, to say nothing of some sort of internal consistency in the program, can easily get out of hand. You can avoid this if you apply the Basic Principle. You may be acquainted with an operating system that ignored the Basic Principle.

It is very hard to apply. All the pressures, internal and external, conspire to add features to your program. After all, it only takes a half-dozen instructions, so why not? The only opposing pressure is the Basic Principle, and if you ignore it, there is no opposing pressure.

The main enemy of simplicity was, in his view, the siren call of generality that led programmers to attempt to speculate on future needs and provide for them. So he added a corollary to the Basic Principle: "Do not speculate!"

Do not put code in your program that might be used. Do not leave hooks on which you can hang extensions. The things you might want to do are infinite; that means that each has 0 probability of realization. If you need an extension later, you can code it later — and probably do a better job than if you did it now. And if someone else adds the extension, will he notice the hooks you left? Will you document this aspect of your program?

This approach flew in the face of accepted practice then as now. A second corollary was even more heretical: "Do it yourself!"

The conventional approach, enforced to a greater or lesser extent, is that you shall use a standard subroutine. I say that you should write your own subroutines.

Before you can write your own subroutines, you have to know how. This means, to be practical, that you have written it before; which makes it difficult to get started. But give it a try. After writing the same subroutine a dozen times on as many computers and languages, you'll be pretty good at it.

Moore followed this to an astounding extent. Throughout the 70's, as he implemented Forth on 18 different CPUs (Table 1), he invariably wrote for each his own assembler, his own disk and terminal drivers, even his own multiply and divide subroutines (on machines that required them, as many did). When there were manufacturer-supplied routines for these functions, he read them for ideas, but never used them verbatim. By knowing exactly how Forth would use these resources, by omitting hooks and generalities, and by sheer skill and experience (he speculated that most multiply/divide subroutines were written by someone who had never done one before and never would again), his versions were invariably smaller and faster, usually significantly so.

Moreover, he was never satisfied with his own solutions to problems. Revisiting a computer or an application after a few years, he often re-wrote key code routines. He never re-used his own code without re-examining it for possible improvements. This later became a source of frustration to Rather, who, as the marketing arm of FORTH, Inc. (see Section 2.2), often bid jobs on the assumption that since Moore had just done a similar project this one would be easy — only to watch helplessly as he tore up all his past code and started over.

Today, Moore is designing Forth-based microprocessors using his own Forth-based CAD system, which he has re-written (and sometimes rebuilt, with his own hardware) almost continuously since 1979.

Moore considered himself primarily an applications programmer, and regarded this as a high calling. He perceived that "systems programmers" who built tools for "applications programmers" to use had a patronizing attitude toward their constituents. He felt that he had spent a great fraction of his professional life trying to work around barriers erected by systems programmers to protect the system from programmers and programmers from themselves, and he resolved that Forth would be different. Forth was designed for a programmer who was intelligent, highly skilled and professional; it was intended to empower, not constrain.

The net result of Moore's philosophy was a system that was small, simple, clean — and extremely flexible: in order to put this philosophy into practice, flexible software is essential. The reason people leave hooks for future extensions is that it's generally too difficult and time-consuming to re-implement something when requirements change. Moore saw a clear distinction between being able to teach a computer to do "anything" (using simple, flexible tools) and attempting to enable it to do "everything" with a huge, general-purpose OS. Committing himself to the former, he provided himself with the ideal toolset to follow his vision.