Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!think!ames!pacbell!sactoh0!tree!stever From: stever@tree.uucp (Steve Rudek) Newsgroups: comp.lang.forth Subject: Re: porting an MS-DOS Forth to a 386 Unix/Xenix Summary: Why people "expect to get good Forths for free" Keywords: MS-DOS, Forth, porting, source, help Message-ID: <1989Nov29.204348.4416@tree.uucp> Date: 29 Nov 89 20:43:48 GMT References: <1989Nov20.211822.1015@tree.uucp> <5317@sdcc6.ucsd.edu> <6420@tekgvs.LABS.TEK.COM> Organization: TREE BBS (916)349-0385 Sacramento, Ca Lines: 128 In article <6420@tekgvs.LABS.TEK.COM>, toma@tekgvs.LABS.TEK.COM (Tom Almy) writes: > Why is it that people are willing to pay good money for other languages, > but expect to get good Forths for free? Why did I decide to make a few bucks > (and *very* few) with Forth when I could have made it rich with a > "politically correct" language used by people with $money$? A good question. I've been stewing on an answer for about 10 years. First of all we need to settle on a definition of "good money". I've purchased a number of languages through the years, including: Software Toolworks' C (cpm) $50 Laboratory Microsystems' Z80 Forth (cpm) $50 FIG Forth (cpm) (public domain, but I probably spent about $50 between disks and source listings) Turbo Pascal (msdos) $50 Turbo Pascal version 3.0 (msdos) approx. $50 for update Turbo Prolog (msdos) $70 Turbo C (msdos) $70 Abundance/BBL Forth (msdos) public domain, but I spent $75 Some comments and observations: (1) I've never spent over $100 on ANY language. I don't know how common my parsimony is, but I don't feel too apologetic. Borland products have been uniformly EXCELLENT (for my purposes) for less than $100 so why should I spend more than $100 for a language implementation which is only "good"? (2) I've purchased 3 different Forths over the years, including LMI Z80 Forth. I haven't gotten even a "good" version yet. BEFORE YOU FLAME ME, let me explain. In my opinion, a good software product must be (a) friendly (b) COMPLETE (c) bug free (d) powerful/flexible (e) WELL DOCUMENTED. The strategy I follow to learn a new language is to cursorily read the documentation and then jump in with both feet to write a non-trivial application which I've been thinking about writing in some other language. This strategy has never worked with Forth because (a) none of the Forth implementations I've seen have had adequate documentation to accomodate an experienced programmer who happens to be new to Forth and (b) to quote from a recent Harvard Softworks Forth advertisement: Forth has to [sic] often been the language that tempted programmers with 'great expectations', then frustrated them beyond all endurance with the need to reinvent the simplest tools expected in any commercial language. How am I supposed to react when I sit down to learn Forth by writing a full screen arcade-style game for my PC and find out that *I* first need to write a slough of primatives to perform basic file manipulation, string manipulation and floating point math? There are some further hitches, of course. Before I can undertake to write these primatives I really need to write a decent full screen editor since the vendor doesn't include one and I can't use Wordstar on Forth BLK files. And before I can write either the editor or the primative operations I really need to be an experienced Forth programmer. Oh, yeah, and before you can become an 'experienced Forth programmer' I need to understand esoterica such as DOES> CREATE and the operation of the dictionary and inner interpreter. Of course the vendor doesn't adequately document these esoterica or provide any real examples of their use. Generally the vendor is nice enough to refer you to _Starting_Forth_. Of course, _Starting_Forth_ (unlike K&R's _The_C_Programming_Language_) doesn't document the esoterica, either, but only the simple stuff. Oh well. You can always buy a FIG assembly language listing and try to figure out DOES> CREATE from reading that and examining chicken entrails. (By the way, Kelly and Spies _FORTH:_a_Text_ and_Reference_ *does* explain things in more detail...but it wasn't published until 1986). 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. No wonder (according to a recent posting to this newsgroup, I believe) an unusually small percentage of Forth programmers are computer science degreed; only hardware hackers have the background to pick up this language easily. This needs to change. (3) Because of the problems mentioned above, a very large number of people have been 'burned' by Forth. They've put time AND MONEY into the language and come out with nothing. Incomplete implementations and lousy documentation have soured an enormous number of talented programmers. If the "public domain" implementations were the whole problem it would be one thing, but I don't think that is the case. When I discovered that the FIG 8080 model wasn't really robust I just wrote it off as "what can you expect for free". But when LMI Z80 Forth wasn't much better I was really irritated. I think my experience with a commercial Forth implementation is shared by many. And you wonder why people aren't anxious to spend more money to try Forth again? (4) Those who survive the Forth learning curve tend to be hardware hacker/ systems programming types. Everyone else has been chased away. Those who remain have commonly read FIG Forth Assembly Source Listings cover to cover. If push came to shove they could write their own Forth from scratch. And many of them have a secret dream of doing exactly that, whether they really need to or not. So...why should they spend more than a hundred dollars to get a merely 'good' Forth?? Tell you what: write a KILLER Forth for Xenix 386 which is competitive with a Borland Turbo C in terms of performance, documentation and "extras" and I would be willing to spend up to $250 for it. But I won't take that gamble for another shot at a "good" Forth. A number of people have written me to mention that Mitch Bradley's CForth runs under Xenix and costs only $50. I'd be delighted to spend $50 except that it's pretty evident from postings to this group and a mail response I got from Mitch that his CForth is a second class citizen under Unix. I'm not disparaging Mitch or his program--I'm sure he's many times over the programmer I will ever be. But the Unix Forth I would like to see must be able to compete with the standard 'C' compiler in terms of PERFORMANCE, support of Unix system calls, and the functionality of standard Unix C libraries. In particular, a Unix Forth must have complete curses support or how can I justify using Forth in place of C? Although Mitch says that curses support could be hooked into CForth it apparently isn't built in. And even if it were built in, even Mitch admits that a CForth program is significantly slower than a comparable C program. (Please folks, don't flame me for these comments--I'm trying to get you thinking and talking... I'm not trying to make an enemy of Mitch or anyone else.) (5) Those who survive the horrendous Forth learning curve and, ultimately, become such experts on Forth internals that they could write their own Forth discover something else: compared to other languages, Forth implementations are EASY to write! Think about it. Writing a high performance, commercially-competitive C or Ada compiler is a extremely intricate task which almost mandates years and years of formal computer science education and many man-years of coding. On the other hand, a Forth hot shot could write a REALLY high performance Forth within 6 months, programming all by himself. And he probably wouldn't have to know a thing about technologies such as compiler-compilers, LALR parsers, and optimizing compilers. So...why SHOULD a commercial Forth vendor expect to be paid as much for his system as another vendor might charge for a C or Ada or Modula-2 compiler? -- {pacbell!sactoh0! OR ucdavis!csusac!}tree!stever