Also in: Croatian (Hrvatski)
The early development of FORTH was in many ways quite different from that of most other programming languages. Whereas they generally emerged full featured with unambiguous formal specifications for language syntax and semantics, Forth enjoyed a lengthy, dynamic adolescence, in which each fundamental presupposition of the language was tested on the anvil of actual applications experience. During this period, Moore, unencumbered by a large following of users, often made revolutionary changes to the language on a daily basis to suit his current view of what the language should be. He had complete control and responsibility for the machine at hand, from the first bootstrap loader to the completed application. The language converged toward the actual needs of one man solving a broad class of technically challenging problems in resource-constrained environments.
The resulting method of problem solving, expressed by the resulting de facto language specification, has proven useful to others. Given the complete flexibility to add syntax checking, data typing, and other more formal structures often considered essential to programming languages, most of the several hundred people who have independently implemented versions of Forth for their own use have not done so. The results of their efforts, as surveyed by the ANS Forth Technical Committee, represent a startlingly democratic ratification of Moore's personal vision.
without a formal language design specification citing clearly defined objectives, we can only evaluate the stated objectives of the inventor of the language and those who have used it. Personal productivity and intellectual portability were Moore's primary stated objectives. Forth has been ported across the vast majority of programmable computers and has been embodied in several different dedicated Forth computer architectures.
In 1979, Chuck Moore looked back on ten years' experience with Forth and observed [Moore, 1979]:
My original goal was to write more than 40 programs in my life. I think I have increased my throughput by a factor of 10. I don't think that throughput is program-language limited any longer, so I have accomplished what I set out to do. I have a tool that is very effective in my hands — it seems that it is very effective in others' hands as well. I am happy and proud that this is true.
Today he sees no reason to change this assessment.
The developers of FIG Forth saw their systems spread all over the world, along with chapters of their organization, and influence Forth programmers everywhere. Their goal of instantiating additional commercial vendors of Forth products was also achieved.
Of the many entrepreneurs who committed their careers and fortunes to Forth-based enterprises, few have become rich and famous for their efforts. But most have had the satisfaction of seeing their own productivity increased just as Moore did, and of having seen seemingly impossible project objectives met because of the power and flexibility of the language. They have also enjoyed prosperity in making this capability available to their clients and customers.
Given Moore's criteria of productivity and portability, perhaps the best measure of achieving these objectives is the very large quantity and range of application programs that have been written in Forth by a small number of programmers across a very broad variety of computers.
In 1984, Leo Brodie wrote a book on designing Forth applications called Thinking Forth [Brodie, 1984]. In it, he quoted a number of Forth programmers on their design and coding practices. In an Epilogue, several of them commented that Forth had significantly influenced their programming style in other languages, and indeed their approaches to problem solving in general. Here are two examples, which are typical of observations of Forth users in general:
[The] essence of good Forth programming is the art of factoring procedures into useful free-standing words. The idea of the Forth word had unexpected implications for laboratory hardware design.
Instead of building a big, monolithic, all-purpose Interface, I found myself building piles of simple little boxes which worked a lot like Forth words: they had a fixed set of standard inputs and outputs, they performed just one function, they were designed to connect up to each other without much effort, and they were simple enough that you could tell what a box did just by looking at its label.
Because Forth is small, and because Forth gives its users control over their machines, Forth lets humans control their applications. It's just silly to expect scientists to sit in front of a lab computer playing "twenty questions" with packaged software. Forth lets a scientist instruct the computer instead of letting the computer instruct the scientist.
Eastgate Systems, Inc., Cambridge, MA
Forth has changed my thinking in many ways. Since learning Forth I've coded in other languages, including assembler, BASIC and FORTRAN. I've found that I used the same kind of decomposition we do in Forth, in the sense of creating words and grouping them together.
More fundamentally, Forth has reaffirmed my faith in simplicity. Most people go out and attack problems with complicated tools. But simpler tools are available and more useful.
owner of Nautilus Systems, Santa Cruz, CA
Mitch Bradley reports [Bradley, 1991] that the design of the Forth-based Open Boot has significantly influenced the thinking of the people at Sun Microsystems who are responsible for the low-level interfaces in the Unix kernel. Open Boot design philosophy is influencing driver interfaces, the device naming system, and the early startup and configuration mechanisms. There is even talk of unifying the syntax of several disparate kernel configuration files by using Forth syntax and including a subset Forth interpreter in the Unix kernel. People at Sun who have worked with Open Boot are impressed by the fact that the simple postfix syntax never "runs out of steam" or "paints you into a corner."
Forth has a chameleon-like capacity to adapt to any particular application need. Indeed, the process of programming in Forth is to add to it application-oriented words at increasingly high levels until all the desired functionality is implemented. So for any project or even any particular programming group, any perceived needs will be promptly addressed. When looking for "mistakes," then, the most useful questions to ask are what were the things that a significant number of implementors have chosen to change or add, and what are the characteristics of the language that may have prevented its wider acceptance.
One of the first actions taken by the ANS Forth Technical Committee when it formed in 1987 was to poll several hundred Forth implementors and users to determine their views on problems in the language that needed to be addressed. The issues cited fell into three categories: "mistakes" in one or both of the existing standards (e.g., incompatibilities introduced by FORTH-83 and anomalies such as an awkward specification for arguments to DO); obsolete restrictions in FORTH-83 (mainly the reliance on a 16-bit architecture), and a need for standards for such things as host file access, floating point arithmetic, etc. Features in the latter group were by then offered by most commercial and many public-domain systems, but as they had been developed independently there was variance in usage and practice. ANS Forth has attempted to address all these concerns.
In retrospect, however, the lack of standard facilities for such things as floating point arithmetic, which are covered by other languages, has probably impeded widespread acceptance of Forth. It's insufficient to point out that most commercial systems offer them if the public perception of the language is formed by a standard that omits any mention of such features! From this perspective, the ANS Forth effort has come almost too late.
Another difficulty is that Forth's very identity is unclear: it is not only unconventional in appearance, with its reliance on an overt stack architecture and postfix notation, but it broadly straddles territory conventionally occupied by not only languages but also operating systems, editors, utilities, etc., that most people are accustomed to viewing as independent entities. As a result, it's difficult to give a simple answer to the question of what it is.
The integrated character of Forth is viewed by its practitioners as its greatest asset. As Bradley  expresses it,
Forth has taught me that 'firewalls' between different components of a programming environment (i.e., the different syntax used by compilers, linkers, command interpreters, etc.) are very annoying, and it is much more pleasant to have a uniform environment where you can do any thing at any level at any time, using the same syntax.
Duncan , however, believes that this seamless integration of Forth the language, Forth the virtual machine and Forth the programming environment is a significant barrier to mainstream acceptance. He notes that the same has been observed regarding Smalltalk vs. C++:
I have been using C++ for some months now, and the very things about C++ that frustrate me — the language is not written in itself (thus there is no way to use the building blocks for the programming environment as part of the application), the language is not truly extensible (e.g. the operators for the native data types cannot be overridden), and there is no programming environment that is smart about the language and class hierarchies — are the things that traditional language experts see as assets for C++ compared to Smalltalk!
So long as Forth users are convinced that its integrated, intrinsically interactive character is the key to their productivity as programmers, however, it is unlikely to change.
Some languages tend to be "levellers:" that is, a program written by an expert is unlikely to be significantly better (smaller, faster, etc.) than one written by a novice. Chuck Moore once observed [Moore, 1979], "…FORTH is an amplifier. A good programmer can do a fantastic job with FORTH; a bad programmer can do a disastrous one." While never quantified, this observation has been repeated on many Forth projects across a broad programmer population, and has achieved the status of "folk wisdom" within the Forth community.
This tendency has given Forth the reputation of being "unmanageable," and there have been some highly publicized "Forth disasters" (notably Epson's VALDOCS project in the early 1980's). On close examination, however, the root causes of this and other failed Forth projects are the same problems that doom projects using other languages: inadequate definition, poor management and unrealistic expectations.
There have also been a number of Forth successes, such as the facility management system for the Saudi Arabian airport mentioned above, in which a project that was estimated to contain 300,000 lines of executable Fortran, PLM and assembly language software was totally redesigned, recoded in Forth and tested to the satisfaction of the customer in only 18 months [Rather, 1985]. The result ran more than a factor of 10 faster.
Jack Woehr, a senior project manager for Vesta Technologies, observes [Woehr, 1991] that successful management of Forth projects demands nothing more than generally good management practices plus an appreciation of the special pride that Forth programmers take in their unusual productivity. Forth rewards a management style that believes a small team of highly skilled professionals can do a better job, in a shorter time, at less overall cost than a large group of more junior programmers.
What can be learned from twenty years' experience with Forth? Forth stands as a living challenge to many of the assumptions guiding language developers. Its lack of rigid syntax and strong data typing, for example, are characteristically listed as major advantages by Forth programmers. The informal, interactive relationship between a Forth system and its programmer has been shown through many projects to shorten development times in comparison with more conventional tools such as C. Despite the tremendous increases in the size and power of modern computers, Forth's combination of easy programming, compact size and fast performance (characteristics often thought to be mutually exclusive) continues to earn a loyal following among software developers, especially for embedded systems.