ir230@sdcc6.ucsd.edu (john wavrik) (06/30/90)
Doug Philips writes:
% I once asked Wavrik (via proxy when he was a guest on FIG's GEnie
% RoundTable) if there were any particular methods that were effective
% in helping programmers already proficient in other languages to
% unlearn their bad habits and learn Forth. The response was not very
% heartening.
Here is what I said (and it was intended to be encouraging):
<[John W]> I think Forth has to be met on its own terms..
<[John W]> I stress this -- so that my students know that they are not..
<[John W]> just dealing with a conventional language..
<[John W]> I probably present Forth in a way that most conventional
languages are not presented...
<[John W]> I teach it in terms of how it is implemented...
<[John W]> (It is one of the few languages that can be taught that way..
<[John W]> As a result, rather than looking at syntax (how things are
said)..
<[John W]> The focus is on semantics (what things mean, or do)...
<[John W]> The orientation is different from the beginning..
<[John W]> and I think it helps students confront Forth as it is..
Let me amplify a bit. First let's talk about utility.
Question:
What has more utility
(a) A pile of wood, a hammer, a bag of nails and a saw
OR (b) A wooden doghouse?
Answer: If what you want is a wooden dog house, then the wooden
dog house has more utility. If you have in mind a shed for garden
tools (or, in fact, anything other than a dog house) the building
materials have more utility. A dog house is just a dog house -- the
building materials can be used not only to build dog houses but,
more importantly, structures exactly designed for your needs.
Forth is a toolshop language rather than a toolbox language. A toolbox
has things like screw drivers, hammers, nuts and bolts, etc. A
toolshop has lathes, welders, drill presses, etc. A toolshop contains
tools to build screw drivers, hammers, etc. There is nothing novel in
the idea that jobs are done best when a worker uses the proper tools
and can become almost impossible with unsuitable tools. What is novel
is the idea that toolbuilding can be simplified to the point where it
is quicker and easier to make yourself the proper tools: making a
hammer rather than trying to build a house driving nails with the
handle of a screwdriver.
What Charles Moore did for computer programming is to show how to
dramatically increase the utility of a computer language by providing
access at a lower than customary level. Moore provides the programmer
with the tools needed to build the language itself and, just as
important, has made these tool-building tools simple. In a quest to
solve a larger variety of problems, conventional languages have
responded by making larger and heavier toolboxes -- Moore has,
instead, improved the toolshop making it accessible, powerful and
simple.
My students have already seen other languages -- so I don't have to
explain why computer languages need control structures or what a stack
is. Exposure to conventional languages tends to produce a mindset
which regards a language as something defined by syntax diagrams and
which regards the toolshop as complicated and off limits. What better
way to introduce students to the idea of a simple and powerful
workshop than to show them how it is used to build the language -- and
how the syntax falls into place when one understands the actions of
the words. The worst thing that one can do with Forth is to teach it
as if it were a conventional language with a funny syntax.
The idea of teaching Forth by introducing SEE, VIEW and DUMP very
early in the game works very well for people who know something about
programming. The approach is not really unusual. In mathematics,
students are often faced with a choice: either memorize 1000 formulas
or understand the 10 simple ideas which are responsible for them -- so
the subject is taught by going for the ideas. Just as in Forth, the 10
ideas have greater utility than the 1000 formulas -- so students wind
up with not only a better understanding but with a simpler approach
and more power.
That being said, one should also not go overboard in stressing the
unconventional nature of Forth. Moore's work, in many areas,
anticipated the path that mainstream computer science has taken.
Programming in Forth does not require a bizarre style -- well written
Forth is a lot like well written anything else. A good part of a
course in Forth just deals with the process of taking ideas and
translating them into correct computer programs. In 10 years of
teaching Forth, I have never had a student whose programming in other
languages was not improved by a course in Forth.
There is one problem that does arise. Charles Moore has observed that
Forth is an amplifier: it exposes rather than covers up deficiencies
in programming. I regard this as a good thing. If a student cusses
out Forth -- don't jump in immediately to defend the language -- ask,
instead, to see some samples of things he has written in his favorite
language -- you may discover that the help he needs goes beyond Forth.
I don't think that Forth is particularly difficult to learn. My course
is in Computer Algebra rather than Forth per se. I mix programming
tasks, mathematics, and language instruction together and the course
is more about mathematics and algorithms than Forth -- yet most of
the students can do simple projects within the first few weeks and
fairly complex projects by the end of 10 weeks. I should mention that
I use a traditionally implemented Forth for the course (I've used Kitt
Peak VAX-Forth, MVP, and now F83). I can't guarantee that things will
work out as well if you insist on using a Teenage Mutant Ninja Forth.
John J Wavrik
jjwavrik@ucsd.edu Dept of Math C-012
Univ of Calif - San Diego
La Jolla, CA 92093 dwp@willett.UUCP (Doug Philips) (07/01/90)
Before I pester you further with more questions/comments... Thank you for such a detailed reply. I appreciate(d) it. -dwp ir230@sdcc6.ucsd.edu (john wavrik), in <11674@sdcc6.ucsd.edu>, writes: > <[John W]> I think Forth has to be met on its own terms.. > <[John W]> I stress this -- so that my students know that they are not.. > <[John W]> just dealing with a conventional language.. > <[John W]> I probably present Forth in a way that most conventional > languages are not presented... > <[John W]> I teach it in terms of how it is implemented... > <[John W]> (It is one of the few languages that can be taught that way.. > <[John W]> As a result, rather than looking at syntax (how things are > said).. > <[John W]> The focus is on semantics (what things mean, or do)... > <[John W]> The orientation is different from the beginning.. > <[John W]> and I think it helps students confront Forth as it is.. Ok, I'll buy that. It strikes me very much as the way assembly languages are taught, perhaps with the same difficulties of perspective/orientation? > Forth is a toolshop language rather than a toolbox language. > ... What is novel > is the idea that toolbuilding can be simplified to the point where it > is quicker and easier to make yourself the proper tools: making a > hammer rather than trying to build a house driving nails with the > handle of a screwdriver. Point taken. BTW: I think one of the things that has been going on between the Minimalists and the Kitchen-Sinkists is along these lines. Personally I'd prefer a toolshop that already has some standardized tools in it. Not mandatory, but available. Presumably there is enough experience with building houses that I could reasonably expect to find a hammer in the toolshop already. Even if I have to make my own sledge for pounding in the stakes for the concrete forms, I'd expect to find a utility hammer at least already there. I should be able to remove it as well. I think the idea of "extended wordsets" fits this bill perfectly. > What Charles Moore did for computer programming is to show how to > dramatically increase the utility of a computer language by providing > access at a lower than customary level. Moore provides the programmer > with the tools needed to build the language itself and, just as > important, has made these tool-building tools simple. I think this is an important point. The tool shop itself is even simple enough that one person can easily understand and modify it (meta-compile/target compile) if necessary. However, I think such things can also undermine the portability of Forth. If the toolshop you use to build your tools is itself non-standard, your programs (blueprints?) are not going to easy be useable by someone else. I think that this is a fundamental tension between Forth's maverick-icity and any standards effort(s). This is also related to the toolshop/toolbox difference. The current standards effort (as I perceive it now) is trying to come to a common ground for both the toolshop ( / NOT ... ) and the toolbox ( File I/O, memory management ). As far as I can tell, the current brouhaha over / and NOT has more to do with existing practice than with any philosophical argument over the "Forth-ness" of one definition or another. The "Forth-ness" debate seems centered about the extended-wordset/toolbox issues. (Do I understand your analogy here or have I gone off into east hyperspace?) > The worst thing that one can do with Forth is to teach it > as if it were a conventional language with a funny syntax. Ok. How would you relate teaching Forth to teach assembler? Do you think the same style is appropriate for both? Often assembly language classes get bogged down teaching things like math in bases 2,8,16; what bits bytes, words, memory addressing, etc. are. Ignoring such "incidentals," I've made an analogy (hardly unique or hardly the first to do so) that Forth is like assembler for a very very CISCy machine. (In that it often has a larger number of pre-defined instructions [words]). Forth departs from assembler in the mechanisms by which you can write new instructions vs. writing subroutines. I've not yet convinced myself, one way or the other, whether this is a significant difference or not. Sometimes I think Forth is more like microcode than macro code, but that may not be a useful difference to make either. On the negative side, assembler isn't usually taught with a difference in system-constructing-philosophy the way Forth is. I think some of the factoring philosophy does tend to come out in assembly language programmers simply because of the level of complexity that has to be managed, but the degree to which that factoring is explicitly made a "goal" rather than a "side-effect" has more to do with the instructor than the language. > In 10 years of > teaching Forth, I have never had a student whose programming in other > languages was not improved by a course in Forth. [...] > There is one problem that does arise. Charles Moore has observed that > Forth is an amplifier: it exposes rather than covers up deficiencies > in programming. I regard this as a good thing. These are the most encouraging things I've found so far! Is this amplification and its side-effects part of the "improvement effect" you mentioned above? Or do you think the "improvement effect" is due more to the discipline necessary to write Forth, or ...??? > I don't think that Forth is particularly difficult to learn. Perhaps, but to learn it well? One can write Forth in the style of Basic, or C, or what have you (and the reverse is true too). I guess my question really should have been: is there anything other than sheer repetition that helps in unlearning the "style" of the profane languages or in learning the "style" of *good* Forth. I'm not looking for a "royal road" to Forth, though I think I'm sounding that way. I'm really look for "habit"-breaking/"habit"-forming techniques that are particulary useful for learning Forth. My current best guess is the assembler analogy. > I should mention that > I use a traditionally implemented Forth for the course (I've used Kitt > Peak VAX-Forth, MVP, and now F83). I can't guarantee that things will > work out as well if you insist on using a Teenage Mutant Ninja Forth. I'm curious as to your distinction between traditional and T.M.N. Forths. Do you mean indirect threading vs. subroutine threading, or the wordset that comes with the Forth, or ??? -Doug --- Preferred: willett!dwp@hobbes.cert.sei.cmu.edu OR ...!sei!willett!dwp Daily: ...!{uunet,nfsun}!willett!dwp [in a pinch: dwp@vega.fac.cs.cmu.edu]