Joe Knapka's post
Date: Wed, 07 Apr 2004
Subject: Re: ANN : Forth Versus C - some Infrequently Asked Questions
Jeff's reply:
Agreed. I'm trying to like Forth, but a lot of the Forth evangelism
really reads as if it's directed toward cult members: "People who use
other languages often think X, Y, or Z. Those people are misguided;
you can tell because it takes them three times as long to write their
code. They don't care about making high-quality products; only *we*
care about making high-quality products. Drink the Kool-Aid now..."
It's really quite a turn-off. I've produced what I consider to be
high-quality products in perhaps a dozen different languages; I don't
really like being told that's impossible.
It usually works better to simply say, "Welcome to Language X, which
is based on the W principle: everything is a Widget. This Widget-
centric approach addresses the following specific perceived
shortcomings of the object-oriented, functional, and thingamajig-based
paradigms: .... Language X also provides the following specific
unique features that are not available in any other language: ..."
People who are intrigued by the introduction will then dive in
and write some code, and decide for themselves whether they like
it.
Let's see.
"Welcome to Forth, a mid-level, interactive, stack-based
language. Forth's interactive and stack-based nature addresses the
following specific perceived shortcomings of other mainstream
languages:
- Unlike many popular languages, Forth is fully-interactive; no
edit/compile/test cycle is required. Instead, you can edit and run
code directly from the Forth command line. This means that
exploratory programming is very easy in Forth. (However, the fact
that control structures usually can't be used outside procedure
definitions somewhat limits one's ability to run ad-hoc code at
the command prompt. [Does any Forth permit loops etc in
interpreted code?])- Unlike many popular scripting languages, Forth can compile
directly to native code, which means you can have native-code
performance in a fully-interactive environment.- Unlike many popular languages, Forth does not impose any
particular structure to your code (no "everything is an X"); you
are free to use procedural, structured, object-oriented, and
limited functional techniques as circumstances warrant. (However,
you may need to build your own toolbox.)- Unlike virtually all popular languages, a complete Forth
development environment can run in a surprisingly small memory
footprint (a few 10's of K for a really large, highly-functional
implementation), and without an underlying general-purpose
operating system. Furthermore, the Forth compiler typically
produces very compact object code. This makes Forth ideal for
exploratory programming in embedded and resource-constrained
environments.- Unlike most popular languages, Forth makes it possible and natural
to directly manipulate the hardware on which the Forth system
runs. Such direct manipulation can be done from the Forth command
line -- another advantage when doing exploratory development in
embedded environments.- Unlike most popular languages, Forth is extensible - it allows the
programmer to add to the language facilities (such as control
structures) that are completely indistinguishable from the
built-in facilities. Forth takes you beyond the ability to design
libraries, and makes you a partner in the design of the language
itself; building a high-level language atop the Forth environment
is therefore fairly simple. Further, any such high-level language
can be made immediately available to the user as well as the
programmer. (Note: do not use this power in the service of evil!)- Unlike nearly all popular languages, the internal structure of a
Forth development environment is extremely simple and easy to
understand, even for folks with little programming experience.
While to an experienced C programmer, for example, Forth may seem
to be full of strange inconsistencies and edge cases, a full
understanding of the nature of Forth makes it clear that all of
its features are natural consequences of its simple and elegant
implementation; and such a full understanding is easy to achieve.
Date: 11 Apr 2004
I would have probably said something similar to describe Forth
in my first twenty years of working with the language. I have
come to think of it as the most common misconception about Forth
among Forth programmers.
Forth is based on the word. Words are like subroutines but
shorter. To facilitate Forth style factoring of code into
words a parameter passing stack is used.
Words also are names. To allow to programmer to focus on the
things that are important enough to be given names there is a
parameter stack where items do not have names.
These aspects of Forth address shortcomings of languages with
rigid syntax and unchangable keywords. The use of short word
definitions increased code re-use and eliminates much of the
work required in other languages to duplicate sections of
their own code. Short word definitions are easier to write,
debug, and maintain.
Forth only requires single pass compilation which in combination
with the use of highly factored code facilitates very fast
compilation times and supports a very fast interactive edit-
compile-test cycle. Forth uses a dictionary to contain and
access words by their name. The dictionary is similar to
the ubiquitous file directories that most programmers use
except that they are early bound and under explicit control
of the programmer while file directories add runtime overhead
by being late bound and remove control from the programmer to
give it to a file system.
In short, Forth uses two stacks as a mechanism to support
a language based on space delimited words. I think it helps
to realize that Forth is word based, not stack based.
If a programmer focuses on stacks as the basis of the language
it is likely that a programmer will not be as focused on factoring
into words, will write stack juggling routines, or may even start
giving stack items names.
I know for the first twenty years that I did Forth while thinking
of it as a stack based language I wrote more code than I needed to
write and made it less readable, less maintainable, and generally
speaking experienced less productivity than when I approached
Forth as a word based language. Of course I am sure that there
were other factors as well that contributed to my learning to
use the language more effectively.
In the light of Jeff's reminder that "Forth is based on the word," it might be a good idea to have a look at one of the classic references for writing clear English: William Strunk's Elements of Style
Compare:
The use of short word definitions increased code re-use and eliminates much of the work required in other languages to duplicate sections of their own code. Short word definitions are easier to write, debug, and maintain.
to:
Vigorous writing is concise. A sentence should contain no unnecessary words, a paragraph no unnecessary sentences, for the same reason that a drawing should have no unnecessary lines and a machine no unnecessary parts. This requires not that the writer make all his sentences short, or that he avoid all detail and treat his subjects only in outline, but that every word tell.
No comments:
Post a Comment