\ This file is from the Forth SIG on CompuServe. NOVICE.TXT/binary 06-Feb-88 5760 11 Keywords: LEARNING TEXT BLOCKS WRITE-ONLY Some general notes on learning and using Forth from the perspective of a novice user. -Doug Hoffman Some notes on Forth from a novice user: -------------------------------------- By Doug Hoffman February 6, 1988 CHOOSING FORTH In mid '85 I had finally decided to purchase my first microcomputer, a Macintosh. I knew that I would also want a programming language to use with it, but was unsure of which. All of my programming training and experience was in Fortran from college. I knew that I wanted something more powerful than Basic, but was somehow dissatisfied with Fortran. In Fortran it seemed that as a program's complexity and length increased, my ability to revise or add to it decreased. I asked a friend, who happened to be a Motorola sales rep, what he would recommend. His response was a wistful, "I can always do something faster in Forth". Having never heard of this language, I trotted off to the local library and luckily stumbled across Leo Brodie's STARTING FORTH. I was intrigued (and amused) and decided to "go Forth". ON LEARNING FORTH After spending an entire weekend wrestling with blocks files, stacks, and the like, I was horrified and convinced that I had made a mistake. Who in their right mind would want to program in this godforsaken language! One error I made was in immediately trying to port over my favorite Fortran program. I had no feel for the concept of information hiding and factoring, and I tried to write Forth code that paralleled the Fortran code. Of course I wound up with extremely long word definitions that were impossible to read or work with. In hindsight, I think that I was somewhat impatient and at least half of the frustration I experienced was caused by the complexity of programming the Macintosh (I wanted to do windows, menus, controls, etc. right away). Fortunately I stuck with it and eventually began to appreciate Forth and learn to use it. After two years I am hooked and can't imagine what features another language could offer to pull me away from Forth. One thing that helped was my prior familiarity with RPN calculators. I didn't want to give up the notion that the stack grew "upwards". I think now I have decided that the stack should be thought of as growing "sideways" (to the left). This seems more consistent to me with stack notation, even though we are told to think of the stack as growing "downwards". Trivial issue. THE WRITE-ONLY LANGUAGE InfoWorld's Steve Gibson has called Forth a "write only" language ( Infoworld, Oct.26,1987). I assume by that he meant that he has trouble reading and understanding code that he has written in Forth. Early on, it also annoyed me to write mathematical expressions in Forth that didn't look anything like the expression would if I were to write it out with pencil and paper. Later, it occurred that the most difficult task for me, when writing and reading my source code, was to be able to follow the overall flow, branching, and logic. For me, Forth proved to be far superior to Fortran and Basic in doing this. Correctly coding a simple mathematical expression in Forth takes a little more work than doing so in an "algebraic" language, but the extra work spent is trivial when compared to that saved in being able to follow the overall program flow. Besides, is T=(L/C)/((1-(V**2)/(C**2))**.5 really that easy to read? I think that when the expressions become complex, the stack becomes equal to or superior than algebraic notation. TEXT VS BLOCKS FILES I liken the argument of text vs blocks as being loosely similar to calculators vs slide rules. Some old timers still maintain that learning to use a slide rule was good for you, and you somehow had a better understanding of the calculation than if you had used a calculator. I never understood the intrinsic intellectual value of sliding together pieces of wood and lining up crosshairs. Okay, the ability to do rough estimates in the head is important, I just don't think that you need to use a slide rule to learn to do that. Likewise, writing concise code in modular packets is also a desirable skill. But you don't need blocks to do that. I agree with what I think Don Colburn has said. It all depends on the quality of the tools available. Certainly there are some very good blocks editors and some not so good text file editors. The Sibley Editor is nothing short of marvelous, in my opinion. If there were a blocks editor that could read my thoughts, then MAYBE I'd give up the Sibley Editor. CHAINING VS SCRIPT FILES I have no problem in breaking my program up into smaller file segments (Variables and Arrays, Windows and Controls, Text Routines, Main Program, Menus, etc.). This makes the program conceptually easier for me to think about. It also saves paper when I change part of my code and want to update the hard copy. At first I was writing script files that would include all of the files that made up my programs. This worked fine. But later I found that if instead I began each file with ANEW and ended it with a statement to INCLUDE the next file, it worked out better. This way if I needed to change some code in, for example, the third file of ten that were chained together, I merely had to open the third file, make the changes and "Save & Include" that file. Only files three thru ten were then recompiled. Very quick. Even quicker when used with enough ram cache so that the only disk access was for file three. Perhaps someone else has a better idea. I'm interested in hearing about other techniques. MISCELLANEOUS Hey, I'm no computer jock. I start getting lost when I read about things like DOER>MAKE, IMMEDIATE, TOKEN.FOR, etcetera. But that's okay with me. I am getting far more performance out of Forth than I did with other languages.