Commodore Free 28/Commodore_Free_Issue_28_2009_Commodore_Computer_Club.d64/evolution

Text File | 2023-02-26 | 15KB | 497 lines

u


**************************
* The Evolution of Forth *
**************************
Commodore Free; would like to thank
"Forth Inc" for its help with
articles about Forth language. The
original article can be found here,
reprinted below is just a small
section of what is available online:

 http://www.forth.com/resources/
  evolution/index.html

Forth Inc also have a very nice
online version of the classic book
Starting Forth this is still
considered a classic book about the
Forth language and you will see its
name pop up many times the full
online book is available from here:
 http://www.forth.com/starting-
  forth/Abstract

Forth is unique among programming
languages in that its development and
proliferation has been a grass-roots
effort unsupported by any major
corporate or academic sponsors.
Originally conceived and developed by
a single individual, its later
development has progressed under two
significant influences: professional
programmers who developed tools to
solve application problems and then
commercialized them, and the
interests of hobbyists concerned with
free distribution of Forth. These
influences have produced a language
markedly different from traditional
programming languages
Authors
Elizabeth D. Rather
FORTH, Inc.
5959 W. Century Blvd..
Suite 700
Los Angeles, CA 90045

Donald R. Colburn
c/o Digital Media Magic
14712 Westbury Rd.
Rockville, MD 20853

Charles H. Moore
Computer Cowboys
40 Cedar Lane
PO Box 127
Sierra City, CA 96125

Presented at the ACM SIGPLAN History
of Programming Languages Conference
(HOPL II, April, 1993). 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.

*************************************
* Chuck Moore's Programming Language*
*       Early Development           *
*************************************

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 and was
in use five years before Dewar's
paper on indirect threaded coded
appeared in Communications of the ACM
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 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
that was never published. It
described how to develop Forth
software and encouraged simplicity
and innovation

Philosophy and Goals
To Moore, Forth was a personal
response to his frustration with
existing software tools, which he
viewed as a sort of "tower of Babel"

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 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 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
& 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.
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

==================================