Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!cs.utexas.edu!tut.cis.ohio-state.edu!ucsd!ames!pacbell!sactoh0!tree!stever From: stever@tree.uucp (Steve Rudek) Newsgroups: comp.lang.forth Subject: Re: Thoughts on Forth Summary: A modest proposal for portable libraries Message-ID: <1990Jan14.203752.22131@tree.uucp> Date: 14 Jan 90 20:37:52 GMT References: <6025@sdcc6.ucsd.edu> Organization: TREE BBS (916)349-0385 Sacramento, Ca Lines: 134 In article <6025@sdcc6.ucsd.edu>, ir230@sdcc6.ucsd.edu (john wavrik) writes: > would be a matter of "making do". Forth, to me, is a language for building > languages. I don't think that any other language you care to mention has this > property. Mathematics will never run out of data structures that no one knows ... > Forth offers unique (and permanent) capabilities that are not within the > nature of other languages to offer. LISP is at least as good for language building (probably better). Of course, all the implementations I've heard of are too slow or run only on expensive hardware. Assuming that LISP's speed problem is inescapably endemic to the language, then Forth has the opportunity to monopolize the market as a language for writing languages which are actually USABLE. That gives Forth at least two market niches -- embedded systems and custom languages. Can anyone think of a third? > Forth is not a little kid refusing to grow up, it is brilliant idea > waiting for people to understand and use it properly. ... > It should not be surprising that such a language encourages a variety of > perversions. Without any conventions for the writing of clear code, there > is no doubt that many examples of "write only" code will be produced > [adding fuel to the fire of critics who claim that writing clear code in > such a language is impossible]. A very flexible language also encourages > a form of masturbation -- people become preoccupied with modifying the > language rather than doing anything with it [adding fuel to the fire of > critics who claim that nothing can be done with it]. If I understand correctly, John is saying that Forth is fine -- Forth PROGRAMMERS, on the other hand, need to grow up. I agree with that. There has always been a tendency for the Forth community to blame Forth's lack of popular acceptance on ignorance, "bigotry", and lack of imagination in the mainstream programming community. The mainstream computing community has blamed the Forth language directly. Neither group was correct: the blame lies with Forth programmers, themselves. In almost twenty years, armed with a language which SHOULD have made them enormously more productive than their programming brethren stuck with "third generation languages", Forth programmers have written almost nothing of any consequence -- just lots of new Forth systems and lots of "small, cute hacks which amuse other Forth programmers". (to quote Peter Silva) > 1. The whole issue of how to use and not abuse the freedom that the > language provides must be addressed. > > 2. Can such a language be standardized so that it retains its flexibility > for each user yet achieves a high degree of portability? > > 3. What is necessary to allow a community to jointly add powerful > features to such a language as portable extensions? > > 4. What is the best approach for setting standards for such a language? > > 5. The language must become portable enough, well understood enough, > established enough so that it can be taught. How can these goals be > best achieved. > > These are just of the few of the issues that need to be addressed. Since > Forth is not just a reworking of a conventional language, some of these > issues may need to be dealt with in a novel way. IT MAY BE THAT FORTH IS > HAVING A PROBLEM WITH STANDARDS RIGHT NOW BECAUSE THE APPROACH USED TO > SET STANDARDS FOR CONVENTIONAL LANGUAGES IS INAPPROPRIATE TO FORTH. (emphasis aded) > > A brilliant idea doesn't automatically thrive -- it all depends upon the > people to whom it has been entrusted for development. John Wavrik's postings are always well composed and thought provoking; this time he outdid himself. In recent months a number of people have voiced a desire for "standards" to ease portability of Forth code. It has been very frustrating to watch even the idea of a unix "standard" rapidly degenerate into nonchalance by some people and arm wrestling contests by others. I have a hunch that the first step in meaningful progress is to discard the word "standard". The word clearly means wildly different things to different people and invokes very stong emotion. As I see it, we can either abandon the word "standard" or force half the Forth programmers into therapy; abandoning the word is easiest. I propose that the Forth community develop "portable libraries" which can be easily retrieved from Fig, Forth BBSes and network archive servers. A portable library for strings, for example, would consist of a base word set prefaced by whatever base primatives are required to adequately define the base word set for your Forth. In other words, the same base word set would be available from a Fig Forth, Forth 79, or Forth 83 by using different definitions for the base primatives. Performance of the base word set is not the primary issue -- portability is. If I write a program which uses portable libraries I will have assurance that you can run that program on another machine; whether it runs "fast enough" on your machine is a different matter but one, I submit, which is not nearly so important as the fact that it does run. If YOU don't think the speed is sufficient, YOU may rewrite the base primatives into suitable assembly language for your machine -- THAT IS *YOUR* CHOICE. You even choose to abandon the base word set to get maximum speed on your machine at the expense of portability -- but isn't it helpful that you at least got to see the program running on your machine before you had to undertake "porting" it? The portable library would ADD a choice -- NOT take anything away. Because Forth programmers are so iconoclastic there would doubtless be disagreements about what constitutes the optimal portable library for strings (for example). That's okay. Write your own portable library and distribute it -- just make sure you clearly identify the necessity of using your library AND that you define the base word set adequately in terms of primatives for all major Forth dialects. It can be survival of the fittest. For portable libraries to help they must 1) exist and 2) be easily retrievable (if you receive source for a game or word processor written in Forth which references a portable library, you must be able to get that portable library quickly and relatively inexpensively. FIG could help by distributing libraries on disk at nominal cost. BBSes and archive servers would be even faster. Certainly such a distribution mechanism for libraries is "doable" -- it would be in keeping with the "different" nature of the Forth community that we use "portable libraries" rather than authoritarian and repressive standards and that we maximize networking to enable portability. Doesn't this approach make more sense than the status quo? The status quo doesn't work and is strangling Forth. If something doesn't work one should try something else. Surely we are all rational enough to agree on that, at least? ----- P.S. I'm leaving for Australia on Wednesday, Jan 17 and won't be back until March 10. I don't want anyone thinking I died of frustration. Those with PCs *should* look at the shareware "Fifth" implementation to stretch their brains regarding a third possibility in the "screens vs. sequential files" debate. It's only $10 and can be ordered from "The Software Construction Company" by calling (409) 696-5432. ----- -- {pacbell!sactoh0! OR ucdavis!csusac!}tree!stever