DAVID@PENNDRLS.BITNET (07/26/88)
mailrus!caen.engin.umich.edu!stejk@ames.arc.nasa.gov (Steven J Kassarjian) writes: > Personal Experience. As much as I've used Fortran (I'm a ChE), I >doubt I ever will _think_ in Fortran. For the short period of time I >used Forth (one class project), I started to think (and dream) in Forth. >(I was under a lot of pressure, too!) (strange :-) You know, you're right. I never thought about that before. I have done most of my programming in FORTRAN, but also work in C and assembler. FORTH, despite (because of?) its unusual 'syntax', is the only one that falls off my fingers naturally. I suspect that this is because the size of a FORTH 'program' (word) is closer to the size of a 'thought' than is a traditional language subroutine. This may in fact be far more important than the 'rapid prototyping' and high interactivity of FORTH development. (Not that I'm knocking either, mind you; they are both very important.) I am also fascinated by the NC4000. 4000 gates and it is effectively more powerful than the 68000. _That_ really says something for the elegance and power of the FORTH philosophy. KISS, but with the last S standing for 'smart'. I am gratified to know that the resulting programs are faster than comparable traditional chips, as well as smaller. -- R. David Murray (DAVID@PENNDRLS.BITNET, DAVID@PENNDRLS.UPENN.EDU) P.S.: For the person who asked about beginners books, I also highly recommend Leo Brody's books. 'Thinking FORTH' is probably the best book on programming I have ever read. But, then, I am biased toward FORTH.
orr@cs.glasgow.ac.uk (Fraser Orr) (07/27/88)
>FORTH, despite (because of?) its unusual 'syntax', is the only one that >falls off my fingers naturally. I suspect that this is because the size >of a FORTH 'program' (word) is closer to the size of a 'thought' than is >a traditional language subroutine. This may in fact be far more If what you are saying is that traditionally people wrote subroutines in Fortran, C etc that were too long, I agree. But if you also are saying that the solution is to throw away these languages and use Forth, I totally disagree. It seems to me a much better solution is to encourage people to program properly ( i.e. with thought sized subroutines.) > >I am also fascinated by the NC4000. 4000 gates and it is effectively >more powerful than the 68000. _That_ really says something for the >elegance and power of the FORTH philosophy. KISS, but with the last >S standing for 'smart'. I am gratified to know that the resulting >programs are faster than comparable traditional chips, as well as >smaller. It is quite interesting to hear all you forth programmers going on about how wonderful it is that you have microprocessors that can run your favourite language. I say this because chips like 68000, 80386 32000 etc, are chips specifically designed to run languages like C. I would be interested to see any exprimental results comparing the preformance of a Forth chip running forth compared with a 68000 running C. ==Fraser Orr ( Dept C.S., Univ. Glasgow, Glasgow, G12 8QQ, UK) UseNet: {uk}!cs.glasgow.ac.uk!orr JANET: orr@uk.ac.glasgow.cs ARPANet(preferred xAtlantic): orr%cs.glasgow.ac.uk@nss.cs.ucl.ac.uk
ns@cat.cmu.edu (Nicholas Spies) (07/29/88)
A couple of years ago Alan Winfield (University of Hull, GB) showed a Forth computer implemented in microcode at the Rochester Forth Conference. The C provided with it ran at 1/3rd the speed of the underlying Forth... So there... :-) -- Nicholas Spies ns@cat.cmu.edu.arpa Center for Design of Educational Computing Carnegie Mellon University
DAVID@PENNDRLS.BITNET (07/29/88)
Fraser Orr writes: >If what you are saying is that traditionally people wrote subroutines in >Fortran, C etc that were too long, I agree. But if you also are saying >that the solution is to throw away these languages and use Forth, I >totally disagree. It seems to me a much better solution is to encourage >people to program properly ( i.e. with thought sized subroutines.) Agreed. My programming in all languages has improved since I learned FORTH (specifically since I read `Thinking FORTH'). And no, I don't think we should throw away traditional languages. When a language is suited to a problem, I use that language. For example, when I want to crunch numbers, I use FORTRAN. If I want to write a UNIX utility program, I use C. There is a limit to the extent to which one can apply the `small is better' philosophy in a traditional language, however. At some point the overhead of a subroutine call makes smallness impractical. C's macro facility goes a long way toward alleviating that problem, though. Yet even when I write what I feel is an appropriately sized subroutine in C, it is still larger visually than the corresponding FORTH program and therefore harder to grasp and think about. At this level we are talking about a small difference, but that, after all, is what religious arguments are all about! :-) >> I am gratified to know that the resulting >>programs are faster than comparable traditional chips, as well as >>smaller. >It is quite interesting to hear all you forth programmers going on about >how wonderful it is that you have micro-processors that can run your >favorite language. I say this because chips like 68000, 80386 32000 >etc, are chips specifically designed to run languages like C. I would be >interested to see any experimental results comparing the preformance of a >Forth chip running forth compared with a 68000 running C. I'm sorry, I thought that *was* what we were talking about. But you are right, the original poster was probably discussing FORTH-only benchmarks. I will reserve my enthusiasm until I hear the kind of comparison you request. (Designing a fair benchmark may be a little tricky though, come to think about it.) -- R. David Murray (DAVID@PENNDRLS.BITNET, DAVID@PENNDRLS.UPENN.EDU)
olorin@juniper.uucp (David Weinstein) (07/31/88)
In article <1534@crete.cs.glasgow.ac.uk> orr@cs.glasgow.ac.uk (Fraser Orr) writes: >> >>I am also fascinated by the NC4000. 4000 gates and it is effectively >>more powerful than the 68000. _That_ really says something for the >>elegance and power of the FORTH philosophy. KISS, but with the last >>S standing for 'smart'. I am gratified to know that the resulting >>programs are faster than comparable traditional chips, as well as >>smaller. > >It is quite interesting to hear all you forth programmers going on about >how wonderful it is that you have microprocessors that can run your >favourite language. I say this because chips like 68000, 80386 32000 >etc, are chips specifically designed to run languages like C. >I would be interested to see any exprimental results comparing the >preformance of a Forth chip running forth compared with a 68000 running >C. > Pick your time and place. The Novix chip is very flawed (brain-damaged) in fact, however even so, it is quite powerful (around 5 MIPs). However, Novix sold the technology to Harris, who has just released the RTX chip, which fixes *all* of the problems with the Novix, and is clocking in at 8-12 MIPs. These chips have an assembly language (hard wired, not in uCode) which contains many of the Forth primitives, and because of its multiple internal busses, it can execute more than one low level Forth word in one clock cycle (including in many cases the ability to make the return from subroutine as part of the last primitive). I got a chance to play with one of these little silicon gems yesterday, and they are fast...very very fast. What type of testing system were you proposing to see which is faster? -- Dave Weinstein Internet: olorin@walt.cc.utexas.edu UUCP: {ames,utah-cs,uunet}!ut-sally!ut-emx!{walt.cc.utexas.edu,juniper}!olorin
orr@cs.glasgow.ac.uk (Fraser Orr) (08/01/88)
In article <2479@pt.cs.cmu.edu> ns@cat.cmu.edu (Nicholas Spies) writes: >A couple of years ago Alan Winfield (University of Hull, GB) showed a Forth >computer implemented in microcode at the Rochester Forth Conference. The C >provided with it ran at 1/3rd the speed of the underlying Forth... >So there... :-) Hmmh, interestingly enough, I know of a certain 68000 machine, that runs a simulator for a 6502 machine. Suprisingly the 68000 simulator runs slower than the original 6502, therefore (this is a Nicholas Spies version of therefore) the 68000 is a slower processor than the 6502, QED. ;^> ==Fraser Orr ( Dept C.S., Univ. Glasgow, Glasgow, G12 8QQ, UK) UseNet: {uk}!cs.glasgow.ac.uk!orr JANET: orr@uk.ac.glasgow.cs ARPANet(preferred xAtlantic): orr%cs.glasgow.ac.uk@nss.cs.ucl.ac.uk
orr@cs.glasgow.ac.uk (Fraser Orr) (08/01/88)
In article <8807291946.AA14510@jade.berkeley.edu> Forth Interest Group International List <FIGI-L%SCFVM.bitnet@jade.berkeley.edu> writes: > >Agreed. My programming in all languages has improved since I learned >FORTH (specifically since I read `Thinking FORTH'). And no, I don't In what way? Do you mean that since reading the holy book you have been able to design your programs better? If so, wonderful. But really, programming language and program design are separate issues. If you want to know about program design I can recomend several books that deal with the topic in a lanugage independent way, thus you see how DESIGN ideas fit (e.g., the concept of a named parameter, or a labeled variable) and how these fit in with your language of choice (in Forth, no named parameters, and a rather tacky idea of labeled variables.) If I gave Kernighan and Richie's book on C, and you read it, you would undoubtedly learn sopmething about program design (though in K&R's case not a lot), but you would have to spend a lot of your time ignoring all the guff about the language. If you want to learn about program design, read a book about program design, not about Forth program design! >think we should throw away traditional languages. When a language is >suited to a problem, I use that language. For example, when I want >to crunch numbers, I use FORTRAN. If I want to write a UNIX utility >program, I use C. There is a limit to the extent to which one can >apply the `small is better' philosophy in a traditional language, >however. At some point the overhead of a subroutine call makes smallness >impractical. C's macro facility goes a long way toward alleviating This is a totally spurious point. The only differences between a forth subroutine call and a C call is that C has to make a stack frame (i.e., *allocate* a small amount of memory on the top of the stack), the parameters have to be put there in but languages, the return address has to be put in by both langnuages, the PC has to be set in both languages, in fact C calls are going to be at most 1usec slower than Forth ones, not in my opinion worth worrying about. This of course assumes that the forth program has been compiled onto a Forth microprocessor, if it's interpreted, well ... >that problem, though. Yet even when I write what I feel is an >appropriately sized subroutine in C, it is still larger visually than >the corresponding FORTH program and therefore harder to grasp and >think about. At this level we are talking about a small difference, :fact dup 0 gt else 1 then dup 1 sub fact if ; vs int Fact ( n ) { if ( n > 0 ) return n*fact(n-1) else return 1 ; } If you find the former easier to understand, you've got a twisted mind! (PS apoligies for my forth, it has been a while since I wrote any, and after all it is not the most memorable syntax:^) >>how wonderful it is that you have micro-processors that can run your >>favorite language. I say this because chips like 68000, 80386 32000 >>etc, are chips specifically designed to run languages like C. I would be >>interested to see any experimental results comparing the preformance of a >>Forth chip running forth compared with a 68000 running C. > >I'm sorry, I thought that *was* what we were talking about. But you are >right, the original poster was probably discussing FORTH-only benchmarks. >I will reserve my enthusiasm until I hear the kind of comparison you >request. (Designing a fair benchmark may be a little tricky though, >come to think about it.) I know what you mean. I no great fan of benchmarks, I suppose the best comparison would be comparing the adequacy of performance of a real program witten in Forth and a real program written in C. An interesting idea might be to think of some problem that both Forth'ers and C'ers claim their language is good at, and measure the time taken to write the program, the "preformance" of the operational program, and perhaps if you were keep, the ease of understanding of the program to a programmer who hadn't seen the program before. (If you really want to see Forth bite the dust, you could also compare the ease of understanding of the program to rookie programmers, hmmh...) P.S. I may have given the impression above that I am a greate fan of C. Not true, I think C is tacky in the extreme, but Forth has all of the problems of forth, and few of the saving graces. ==Fraser Orr ( Dept C.S., Univ. Glasgow, Glasgow, G12 8QQ, UK) UseNet: {uk}!cs.glasgow.ac.uk!orr JANET: orr@uk.ac.glasgow.cs ARPANet(preferred xAtlantic): orr%cs.glasgow.ac.uk@nss.cs.ucl.ac.uk
caasnsr@nmtsun.nmt.edu (Clifford Adams) (08/03/88)
In article <1552@crete.cs.glasgow.ac.uk> orr%cs.glasgow.ac.uk@nss.ucl.ac.uk (Fraser Orr) writes: [much of article deleted] |:fact dup 0 gt else 1 then dup 1 sub fact if ; | |vs |int Fact ( n ) |{ | if ( n > 0 ) | return n*fact(n-1) | else | return 1 ; |} |If you find the former easier to understand, you've got a twisted |mind! (PS apoligies for my forth, it has been a while since I wrote |any, and after all it is not the most memorable syntax:^) Ahem. The sample of Forth code is not a realistic one. Try these comparisons. This is how Forth should be written, and how C is often written. Forth: ----- \ Factorial routine. Returns n! : factorial recursive ( n -- n! ) dup 0 > if dup 1- factorial * else 1 then ; C: -- /* factorial routine. Returns n! */ int factorial(n) {if(n>0) return(n*factorial(n-1));else return(1);} See! You can write C functions on a single line too! Now, which is more legible? >==Fraser Orr ( Dept C.S., Univ. Glasgow, Glasgow, G12 8QQ, UK) >UseNet: {uk}!cs.glasgow.ac.uk!orr JANET: orr@uk.ac.glasgow.cs >ARPANet(preferred xAtlantic): orr%cs.glasgow.ac.uk@nss.cs.ucl.ac.uk Now, I'll list some of the advantages and disadvatages I see in Forth. The following only apply to reasonably written Forth--it is possible to make a mess in almost any language. Advantages. ---------- 1. Forth is extremely compact, often more compact than reasonably written assembly language. Forth is usually more compact than the output of a compiler. 2. With appropriate hardware, Forth runs fast. Many MIPS fast, with gates on the order of 10,000. 3. Forth's compiler is simple. Because of this simplicity, Forth compiles very fast. Forth's compiler is also simple to change (just add IMMEDIATE words). 4. Forth's stack is a good place to store temporary results. This means fewer variables such as MISC and TEMP. 5. Forth can be easier for the final user to use. Compare the following, where the function rotate takes an angle and an appendage. Forth allows words to be defined which act as adjectives or adverbs. Forth: 90 left arm rotate C: rotate(90,left||arm) ; 6. Forth is usually run as an interpreter until the program is ready to be destination-compiled. Debugging (especially when working with hardware) can be much easier. In C, extensive test scaffolding is often needed because functions cannot be called interactively. Disadvantages. ------------- 1. Forth is seen as "strange" by much of the computing world. This does appear to be changing somewhat. 2. There is no true standard for Forth. This has hurt Forth in two main ways: A. No standard file system interface has been created. B. Floating point tools are non-standard. 3. No 32-bit standard (yet). 4. The usage of the stack often leads to stack-manipulating code breaking up higher-level parts of code. 5. Forth can die horribly from simple mistakes, like swapping a variable and a value before storing. 6. The hardware needed to run Forth most effeciently is not widely availible yet (I can't walk into a store and pick up a Forth machine). Well, that's enough for now. -- Clifford A. Adams --- "I understand only inasmuch as I become." ForthLisp Project Programmer (Goal: LISP interpreter in Forth) caasnsr@nmtsun.nmt.edu ...cmcl2!lanl!unm-la!unmvax!nmtsun!caasnsr
DAVID@PENNDRLS.BITNET (08/03/88)
Fraser Orr writes: >[I write:] >>Agreed. My programming in all languages has improved since I learned >>FORTH (specifically since I read `Thinking FORTH'). And no, I don't > >In what way? Do you mean that since reading the holy book you have been >able to design your programs better? If so, wonderful. But really, >programming language and program design are separate issues. If you want >to know about program design I can recomend several books that deal >with the topic in a lanugage independent way, thus you see how DESIGN >ideas fit (e.g., the concept of a named parameter, or a labeled >variable) and how these fit in with your language of choice (in Forth, Yes, please (if you have a minute), I *would* be interested in a good book on program design from a language independent point of view. I am curious to see how the tradeoff between program size and subroutine call overhead is presented. I also look forward to improving my programming some more; this is *not* a facetious request. Part of the motivation behind my remark was that Thinking FORTH taught me to decompose problems into subroutines in ways that I would not have thought of from my traditional language background. I am interested in finding out what the current theories of program design are, but I haven't found a good book yet. (Haven't looked too hard yet, either.) >no named parameters, and a rather tacky idea of labeled variables.) "?" he says, with a puzzled frown. :-) My definition of a 'named parameter' is: a constant referred to throughout a program or set of programs by a symbolic name. In which case a FORTH constant fits the bill very well. If what you are looking for is a way to assign a constant a name during compilation and have the compiler substitute the real value into the compiled program, then you are no longer being language independent. A litteral (a constant compiled directly into a FORTH word) executes more slowly than a FORTH constant. If it is referred to more than once, it also occupies more memory. (disregarding headers, which any good target compiler will have deleted.) Of course, if we are talking about different concepts my point is moot. What's a labeled variable? (I know, I know: 'read the book'. :-) O.K, which book?) >If I gave Kernighan and Richie's book on C, and you read it, you would >undoubtedly learn sopmething about program design (though in K&R's case >not a lot), but you would have to spend a lot of your time ignoring >all the guff about the language. If you want to learn about program >design, read a book about program design, not about Forth program >design! This is not really a valid comparison. Kernighan and Richie is a book about a language that happens to also talk about program design in that language. Thinking FORTH is a book about program design using FORTH as the vehicle for illuminating its points that happens to also talk about some specifically FORTH design issues. This is, of course, not the same as talking about program design independent of any language. Still, if you want to firmly ground a concept it helps to give examples, and FORTH is better for some examples than any other language. Just as LISP, or even C, is better for others. So I think I can have learned some things from Thinking FORTH that I would not have learned by reading a language independent design book. (Which won't stop me from doing both!) >>however. At some point the overhead of a subroutine call makes >>smallness impractical. C's macro facility goes a long way toward >>alleviating > >This is a totally spurious point. The only differences between a forth >subroutine call and a C call is that C has to make a stack frame (i.e., >*allocate* a small amount of memory on the top of the stack), the >parameters have to be put there in but languages, the return address has >to be put in by both langnuages, the PC has to be set in both languages, >in fact C calls are going to be at most 1usec slower than Forth ones, >not in my opinion worth worrying about. This of course assumes that the >forth program has been compiled onto a Forth microprocessor, if it's >interpreted, well ... Hmm. You're right; if you properly design a C program it can be *almost* as fast as a FORTH program compiled on an 'equivalent' FORTH microprocessor. Slower by more than you think, though. In most FORTH programs the arguments to a word are already on the stack fairly often, rather than needing to be moved into place. Ditto for removing them afterward. And on a FORTH micro, the FORTH return from subroutine is faster. Add up the number of subroutine calls in a fair sized program, and we are talking about a significant difference. Still, I would be willing to bet that, assuming 'equivalent' underlying chips, one could write a C program and a FORTH program that would do the same job equally efficiently, but the average subroutine size in the C program would have to be larger (though perhaps not much larger). So I don't think my point is completely spurious. Of course, I have no way of testing it, so you should feel free to not change your mind :-). (Hmm. It might be worth comparing a direct threaded FORTH to a C on the same micro . . . that I may be able to try some day. I suspect the results would be very similar.) >>that problem, though. Yet even when I write what I feel is an >>appropriately sized subroutine in C, it is still larger visually than >>the corresponding FORTH program and therefore harder to grasp and >>think about. At this level we are talking about a small difference, > >:fact dup 0 gt else 1 then dup 1 sub fact if ; > >vs >int Fact ( n ) >{ > if ( n > 0 ) > return n*fact(n-1) > else > return 1 ; >} > >If you find the former easier to understand, you've got a twisted >mind! (PS apologies for my forth, it has been a while since I wrote >any, and after all it is not the most memorable syntax:^) Let's try: int Fact ( n ) : Fact ( n -- n! ) { VS Dup if ( n > 0 ) -- 0= If return n*fact(n-1) Drop 1 Exit else Else return 1 ; Dup 1- Fact } * Then ; (Excuse me, but didn't you forget to declare n?) I find the two approximately equally understandable. I wrote the FORTH after almost a year of writing no FORTH code and looking at very little, but got it right on the first try. *I* find FORTH's syntax memorable. I learned C and then did not use it for a year, and when I tried to write a C program I got bit by the '=' vs. '==' distinction and had to look up the syntax of the for and while constructs. I think I remember them now, but I wouldn't bet on it. To see what I mean by visually larger, let's try: void CFormatOK(Count,Args) : CFormatOK ( a n -- ) int Count; 1 ?REXXArgs char **Args; 0 Arg UpperCase { ?Devid char *Devid,*OutType,*Format; ?OutputName REXXArgs(Count,1); VS ?FormatName UpperCase(Args[0]); -- ?EndArg Devid = DevidCheck(Args[0]); FormatOK OutType = OutTypeCheck(Args[0]); REXXReturn Format = FormatNameCheck(Args[0]); ; NoMore(Args[0]); REXXReturn(FormatOK(Devid,OutType,Format)); } I drew this example from a C program I threw together the other month; don't worry about what it does. The point is that the FORTH is smaller visually. True, this also means the FORTH version does not convey as much information about the arguments to the subroutines as the C version, but I find that information more distracting than helpful. As long, that is, as I am consistent in how my FORTH subroutines handle arguments. Given that I know what the subroutines do (which anyone studying the code would have to learn anyway) I can see at a glance what the FORTH version does, whereas my eyes and mind have to do more work to get the same information out of the C version. My conclusion, I think, is that FORTH encourages small subroutines (which you agree is good) and C does not, and that even when the subroutines are of the same size code wise, the FORTH subroutines are smaller mentally. Since a good programmer can program well in any language, I'll program (when I can) in FORTH, and you can program in whatever language *you* prefer. -- R. David Murray (DAVID@PENNDRLS.BITNET, DAVID@PENNDRLS.UPENN.EDU)
jesup@cbmvax.UUCP (Randell Jesup) (08/05/88)
In article <1552@crete.cs.glasgow.ac.uk> orr%cs.glasgow.ac.uk@nss.ucl.ac.uk (Fraser Orr) writes: >>however. At some point the overhead of a subroutine call makes smallness >>impractical. C's macro facility goes a long way toward alleviating > >This is a totally spurious point. The only differences between a forth >subroutine call and a C call is that C has to make a stack frame >(i.e., *allocate* a small amount of memory on the top of the stack), >the parameters have to be put there in but languages, the return address >has to be put in by both langnuages, the PC has to be set in both languages, >in fact C calls are going to be at most 1usec slower than Forth ones, >not in my opinion worth worrying about. This of course assumes that >the forth program has been compiled onto a Forth microprocessor, >if it's interpreted, well ... Wrong on multiple counts. First, the use of a stack paradigm reduces the amount of parameter pushing being done. A lot of C-generated code consists of retrieving values from the last stack fram and pushing them onto the new one. Good subroutine-threaded forth implementations give up nothing to C on the same machine (for example, 68000). Forth can have optimizers too, no forth-chip needed. I grant forth might be a bit of a dog on a 8088, but it works well on a 68000 (auto-increment/ decrement, lots of registers to hold important values/stack ptrs, etc.) >>that problem, though. Yet even when I write what I feel is an >>appropriately sized subroutine in C, it is still larger visually than >>the corresponding FORTH program and therefore harder to grasp and >>think about. At this level we are talking about a small difference, > >:fact dup 0 gt else 1 then dup 1 sub fact if ; A few problems with that, try this: : fact ( n -- n! - compute n!) dup >0 if dup 1- fact * else drop 1 endif ; More readable, isn't it? Forth doesn't have to be unreadable, though many old forth implementations which use blocks for source often are. >vs >int Fact ( n ) >{ > if ( n > 0 ) > return n*fact(n-1) > else > return 1 ; >} > >If you find the former easier to understand, you've got a twisted >mind! (PS apoligies for my forth, it has been a while since I wrote >any, and after all it is not the most memorable syntax:^) >who hadn't seen the program before. (If you really want to see Forth >bite the dust, you could also compare the ease of understanding of the >program to rookie programmers, hmmh...) Not if the "rookie" has ever used an HP calculator. -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup
skip@rafos.gso.uri.edu (Skip Carter) (06/07/90)
I just received a catalog from: MicroProcessor Engineering Ltd.
In it Leo Brodie's book 'Thinking Forth' is listed with the price of 14.75
Pounds. I haven't called them to confirm that the book is really available,
but those of you that are looking for copies of this book before it utterly
disappears might want to get in touch with them.
MicroProcessor Engineering Ltd.
133 Hill Lane Shirley
Southhampton SO1 5AF England
Tel: 0703 631441
They list a USA dealer as AMICS, phone number: 716-461-9187wmb@MITCH.ENG.SUN.COM (09/20/90)
> wondering if this is true...? do you seasoned Forth programmers like or > dis-like [ Thinking Forth ] I'm not crazy about it. I think that it codifies and attempts to justify a lot of the things that are holding Forth back (e.g. BLOCKs, prefix string operators). My copy is all marked up with things I disagree with. Nevertheless, it's worth reading. There is a lot of helpful stuff in it. Just don't believe everything it says. Mitch Bradley, wmb@Eng.Sun.COM
DAVID@PENNDRLS.BITNET (09/20/90)
I loved Thinking Forth when I first read it, and it changed my (programming) life forever. But I agree with Mitch, there is a bunch of stuff in there justifying things FORTH does that I simply don't agree with. Nevertheless, it shook me out of my complacency about my programming methods, made me figure out *why* I did what I did, and encouraged me to find new ways that were better (and some of my 'new improved' techniques I did take almost whole cloth from the book). I guess my recommendation about the book is read it, absorb it, think about it, but *don't* use it as a bible. More of a Gloss, remembering that there are as many different glosses of the Bible as there are gloss authors :-). Thinking Forth is one of the best (possibly the best) glosses on Forth, but there is always room for interpretation and disagreement (as this list demonstrates almost daily!) -- R. David Murray (DAVID@PENNDRLS.BITNET, DAVID@PENNDRLS.UPENN.EDU)