Forth Values

The basic values of ForthLanguage:

Note: there seems to be an overlap in values between Forth, as expressed in the quotations below, and the practice of ExtremeProgramming (XP), specifically in the patterns of DoTheSimplestThingThatCouldPossiblyWork and YouArentGonnaNeedIt. --Michael Losh

(especially LeoBrodie 's ThinkingForthTips -- ToddCoram)

Using Forth is what really taught me about refactoring. --KrisJohnson

Excerpts from a talk "1x Forth" by Charles Moore (ChuckMoore) April 13, 1999:

How do you get there? What is the magic? How can you make applications small? Well you can do several things that are prudent to do in any case and in any language.

No Hooks

One is No Hooks. Don't leave openings in which you are going to insert code at some future date when the problem changes because inevitably the problem will change in a way that you didn't anticipate. Whatever the cost it's wasted. Don't anticipate, solve the problem you've got.

Don't Complexify

Simplify the problem you've got or rather don't complexify it. I've done it myself, it's fun to do. You have a boring problem and hiding behind it is a much more interesting problem. So you code the more interesting problem and the one you've got is a subset of it and it falls out trivial. But of course you wrote ten times as much code as you needed to solve the problem that you actually had.

Ten times code means ten times cost; the cost of writing it, the cost of documenting it, the cost of storing it in memory, the cost of storing it on disk, the cost of compiling it, the cost of loading it, everything you do will be ten times as expensive as it needed to be. Actually worse than that because complexity increases exponentially.

10x Code
10x Cost
10x Bugs
10x Maintenance

Ten times the bugs! And ten times the difficulty of doing maintenance on the code as is amply illustrated by the Y2K bug. In fact it is curious that the fixes that I see people making COBOL programs to fix the Y2K bug make the programs significantly more complex and larger and introduce spaghetti code that can't be maintained and is probably going to fail again in fifty years. They are just using windows. They are not increasing the range of the date they are merely shifting it so that is going to lead to another problem when that window runs out.

This is why we are still running programs which are ten or twenty years old and why people can't afford to update, understand, and rewrite these programs because they are significantly more complex, ten times more complex than they should be.

So how do you avoid falling into this trap. How do you write one times programs?

One times, 1x That would make a good name for a web page.

You factor. You factor, you factor, you factor and you throw away everything that isn't being used, that isn't justified.

The whole point of Forth was that you didn't write programs in Forth you wrote vocabularies in Forth. When you devised an application you wrote a hundred words or so that discussed the application and you used those hundred words to write a one line definition to solve the application. It is not easy to find those hundred words, but they exist, they always exist.

From the Forth ANSI standard (Appendix C of the final draft):

Conventionally, software projects progress through four stages: analysis, design, coding, and testing. A Forth project necessarily incorporates these activities as well. Forth is optimized for a project-management methodology featuring small teams of skilled professionals. Forth encourages an iterative process of successive prototyping wherein high-level Forth is used as an executable design tool, with stubs replacing lower-level routines as necessary (e.g., for hardware that isn't built yet).

In many cases successive prototyping can produce a sounder, more useful product. As the project progresses, implementors learn things that could lead to a better design. Wiser decisions can be made if true relative costs are known, and often this isn't possible until prototype code can be written and tried.

Using Forth can shorten the time required for software development, and reduce the level of effort required for maintenance and modifications during the life of the product as well.

Excerpts from the History of Forth: http://www.forth.com/resources/evolution/index.html

[Note: the quotes are from an unpublished book written in 1970]

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.

Similar in flavor to DoTheSimplestThingThatCouldPossiblyWork and RefactorMercilessly. -- IanOsgood

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?

In other words, YouArentGonnaNeedIt. -- IanOsgood

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.

[...]

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.

[...Why is working with Forth more productive?...]

The obvious answer seemed to lie in the interactive nature of Forth. The programmer's attention is never broken by the procedural overhead of opening and closing files, loading and running compilers, linkers, loaders, debuggers, etc. But there's more to it than that. For example, all the tools used by Forth's OS, compiler, and other internal functions are available to the programmer. And, as Chuck Moore intended, its constraints are minimal and its attitude is permissive. Forth devotees still love to debate the source and magnitude of such productivity increases!

[...Description of Forth model and features...]

These features enable Forth programmers to write code in short, easily testable modules that are automatically integrated into an application. Programming is fully structured, with consistent rules of usage and user interface for both assembler and high-level programming. Words are tested incrementally, while the desired behavior is fresh in the programmer's mind. Most new words can be tested simply by placing input values on the stack, typing the word to be tested and validating the result left on the stack by displaying it.

NOTICE [for the History of Forth paper]

This paper was given at the ACM SIGPLAN History of Programming Languages Conference (HOPL II) in April, 1993. It was published in ACM SIGPLAN Notices, Volume 28, No. 3 March 1993.

Permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee and/or specific permission.

HOPL II/4/93/MA, USA �1993 ACM 0 89791 571 2/93/00004/ 0177...$1.50

Also see http://www.colorforth.com/binding.html. Bear in mind that ChuckMoore's values don't completely coincide with those of most Forth users.

CategoryForth