Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!usc!ucsd!sdcc6!ir230 From: ir230@sdcc6.ucsd.edu (john wavrik) Newsgroups: comp.lang.forth Subject: Re: BASIS Feedback Message-ID: <11093@sdcc6.ucsd.edu> Date: 1 Jun 90 06:18:29 GMT References: <1032.UUL1.3#5129@willett.UUCP> Organization: University of California, San Diego Lines: 150 Dennis Raffer writes: $ Having just gone through the grueling process for my first time, I wish I $ could convey how much hard work the TC is doing. These choices are not $ easy, and some result in long, drawn out debates. Compromises MUST be made $ or we will never have a standard. There are basically two camps among all $ Forth programmers, those who want only the minimum words standardized, and $ those who want to include everything they could possibly need. What we will $ end up with is a compromise between the two, and hopefully all the factions $ within each group will be satisfied that they have at least been heard. There also seems to be a division between those who believe that the only reason for having a Standard is to insure portability and those who believe that some kind of magical respectability will flow merely from having an ANSI-"Standard" regardless of its content. If Forth retains is main asset, the ability of users to add major features to the language, the dispute between "minimalists" and "kitchen sinkists" disappears. I don't think anyone seriously objects to having features available as portable add-ons. A great deal of advantage would come from creating conditions which would allow "third party" tools to run on everyone's Forth. The dispute is whether the character of Forth should be changed. Whether it should, like other languages, become based on an implementation dependent black box requiring major features to be vendor supplied. Forth is a very unusual language. A great deal of its power derives from the user's access to the implementation -- and the implementation is very simple. As a result it is probably easier to diddle with Forth implementation than it is to actually do something useful with the language. There is really no harm in people developing and using their own dialect of a language -- the harm comes when they actively obstruct progress toward the development of a shared language for those who need it. It is true that compromises must be made if the portability and power that Forth once enjoyed are to be restored. However, some of the most insidious bugs in programs translated from one dialect of a language to another come from cases in which the same word has different meanings. Declaring the action of fundamental words to be "implementation dependent" is not the kind of compromise which will contribute to portability. $ > I wonder if there is any possibility that the ANSI Committee has $ > put users of the language in a position where they really can't $ > comment? $ How would you prefer that they do to sollicit your comments John? $ This is not the first time I and others have asked for comments and $ proposals, and no one has cut anyone off. However, I hope everyone $ realizes that this process must come to a close eventually. The TC $ has already been working on this for 3 years and there is a limit to $ how much each of the individuals can afford to dedicate to this $ process. We have already seen the withdrawl of a few very valuable $ individuals due to the expense and frustration of this effort. How $ much longer would you like to see people spend on it? The issue isn't how comments are solicited, it is with whether the users are in a position to be informed about what is going on. How many users are aware of what issues are to be discussed at the meetings? How many users are aware of what has been decided? I rather suspect that most users have interpreted the assurances that "We're not going to break anyone's code" and "We're following existing practice" to mean that the new Standard will look a lot like Forth-83. I'm sure that very few have had a chance to test a software implementation of any of the BASIS drafts to see how it differs from current versions of Forth. As for input from users, the TC is not equipped to deal with the kind of broad-based input that users are likely to provide -- and users are not in a position to provide the kind of narrow technical input the TC wants. As for output: To the best of my knowledge, there has never been a forum in which the goals and objectives of the ANSI effort have been aired. Much of the information available on the subject of goals comes as asides in postings to this newsgroup by members of the Team -- ranging from Mitch Bradley's indictments a month ago to the current posting of Dennis Raffer. We receive no reports about brilliant solutions -- just on unsatisfying compromises. Details on specific actions are presented with an air of "I know it isn't any good, but its the best we do given the political climate". All of these gloomy reports come from *supporters* of the ANSI effort who always add something about how hard the members work, how much time has been put in, and the hardship our boys have had to endure. I'm just waiting for someone to tell us he sees light at the end of the tunnel! [For non-US readers and those too young to remember -- rhetoric like this was used to convince people in the US that it would be unpatriotic of them to question the conduct of the Vietnam War -- even though all objective signs indicated that it was a total disaster] If the purpose of the exercise is just to have everyone's current system blessed then I wouldn't want to see any time spent on it at all. If the object is to restore power and portability to Forth then it should be worked on until it is done. Let me propose a simple test for doneness: Suppose the programmers at FORTH, Inc or any other software shop that uses programming teams, were equipped with different computers running randomly selected different ANSI-Standard implementations of Forth. Would it be possible to complete projects just as easily as now? Now let me give some reasons why this is a reasonable test: Many current and potential users of Forth work under just these conditions. In an academic setting, for example, many programming tasks exceed what any one person can accomplish -- and a joint effort by several individuals, perhaps at different schools using different computers, is needed. Even for single-programmer ventures, the need to have software running on several platforms has become common. Also in an academic setting, a language can be made unteachable. Here is how to do it: 1. Have no university level texts 2. Make it impossible for anyone to write a university level text (see 3&4) 3. Make the language unstable e.g. a. Change the language Standards every few years b. Split the language into multiple dialects 4. Make the language non-portable 5. Have no pool of (portable) basic application packages 6. Make it impossible for such a pool to be produced (see 3&4) 7. Fail to provide support to education If a language is made unteachable, it is not likely to be taught. If a language is not taught, it is not likely to spread. Friends in industry inform me that there too portability is important. Established software houses can get by using an in-house dialect of a language -- and there may be a few isolated opportunities for freelance programmers like Sam Smith, who does all his work in SmithForth. But for the majority of jobs, employers apparently would like to believe that code can be maintained by someone else when their chief programmer moves on to greener pastures -- and that it will not have to be entirely rewritten to run on another machine. The test proposed above, therefore, corresponds to what the bulk of the user community needs from a language standard. I believe that the ANSI effort is a one-shot deal. If we do not restore portability to Forth on this attempt, we will not have a second chance. John J Wavrik jjwavrik@ucsd.edu Dept of Math C-012 Univ of Calif - San Diego La Jolla, CA 92093