Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!agate!ucbvax!MITCH.ENG.SUN.COM!wmb From: wmb@MITCH.ENG.SUN.COM (Mitch Bradley) Newsgroups: comp.lang.forth Subject: Re: Broken cmForth Message-ID: <9102222023.AA15724@ucbvax.Berkeley.EDU> Date: 22 Feb 91 19:21:35 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Mitch Bradley Organization: The Internet Lines: 110 > I get the impression that the bug is really that CM changed the definition > of THRU instead of picking another word. You could look at it that way. However, one might ask why he changed the definition. The "new" definition of THRU is in no way an improvement; it does the same thing as the old THRU, except that it takes away functionality that used to exist. Furthermore, I expect that this was done consciously. The functionality was given up simply because it was slightly inconvenient to implement using FOR .. NEXT . In any case, it still supports my orginal point; FOR .. NEXT is not an unmitigated win in all circumstances. Here is a real live example of a particular weakness of FOR .. NEXT compared to DO .. LOOP , and a good Forth programmer broke a well-understood function as a result. There's nothing inherently wrong with FOR .. NEXT per se, but I can't accept the claim that the existence of FOR .. NEXT renders DO .. LOOP useless. > As Forth implementions qua personal-systems, I see no problem with taking > short-cuts. Nor do I, but I wish people would stop posting and distributing their half-baked experiments. And I don't object to half-baked experiments; I do them all the time. I just don't pass them around labeled as "Forth implementations". > As for products, I don't understand why market forces > haven't straigtened the situation around. Market forces work best when the market is large. The Forth market isn't. To some extent, the market forces do work; crummy Forth implementations die relatively quickly, and the competent ones survive. This is independent of whether they are commercial systems or not. Crummy commercial systems die too. The problem is that crummy systems just keep on coming, and many people have been and are turned off of Forth because of bad experiences with crummy Forth systems. > The "problem" is that shareware/PD systems abound and somehow it is > those systems that scare people off? I do NOT equate "bad" with PD. There are several completely competent PD systems out there, F-PC and F-83 to name just two. The problem that I am talking about is when somebody posts the Forth that they wrote in 2 weeks for their "CS 202" project and it gets stuck up on better bulletin boards everywhere. > My question is why are there so few PD/Shareware C > systems (semi-rhetorical question) and why has the Forth PD/Shareware > market had such a great eclipsing influence over the "professional > product" market? It's partially because Forth is not an accepted "respectable" language, thus many Forth enthusiasts have to buy Forth out of their own pockets, rather than getting their company to pay for it. I have lots of customers who have purchased my system for use at work, paying for it themselves and hoping someday to impress their bosses to reimburse them. In fact, I did the same thing myself when I was starting out with Forth. Most people are careful how they spend their own money, and will make do with something that is free rather than commit the bucks. > The commercial Forth vendors must distinguish themselves from the > PD/Shareware people. I find it hard to believe "support" can be taken > seriously as a distinguishing factor when the whole philosophy of > Forth is build your own language to support your application. How can > commercial vendors expect me to believe they'll support "my" code? > (not a rhetorical question). Product support takes many forms; it can mean fixing bugs in a timely fashion, or providing suggestions about good ways to attack a particular problem, or telling people about system features that may help in their problem (that they may not have discovered in their reading/exploring), or helping people find bugs in their code or setup (for instance, I spent a lot of time on the phone with one customer, only to discover that he was using a PC-XT as a dumb terminal, and the comm program he was using dropped characters at 9600 baud). Speaking only for myself, I spend a great deal of effort doing product support, and I can name you a lot of customers who appreciate it a great deal. The great majority of my customers have considerably less Forth experience than I have, and they value the ability to "pick my brain" to the extent of paying me for it. That is what support means to me. > I'm curious to know what the commercial > vendors see as their added value. The above diatribe is part of my added value. Another is printed, bound documentation (which lots of people want; no kidding). Another is purely administrative; you send me money, I send you a disk. A lot of people don't want to fool around with searching for and downloading a PD system, or figuring out how to get the bits onto the target machine. > In anticipation of one obvious answer: "Libraries," I ask > further how that will be affected by the ANSI effort (where the > library will be less unique because it must conform). That too, but I provide a lot of libraries that are not covered by ANS Forth, for example system-dependent OS calls, window interfaces, dynamic loading, etc. Mitch