JAJZ801@CALSTATE.BITNET ("Jeff Sicherman,CSU Long Beach") (08/27/90)
It would seem, from the recent postings about the distribution policy for BASIS13 that the committee is trying to inhibit, not prevent, the wide dispersal of the proposed standard. It would probably be 'illegal' to prevent it, given their mandate, but making it slower, harder, and at some expense to get when an efficient medium is available is sort of a logistic stonewalling. Restricting it to MS Word format makes it minimally portable. Convertible standard formats, especially Postscript (tm) which I suggested before are available and presumably verifiable. I'm a relatively new Forth programmer so I don't have much investment either intellectual or financial in any particular set of choices or the effects of the standard, but I'm not encouraged much for the future of Forth by the standards process and progress, at least as I've viewed it through the discussions on the net and the relative silence of the committee itself (see above). This is based largely on supposition, but I can't escape the by the opinion that the committee's intent, by and large, was to protect their own interests and perspectives. The expense and time involved in the process itself restricts and discourages wide participation so that it will involve largely those with both heavy resources and investments (plus some fanatics). There's nothing inherently wrong with that: these people have the right and responsibility to protect those interests. But given the diversity of opinion in the Forth community (if the net is any indicator), there's a strong risk of narrowness of view. I'm not suggesting that things should have been put to popular vote on the net or any other medium, put I would have been encouraged to see solicitation from the committee for discussion fo various topics before and/or while they were the subject of strong debate within the process instead of dispersing decisions. There's an air of arrogance about that, a sort of attitude that 'We are the Forth community'. Given the issues raised over the result, I have to assume that the standard will be the object of much protest and discussion after it is published for comment by ANSI. If the issues are not resolvable, I fear it will never really be accepted (implemented) even though it may be adopted. And I don't know how they can be resolved given the failures and weaknesses of the process that has lead to it. I don't doubt that the standardization of other languages were exercises in politics also, but it seems from this distance to have dominated the Forth one. I feel this may be inherent to the nature of the language. It is too close to the hardware in practice, structure, and use for a sufficient level of abstraction to have been adopted early on and it appears to be much too late now to define a significant, robust virtual machine that will be adhered to. Too many Forth experts with too much provinciality and influence exist for the process to succeed. It's too much a hacker's (in a non-pejorative sense) language with a paucity of academic rigor (and consequently interest, you will note) in it's definition and implementation. This is not meant to belittle the quality of the products or their power - they seem quite good - it just means that everybody is likely to go their own way. It may be a misguided effort to try to standardize Forth in the first place; it's akin to trying to invoke get a single machine architecture, given the low level Forth operates at. That hasn't happened for much the same reasons: a multiplicty of ideas, interests, and investment in established implementations. Forth is more like a common machine model (e.g. the Von Nuemann) that everyone has built variations of. Maybe this is as it should be, not to cheapen the attempt too much, I just think it may (have been) doomed. I'm also not convinced the portability is all that necessary, given the nature of Forth applications and the likely potential for popularity. Based upon what I've seen and heard, I can't see large projects built with it. That doesn't mean there haven't been important and significant ones built - I mean REALLY big stuff that represents the big bucks and contracts in the industry. It's just too idiosyncratic to manage (literally) and too strange a language. I just can't see a big pool of programmers out there that will become proficient and comfortable with it. Let's face it: it's unnatural from an English language point-of-view and that's what's been burned into our neural nets in this country. (Does anybody know if the Japanese adapt to it any better ?). I know it's a trite joke, but it IS rather write-only and that's the principle inhibition to both learning the language and to code sharing and reading that are inherent to large projects these days. As a consequence, I think it is destined to be a niche language project- and programmer-wise. Maybe that's as it should be. Sorry, I don't think Forth would be much more popular no matter how standard and portable. Jeff Sicherman jajz801@calstate.bitnet
wmb@MITCH.ENG.SUN.COM (08/28/90)
> It would seem, from the recent postings about the distribution policy > for BASIS13 that the committee is trying to inhibit, not prevent, the > wide dispersal of the proposed standard. I haven't sensed any such undercurrent. I suspect that it is more an issue of trying to keep things from getting out of control. In the short time interval that a particular Basis is valid, attempts to convert it to a multiplicity of formats have a high probability of causing confusion. It's a tradeoff. On the one hand, decentralized distribution appeals to one's sense of democracy and fairness. On the other hand, it is likely to result in so many different versions that it's hard to know what you have. A similar situation exists with GNU EMACS. There are so many versions of it floating around at Sun that it's hard to help people solve their problems. What I'm saying is, the policy to control the distribution format does not necessarily imply a desire to inhibit wide dispersal. Another example: I am the author of a shareware Forth product for the Atari ST (Forthmacs). I allow people to copy it, post it on bulletin boards, etc, subject to the constraint that they may not distribute incomplete or modified copies without my express permission. That is not an attempt to limit distribution; on the contrary, my interests are served by maximizing distribution. It is an attempt to keep the package stable enough that I can help people when they write to me with questions. Mitch
a684@mindlink.UUCP (Nick Janow) (08/28/90)
JAJZ801@CALSTATE.BITNET (Jeff Sicherman,CSU Long Beach) writes: > It would seem, from the recent postings about the distribution policy for > BASIS13 that the committee is trying to inhibit, not prevent, the wide > dispersal of the proposed standard. Not at all. I attended the last conference (Vancouver) and I was present when the issue of electronic distribution format came up. The committee wants anyone interested in FORTH to have access to the documents, so that constructive proposals and comments can be made. The reason for limiting distribution to the official format--which happens to be MSWORD--is to prevent the misinterpretation of the contents of the document. I don't know where the problems would arise, but there is information contained in the format (bold type, editor's comments, etc) that could cause confusion if lost. It's not a plot to keep interested FORTH parties from having access to the document. If there was a truly standard format that would convey the information properly _and_ if someone who knew how to use it volunteered to be the editor, the committee would have chosen that format. MSWORD just happened to be what the volunteers used. Are you offering them money to hire editing services in some other format? :) The cheapest and most convenient method of getting the document is by mail. It doesn't solve the problem of electronically searching the document, but I find the document fairly readable anyways; I find it easy enough to find what I'm looking for. I think it would be a lot more forbidding as computer text.
a684@mindlink.UUCP (Nick Janow) (08/28/90)
JAJZ801@CALSTATE.BITNET (Jeff Sicherman,CSU Long Beach) writes: > ...This is based largely on supposition, but I can't escape the by the > opinion that the committee's intent, by and large, was to protect their own > interests and perspectives. I was there (as an observer) and I didn't get that feeling at all. It's not a group of employees paid bigbucks to get a particular implementation accepted. It's a bunch of people who have donated a lot of time and energy because they are interested in seeing FORTH become more midely accepted in the programming community. Some of them do promote the implementation choices of that they use or that their company uses. However, all they can do is present an argument, and if someone presents a better counter-argument which will lead to a standard that will be more acceptable, they change their votes. > The expense and time involved in the process itself restricts and discourages > wide participation so that it will involve largely those with both heavy > resources and investments (plus some fanatics) You don't have to go to the meetings to affect the standard. A well written proposal which presents a convincing argument is all that you need. The committee votes (fanatics aside (-: ) according to convincing arguments. Controversial proposals get discussed at great length <understatement> and eventually a concensus is reached (a majority of the members have been swayed by convincing arguments) or else the proposal gets tabled or postponed until some new arguments come up. > I would have been encouraged to see solicitation from the committee for > discussion fo various topics before and/or while they were the subject of > strong debate within the process instead of dispersing decisions. The committe _does_ encourage input during discussions. Proposals are divided into categories such as "Floating Point" or "Multi-programming Word Set" and are then discussed. Any and all comments or proposals you submit will be discussed and considered. Before I get hate mail from the committee members who have to deal with all those proposals, I think they'd be grateful if you don't send in stacks of proposals that don't provide a good supporting argument, especially on well-discussed issues. The committee deals with _every_ proposal, and simple "make a separate FP stack" type proposals simply waste the committee's limited time. Perhaps one of the committee members who has been to several meetings would like to post some pointers on good proposal writing techniques. A list of "heavily discussed and more or less settled" issues might also be helpful at this stage.
a684@mindlink.UUCP (Nick Janow) (08/28/90)
JAJZ801@CALSTATE.BITNET (Jeff Sicherman,CSU Long Beach) writes: > Given the issues raised over the result, I have to assume that the standard > will be the object of much protest and discussion after it is published for > comment by ANSI. Of course. Any compromise virtualy guarantees that someone will be unhappy. However, the other side of that is that most parties will at least grudgingly accept the compromise position. > If the issues are not resolvable, I fear it will never really be accepted > (implemented) even though it may be adopted. The feeling I got from the members of the committee is that they were going to implement/use ANS FORTH when it is finished. I just write programs for myself, but I'm going to follow the ANS standard as much as possible. I don't think the changeover will be all that difficult. > And I don't know how they can be resolved given the failures and weaknesses > of the process that has lead to it. I don't doubt that the standardization of > other languages were exercises in politics also, but it seems from this > distance to have dominated the Forth one. The failures and weaknesses come from the fractured practices of the FORTH community; the ANS committee is trying to bring the community back together. Politics does play a part of the process; compromises were required to keep the support of some major parts of the FORTH community. The ANS standard is meant to improve the FORTH community's viablility as a whole by having a large community working together. Splitting it up over the meaning of / would not help the language.
a684@mindlink.UUCP (Nick Janow) (08/28/90)
JAJZ801@CALSTATE.BITNET (Jeff Sicherman,CSU Long Beach) writes: > I know it's a trite joke, but it [FORTH] IS rather write-only and that's the > principle inhibition to both learning the language and to code sharing and > reading that are inherent to large projects these days. As a consequence, I > think it is destined to be a niche language project- and programmer-wise. > Maybe that's as it should be. Sorry, I don't think Forth would be much more > popular no matter how standard and portable. Sheesh, what a terribly pessimistic viewpoint. :-( FORTH _can_ be written in a manner that is very readable. It's not even that hard to do once you get used to it. I started off writing very few comments, but now I find myself commenting more and appreciating the comments more. John Rible (if I have my Johns straight) proposed a concise method of stack commenting which handles all stacks (data, FP, control flow, etc); it is even machine readable. Something like that could help on large projects and/or code revision. I like FORTH and am optimistic about its prospects, even for large applications. I think the ANS standard will help.
a684@mindlink.UUCP (Nick Janow) (08/28/90)
I'm just a FORTH hobbyist, and the only implementation I've used is MacFORTH Plus (Creative Solutions). I attended the latest ANS conference out of interest in the process of forming a standard and the reasons why certain choices were made. (Living 1/2 hour away from the meeting room helped too. (-: ) The meetings were long, but I'm glad I had the opportunity to attend. Now when I view the standard, I'll understand what went into it. Any visions of a conspiracy by a few major FORTH vendors have been laid to rest. "THE ANS COMMITTEE" is no longer a faceless entity for me; they're just people interested in FORTH, each bringing their own preferences, opinions and knowledge. They can also be swayed by good arguments. I'm satisfied with the workings of the committee. They have my support. :-)
wmb@MITCH.ENG.SUN.COM (08/28/90)
> As regards GNU EMACS, If one person/department at SUN made it known that > he would keep the most recent version of GNU EMACS available (by FTP, at > least, or by keeping a disk copy that could be borrowed, copied, and > returned), then there would be no reason for multiple versions of EMACS > to proliferate. There is such a person and such a "most recent version, readily available", but the company is so big and is growing so fast that people routinely FTP GNU EMACS from God-knows-where without bothering to ask where the the "official version" is. Also, lots of people just like to hack on it. I'm not saying that electronic distribution doesn't have its advantages, I'm just saying that it inevitably leads to multiple versions and some amount of confusion. All in all, I am in favor of electronic distribution, with a reasonable attempt to keep some amount of control. I would like to see an ASCII version myself. However, the people who are doing the actual work of editing and distributing it have chosen not to distribute it that way. Since I haven't volunteered to do the work, I don't feel empowered to dictate to them how to do it. Mitch
dwp@willett.pgh.pa.us (Doug Philips) (08/29/90)
In <9008271927.AA29643@ucbvax.Berkeley.EDU>, JAJZ801@CALSTATE.BITNET ("Jeff Sicherman,CSU Long Beach") writes: > > It would seem, from the recent postings about the distribution policy > for BASIS13 that the committee is trying to inhibit, not prevent, the > wide dispersal of the proposed standard. It would probably be 'illegal' > to prevent it, given their mandate, but making it slower, harder, and > at some expense to get when an efficient medium is available is sort > of a logistic stonewalling. Restricting it to MS Word format makes it > minimally portable. Convertible standard formats, especially Postscript (tm) > which I suggested before are available and presumably verifiable. Just to say it ONE MORE TIME: X3J14 is the FIRST TC to have ANY KIND of online document available. You can flame, but flame ANS for failing to do this before. Maybe we can get a semi-official reply from the TC about the why's and what's and wherefore's of getting this to come about. When the C standard (X3J11) was winding down there was some net traffic about on-line access. As I recall there were moral and legal sides to the question. I no longer recall the justifications for restricting, except that selling hardcopy is how ANS makes its money. The TC should be applauded for forcing this issue. BUT, be forewarned, there is NO guarantee that when the BASIS becomes a dpANS that ANS will let the TC distribute it (the dpANS) electronicly. > become proficient and comfortable with it. Let's face it: it's unnatural > from an English language point-of-view and that's what's been burned into > our neural nets in this country. Oh, and so is assembler and C and ADA and SmallTalk (can you really THINK in an OO manner when programming?), and LISP and ... -Doug --- Preferred: ( dwp@willett.pgh.pa.us OR ...!{sei,pitt}!willett!dwp ) Daily: ...!{uunet,nfsun}!willett!dwp [last resort: dwp@vega.fac.cs.cmu.edu]
wmb@MITCH.ENG.SUN.COM (Mitch Bradley) (08/30/90)
> That's great, I compliment you. But what's the point? Are you violating > ANS policy at great risk to yourselves, your reputations, or to the backing > of ANS for the standard, or WHAT ? Having decided to do it and done it at > all, then it shouldn't have been casual or an afterthought. In for a dime, > in for a dollar: if you're going to test some rule, do it for a good reason, > De Facto as well as De Jure. I wasn't expectin' the Spanish Inquisition! :-) But seriously, folks, could we lighten up a little here? Us TC folks are trying to muddle through this whole process, and we are only human, okay? We could probably do better, but we have other jobs too. The committee screwed up by not implementing electronic distribution sooner and better. I would like to propose an end to this discussion thread, on the grounds that the TC has heard it and is trying to fix it (i.e. trying to implement electronic distribution), subject to some constraints. Recent arguments have generated much heat and little light. You may show your approval of my proposal by NOT replying, neither to me nor to the net. You may vote "no" by sending U.S. Mail to the TC, in the form of a technical proposal detailing specifically the set of distribution formats that should be used. An offer to help implement your proposal will give it greater weight. Mitch
jax@well.sf.ca.us (Jack J. Woehr) (08/30/90)
JAJZ801@CALSTATE.BITNET ("Jeff Sicherman,CSU Long Beach") writes: >but I can't escape the by the opinion that the committee's intent, by >and large, was to protect their own interests and perspectives. Jeff ... I can tell by your many postings that you really care about Forth ... thank you for your interest. It is easy to get concerned when the Standard Committee seems so far away and unreachable. Let me tell you what is really happening there. About 20 regulars are, at mostly their own (considerable and unrenumerated) expense attending these meetings again and again, as they drag on, out of devotion to the Forth programming model and their own ideas of it. We are all getting kicked in the ass financially. We did not distribute in WORD [TM] format for fun. It's because that is what the BASIS is in, done lovingly and occasionally clumsily by a semi-retired engineer who falls asleep a lot at the meetings. We don't have the time or money to port it to ten other formats. Sorry. Keep online for ANS Forth, Jeff! It's coming, glacially slow, but we're trying ... come to our next meeting, if you wish, everyone is invited. It really is a free-for-all ... if we were in this for the money, we'd do it in C! :-) <jax@well.{UUCP,sf.ca.us} >< Member, > /// ///\\\ \\\ /// <well!jax@lll-winken.arpa >< X3J14 TC > /// /// \\\ \\\/// <JAX on GEnie >< for ANS > \\\ /// ///====\\\ ///\\\ <SYSOP RCFB (303) 278-0364>< Forth > \\\/// /// \\\ /// \\\