From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,f03f7958fe713ed1
X-Google-Attributes: gid103376,public
From: dewar@merv.cs.nyu.edu (Robert Dewar)
Subject: Re: language standards
Date: 1997/03/07
Message-ID: <dewar.857783781@merv>#1/1
X-Deja-AN: 223900555
References: <dewar.857664647@merv> <JSA.97Mar7151431@alexandria>
Organization: New York University
Newsgroups: comp.lang.ada
Date: 1997-03-07T00:00:00+00:00
List-Id: <comp.lang.ada>


Jon Anthony says

<<Now, on the face of it, your sentence here says that it is not silly
to say that there are "too many" ways to approach a language design to
decree any as standard.  Tell us, what other possible meaning could
there be?

Now, you go on _later_ to _introduce_ the _new_ requirement of "and no
agreement".  Of course, you also go on to simply apriori _decree_ that
there could _not possibly_ be any agreement.  I suppose that's how you
got confused about it all.>>

I really can't follow this peculiar reasoning, but I am guessing that
you have very little (no?) experience in programming language
standardization.

In practice, if there are many possible technical approaches to a problem,
then it is extremely hard, and many would say inappropriate, to standardize
one. It can sometimes be done, but you spend many chips to get it done.
Generally a standard development proceeds from consensus, adopting things
that everyone can agree on. A counter example in Ada 83 was tasking, and
there I think the standard succeeded not because there were not lots of
different aprpoaches, but rather that there was not much experience in
embedding concurrency in languages, so there was not muc in the way
of built-in constituencies.

The closest case in Ada 95 would be the distribution annex, where two
fudnamental approaches (RPC and message passing) clashed, and it was
quite a delicate balance to get a standard in this area.

In a case like GC, or pattern matching, where there really are many
different technical approaches (even in the SNOBOL camp, the declarative
vs procedural style, SNOBOL embodying the first more, and ICON the second,
is far from resolved), there is no possibility in my opinion of achieving
the kind of consensus that is required for an ISO standard.

So, once again (reread my statements that you kindly quoted), my point is
that if there are many possible technical approaches to a question, and
there is no clear consensus on which is the best, then you are unlikely
to be able to standardize in that area.

How that translates in your mind to me making a blanket statement that
there should be no language standards is still completely beyond me.
I can't even figure out the chain of reasoning, perhaps it is something
like:

  Dewar says you can't standardize something where there are many approaches
  All features in programming languages have many approaches
  Therefore ...

But the weakness is in the second step, since it just isn't true, we are
developing major areas of general agreement on how programming language
design should be approached at this stage, and indeed the basis of
the Ada 83 design was  that, with the exception of tasking, it was based
on established engineering approaches around which a consensus had
developed

In any case, rest assured that I *do* think programming languages
should be standardized (I was involved heavily in the standardization
of Algol-60 modified, the standarization work on Algol-68, and the
standardization of both Ada 83 and Ada 95, and I definitely do not
think that I was wasting my time :-) :-)