JAJZ801@CALSTATE.BITNET ("Jeff Sicherman,CSU Long Beach") (08/29/90)
OFF BASIS II, the squeekuel
NOTE: To save most of the net the extra added effort of trashing my replies
individually, I have consolidated my answers into a single followup
diatribe. Names have been omitted to protect the weak arguments.
> The meetings were long, but I'm glad I had the opportunity to attend. Now
> 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. :-)
I never have or will accuse them of a conspiracy. The agreement and
cooperation that would require are unprecedented and probably unobtainable
in the FORTH community. The problem is with the preferences being motivated
by self-interest and opinions controlled by self-practice. I'm sure they
can be swayed by good arguments - they are undoubtedly intelligent and have
good intentions - they can be motivated to compromise to maintain self-
interest and existing practice, not improve the language, its environment
and consistency.
>
> Sheesh, what a terribly pessimistic viewpoint. :-(
>
Often also known as realistic.
> 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.
>
Thanks you for reinforcing my arguments. If it WAS a decently readable
LANGUAGE you wouldn't have to stick COMMENTS everywhere in sight. Most
languges require some commenting, but as exceptions not as the RULE for
most every statement. Sheesh indeed.
> I like FORTH and am optimistic about its prospects, even for large
> applications. I think the ANS standard will help.
Want to invest some money on that premise ? Or would you prefer to be
'realistic'
>
> 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? :)
>
This is apparently a strange use of the word 'wants' that I'm not familiar
with. If you really want something you find ways to achieve it and put effort
into overcoming the obstacles; NOT let the preferences of some inhibit or
prevent it. The format doesn't 'happen' to be MSWORD. It is because there
wasn't due consideration for the maximization of distribution, and it was left
to the choice of whomever could be convinced to do the work. I guess maybe
they couldn't get someone unless they gaveup control of the matter ?? In any
case, portability of the document obviously wasn't a priority along with the
consequences of that choice.
>
> The cheapest and most convenient method of getting the document is by mail. I
> 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.
>
See previous comments above. Anyone who can (claim to) read FORTH should
obviously be able to handle an ASCII file, with some study and intelligence.
>
> 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.
>
Whatever that means. Does that mean that vendors will remove non-ANSI
compliant features from their products. Will they produce both ANSI and
non-ANSI ones (to support old applications and stubborn customers) and
which ones will sell and last ? I don't think happiness is the question,
implementaion is.
>
> 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.
>
(Caution, the following comments may be offensive to persons of some
political persuasions, reader discretion is advised). We just got done with
a decade of depending upon feelings, promises, goodwill and all that crap.
See where it got us. I'm not sure I understand what 'finished' means. As I
understand it, the committee is 'finishing' a *proposed* standard. Let's see,
it took about five years to get that, another five to iron out all the
objections and clear all the bureaucratic obstructions to adoption, another
one or two to get everyone compliant. I feel confident in guaranteeing we
will have a functional ANS standard before the end of the millenium. Whether
anyone will give a damn by then is another question.
>
> 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 th
> 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.
The failures and weaknesses come from the fact that FORTH is only marginally
qualified to be called a language, at least in the sense of most high-level
computer languages. It's and abstract machine with everyone self-qualified to
design the architecture. Show me an assembly/machine language standard and
I'll have high hopes for a FORTH one. The best thing that could have been
done for FORTH as a LANGUAGE would have been to decide to fix everything that
needed fixing regardless of whose toes were stepped upon. That doesn't exclude
compromises on some matters but it would have meant getting rid of the kludges
that have hung on for archaic reasons. Sometimes it's right to gore everyone's
ox in the interest of starting the herd over.
>
> 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.
... and from another party ...
> 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.
Show me the formal, announced, supported procedure for doing this. Until
then it's merely a nice idea which may be honored. It may even be done
occassionaly.
>
> 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 a
> this stage.
God forbid. I wouldn't want to waste the limited four years it's had to
work with. I think many of these people are good candidates for public office.
>
> Forth is not write-only at all. It is true that relatively few programmers
> know how to read it, but that is an entirely different thing.
> Any language is unreadable if you don't know the vocabulary. For millions
> of Americans, Chinese is totally unreadable, but that doesn't stop billions
> of Chinese from reading it. The problem with Forth is that the vocabulary
> is rather extensive, and completely new for most programmers.
That's why the world is full of RPN calculators and infix ones have fallen
into disrepute and disuse. On the other hand, we could send out prophets to
all the schools and indoctrinate the educational establishment so a generation
from now we will have a crop of programmers weaned on this stuff. Let's face
reality: it's an elite language which will be comfortable for a limited part
of the pool of potential programmers.
>
> I routinely read other people's Forth code, with no problems, and other
> people read my code.
That's great, wonderful. And Of course you're Mr Typical Programmer.
Give me names and numbers. We're talking about potential for popularity
here.
>
> In a large project, it is important to enforce coding style standards so
> that visual clues help rather than hinder. It is also important to use
> lots of stack comments. Finally, software engineering tools like those
> present in Unix help a lot.
>
> Given a disciplined team of Forth programmers, Forth can be successfully
> used for large projects. We have 7 programmers working on the Sun firmware,
> which consists of about 300 files. So far, it is working out quite well.
>
So ? The issue is whether FORTH has the potential to be more than a niche
language. As long as we're talking about engineering here, what's the level
of productivity for FORTH as compared to high-level languages. My guess is
its better than assembly and quite lower than HLL's, especially if you
include debugging time. I also imagine Case and quality control are more
difficult and time consuming for it. The situation si probably improved
somewhat by the fact that Forth programmers are probably better programmers
on average than the hordes working in C these days, if only by self selection.
Seven programmers is NOT a big team by any contemporary standard. You cant
even get the paperwork started with that many. Call me when really big banks
and defense contractors start doing their major projects in FORTH.
Hey, I *really* like Forth, it think it's neat and all that. But give
me a break from wishful thinking and spare me true believers all set to
join the crusade.
Jeff Sicherman