Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!willett!dwp From: dwp@willett.UUCP (Doug Philips) Newsgroups: comp.lang.forth Subject: Re: Teaching Pros Message-ID: <1255.UUL1.3#5129@willett.UUCP> Date: 1 Jul 90 14:36:38 GMT References: <11674@sdcc6.ucsd.edu> Organization: Latest link in the ForthNet chain. (Pgh, PA) Lines: 122 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]