stever@tree.uucp (Steve Rudek) (12/12/89)
In an earlier posting I said: >>Forth probably has the steepest learning curve of any language in existence. >>Given the severity of the learning curve, even "ordinary" levels of >>documentation are NOT sufficient. To which ir230@sdcc6.ucsd.edu (john wavrik) responded: > Forth *is* a very easy language to learn -- we've had many novices do very > well with it. But we have also had a few students who have trouble with it, > and I've tried to understand why. Perhaps you would agree with me if I substituted "longest" for "steepest"? Rabid Forth programmers have a bad habit of pointing to stupid "programs" like: ( LARGE LETTER-F ) : STAR 42 EMIT ; : STARS 0 DO STAR LOOP ; : MARGIN CR 30 SPACES ; : BLIP MARGIN STAR ; : BAR MARGIN 5 STARS ; : F BAR BLIP BAR BLIP BLIP CR ; as proof that Forth is easy to learn. I've got to admit there is nothing particularly steep about this program. But will you admit that it is a long, long way from typing a letter F to finishing a reasonable example of a "real" program such as an arcade game or a word processor? My point is that a newcomer to BASIC or Pascal or C can have an an application such as a basic word processor or arcade game *finished* while a newcomer to Forth is still trying to figure out the Forth dictionary and CREATE DOES>. With Forth you don't have the luxury of being able to ignore the internals of the language implementation. Until you pretty much know Forth like the back of your hand you haven't got a prayer of finishing a serious program. I had a polished arcade-style game written for my old Osborne within ten days of my first exposure to C. Ten days after my first exposure to Forth I was torn between shoving my floppies down the garbage disposal and jumping out of a window. THAT is the point I was trying to make. If you really disagree with me on this point then I'd suggest we have a little contest. And bet some significant money. We'd have to spend some time finding some cooperative and representative "beginning" programmers and laying out the ground rules, of course, but I'm serious. I'd enjoy a free vacation in San Diego. > The students who learn the language easily are those who believe me when I > say that VIEW, SEE and DUMP are the most important words in Forth. Agreed. F83 is the best system for learning Forth that I've ever seen, precisely because of its documentation, help system and shadow screens. But the hypertext help system built into Quick C is kind of nice, also. If you're trying to say that Forth is much easier to learn if you have proper training wheels, I agree. But fair is fair--beginning Forth programmers using F83 should compete with beginning C programmers using Quick C. > They also believe me when I say that the use of screens for source code is one > of Forth's strong points -- if their definition does not fit on a screen it is > because their ideas have not been clarified. They need to factor -- and, of > course, to test their definitions before they go on to the next screen. I'm getting off the track by responding to this but you're raising an issue which I've been thinking a whole lot about. Forth's terseness and the fact that it doesn't punish you with bad performance when you use a high level of factoring are things which I really admire. But I regard the rigid 64 column by 16 line "screen" as an anachronism which should have been replaced when teletypes and dinky CRT screens were replaced with 80 by 24 column terminals and bit-mapped computer screens. I'm seriously puzzled as to why someone hasn't experimented with variable-sized, pop-up, overlayable windows where each window could contain a single definition or, at the programmer's preference, a few highly associated definitions and data structures. In other words, refine the klunky screen concept and replace it with a "tree" or "network" editor: If you're editing a word and you wish to view or edit some previous word or data structure, just place your cursor on the desired word (or type it in) and bring up a window. Allow windows to be stacked as deep as necessary and just pop them (or move them to the side) when you are done. It should be possible to design a hashing or indexing scheme which would support very fast lookup of source and maybe even support compiling of definitions on a word by word demand basis rather than screen by screen. Such a system and editor would really showcase the unrivaled factorability of Forth, update Forth for the 1990's, and maybe even revive interest in the language. (Or is my idea seriously flawed?) Touting traditional screens as an example of "virtual memory" (it seems like all Forth books like to do this) has always seemed pretty laughable to me. These days, with hardware assisted virtual memory becoming commonplace in micros, I shouldn't be the only one laughing. (That reminds me of the hokey way that _Starting_Forth_ tried to sell Forth's lack of floating point support as a "feature," stopping just short of 'be glad you've been spared the temptation of ever using evil and slow floating point by your vendors courageous decision to not provide it!') > > [P.S. Things have been helped along by a good Forth screen editor. I used > a commercial one for my own work, but Nick Spies wrote a generic one. I will > be happy to supply a copy, customized for F83, by email.] I would appreciate it. I typed in Kelly and Spies' editor and have it basically working under F83, but if you have a more augmented version I would appreciate it. > There is a kind of mental barrier that exists for some people: they've been > trained to believe that what goes on underneath a language is so arcane that > only specialists (or hackers) can understand it. [The same kind of barrier > prevents many people from understanding mathematics.] In spite of all my disparaging remarks, I'm really attracted by Forth (God help me, why couldn't I feel this way about 'C' and be like all the other guys?). I feel that Forth has failed to achieve widespread popularity for good and deserved reasons. Forth programmers should wake up and smell the roses. If FIG advocated and supplied standardized libraries for things such as floating point and strings it would help a lot. Those who want to "roll their own" (I hear this phrase a lot from Forth programmers) could refuse to participate, but new programmers (at least) would have these libraries available and maybe Kelly and Spies would even be willing to write a version of their great book, FORTH: A Text and Reference, geared to this "standard" rather than just MMS-Forth. Hmmm. Maybe MMS-Forth should *become* the standard, so that K&S's book wouldn't need to be revised. P.S.> Perhaps there really is some good answer which doesn't speak badly of either Forth or Forth programmers, by why have there been so few successful, widespread, software programs written in Forth? All the Forth books like to talk about how Forth can be as fast as 'C' and more flexible and productive. So what's the problem? I find it hard to believe it's just that there aren't (and there never have been?) many Forth programmers. Could it be that Forth programmers *tend* to lack either the requisite ambitions or the patience to produce a significant, polished, friendly product? Or is the language actually not all it's cracked up to be in some regard? Virtually all Forth programs I've seen have been simplistic, unfinished, unfriendly or buggy. On the other hand, I've seen a lot of large, polished programs written in assembly, C, Pascal and even BASIC! -- {pacbell!sactoh0! OR ucdavis!csusac!}tree!stever