dwp@willett.pgh.pa.us (Doug Philips) (02/20/91)
In article <9102211446.AA20543@ucbvax.Berkeley.EDU>, wmb@MITCH.ENG.SUN.COM (Mitch Bradley) writes: > A bug that doesn't happen to show up in a particular application is > still a bug. > > A bug that is easy to fix is still a bug. I get the impression that the bug is really that CM changed the definition of THRU instead of picking another word. > One of the reasons that Forth has a bad reputation is because there > are so many half-hearted Forth implementations floating around. > Too many Forth implementors have a tendency to take shortcuts that > compromise the quality of their implementations. The "I don't need > that feature this week, so the heck with it" attitude has probably > damaged Forth's reputation more than anything else. Hmm. I find this a peculiar point of view. I have heard it said that one doesn't really know Forth until one has implemented it. As Forth implementions qua personal-systems, I see no problem with taking short-cuts. As for products, I don't understand why market forces haven't straigtened the situation around. The "problem" is that shareware/PD systems abound and somehow it is those systems that scare people off? 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? Personaly, I feel the answer is that the proliferation of PD/SW systems tells people that they are dealing with a "little language," one so easy to implement that any bozo can do it, and therefore they would get little out of it ("To carry out the treasure of the Indies you must carry in the treasure of the Indies" attitude). 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) I'm curious to know what the commercial vendors see as their added value. 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). -Doug --- Preferred: dwp@willett.pgh.pa.us Ok: {pitt,sei,uunet}!willett!dwp
wmb@MITCH.ENG.SUN.COM (Mitch Bradley) (02/21/91)
> > I find it amusing that Chuck introduced a bug in cmForth because of > > his zeal for eliminating DO .. LOOP > There was no need in cmFORTH to compile colon or CODE definitions across > screen boundaries, thus its THRU worked just fine. And, as Jan Stout pointed > out, it is easily modified to allow compiling colon or CODE words across > screen boundaries, if one's factoring is so poor (as mine is on occasion) > that he needs that facility. A bug that doesn't happen to show up in a particular application is still a bug. A bug that is easy to fix is still a bug. One of the reasons that Forth has a bad reputation is because there are so many half-hearted Forth implementations floating around. Too many Forth implementors have a tendency to take shortcuts that compromise the quality of their implementations. The "I don't need that feature this week, so the heck with it" attitude has probably damaged Forth's reputation more than anything else. Mitch
wmb@MITCH.ENG.SUN.COM (Mitch Bradley) (02/23/91)
> 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
dwp@willett.pgh.pa.us (Doug Philips) (02/24/91)
In article <9102222023.AA15724@ucbvax.Berkeley.EDU>, wmb@MITCH.ENG.SUN.COM (Mitch Bradley) writes: +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. I might be inclined to reply to this by saying that CM is not your average Forth programmer. No reason to assume he can't make mistakes or blunders, nor that he won't change his mind. I would be interested in hereing further justification. Was the THRU bug no big deal? Was it better factored (as I think it was Frank suggested) this way? Personally I believe that the bug is that THRU needed more than just a replace-string done on it. That FOR NEXT is slightly inferior in this case doesn't sound the death nell for me as it seems for you. Perhaps one of the straws on the camels back, but not that interesting in and of itself. +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 I said in an earlier post, they are nearly isomorphic. I think this is an interesting illustration of the deceptive simplicity of Forth. Simplicity doesn't "just exist," but is always relative to something. Whether DO LOOP or FOR NEXT is "simpler" or "more elegant" or .... depends on what you are trying to do. +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. +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. "Most bad systems are PD, Therefore most PD systems are bad." I meant the former, not the latter. Sorry for any confusion. It is interesting to note that the same thing doesn't happen with C compilers/run-time systems. One of Forth's strengths seems to cast a bad light here. +Most people are careful how they spend their own money, and will make +do with something that is free rather than commit the bucks. That explains why people might choose a "free" PD/Shareware system, but not why there are so many to choose from. +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. Printed documentation is a BIG plus. Not just stuff you can run off on a half decent dot matrix printer, but nice bound, laser output with pictures, etc. Not having to maintain the core system itself, i.e. unsolicited updates and bug fixes, are also BIG pluses. Thanks for the detailed reply. I don't have any dispute with what you said. I guess one thing you didn't say is that the quality of the implementation is much more crucial for commercial success than PD/Shareware "success." -Doug --- Preferred: dwp@willett.pgh.pa.us Ok: {pitt,sei,uunet}!willett!dwp
wmb@MITCH.ENG.SUN.COM (Mitch Bradley) (02/27/91)
> That FOR NEXT is slightly inferior in this > case doesn't sound the death nell for me as it seems for you. Perhaps > one of the straws on the camels back, but not that interesting in and > of itself. I was not trying to make the point that FOR .. NEXT is bad; rather I was noting that, contrary to some earlier messages that were going around, DO .. LOOP does have some nice uses. Mitch