Re: Try J# ( was Re: J# is there )

Re: Try J# ( was Re: J# is there )

[Israel Raj T]

On Sat, 13 Oct 2001 21:17:26 GMT, "Marshall Spight" <mspight@dnai.com>
wrote:

>> > F# which will be a mangled Fortran
>> > P# which might be a cloned Perl
>> > T# as a new Tcl dialect
>> > A# an assembler version, with .Net macros
>> >
>> > S# the new .NET language to access some database in SQL syntax
>>
>> You laugh, but it's true! Already ISE has announced
>> Eiffel#, a .NETified version of their Eiffel language.
>>
>> Personally I can hardly wait for INTERCAL#. :D

>Visual BASBOL#. A combination of BASIC and COBOL.

Or Visual Ada# : The language that is Pascal + Cobol + Occam + all the
other bits the DOD committees thought of..

Re: Try J# ( was Re: J# is there )

[Dale Stanbrough]

Israel Raj T <israelrt@optushome.com.au> wrote:

> Or Visual Ada# : The language that is Pascal + Cobol + Occam + all the
> other bits the DOD committees thought of..

Don't post too much more. You'll only end up showing your ignorance
to a wider audience. 

Now repeat after me...

   Ada was not designed by a committee.
   Ada was not designed by a committee.
   Ada was not designed by a committee.
   ...

Dale

Language design by by committee ( was Re: Try J# ( was Re: J# is there ))

[Israel Raj T]

On Sun, 14 Oct 2001 04:39:14 GMT, Dale Stanbrough
<dale@cs.rmit.edu.au> wrote:
>Now repeat after me...
>   Ada was not designed by a committee.
>   Ada was not designed by a committee.
>   Ada was not designed by a committee.

Yes, you are absolutely right Dale....

At least 21 people and TWO committees were involved.

"In 1975 the U.S. Department of Defense (DoD) established a   A High
Order Language Working Group (HOLWG) ...to formulate the DoD
requirements for high order languages . The requirements were widely
distributed for comment throughout the military and civil communities,
producing successively more refined versions from Strawman through
Woodenman, Tinman, Ironman, and finally Steelman."
http://www.adahome.com/History/Steelman/steeltab.htm

"A high-order language working group (HOLWG) was formed with Whitaker
as chairman. Other representatives included Cmdr. Jack Cooper, the
Navy representative (along with Bernie Zempolich and Robert Kahane),
Bill Carlson of ARPA, Maj. Tom Jarrell of the Air Force, Paul Cohen of
the Defense Communications Agency (DCA), Lt. Col. Schamber of the
Marine Corps, and Maj. Breault of the Army."
http://www.adapower.com/adafaq.htm
   
"The Ada design team was led by Jean D. Ichbiah and has included
Berned Krieg-Bruechner,  Brain A. Wichmann, Henry F. Ledgard,
Jean-Cluade Heliard, Jean-Loup Gailly, Jean-Ryanmond  Abrial, John G.
P. Barnes, Mike Woodger, Olivier Roubine, Paul N. Hilfinger, and
Robert Firth. "
http://archive.adaic.com/pol-hist/history/histada.txt
     
As for the use of the word "committee":

"Dear Lord Lytton 
For some years now, the United States Department of Defense has been
engaged in a project to define a new computer programming language for
use in weapon systems, as opposed to scientific or business and
commercial applications.
This effort will shortly reach its climax with the publication of the
language design in April 1979.  Until now, the language has not had a
distinctive name, and the steering committee of the project has been
open to suggestions for such a name.  The only serious contender, and
one the committee would like to adopt, is Ada - in honour of Countess
Lovelace. "
http://archive.adaic.com/pol-hist/history/holwg-93/3.htm

As for protests that Steelman was not a design document but was merely
a requirements document, here is a brief extract from Steelman:

"7C. Scope Rules. A reference to an identifier that is not declared in
the most local scope shall refer to a program element that is
lexically global, rather than to one that is global through the
dynamic calling structure.

Functions
7D. Function Declarations. The type of the result for each function
must be specified in its declaration and shall be determinable during
translation. The results of functions may be of any type. If a result
is of a nonindirect array or record type then the number of its
components must be determinable by
the time of function call.

Parameters
7F. Formal Parameter Classes. There shall be three classes of formal
data parameters: (a) input parameters, which act as constants that are
initialized to the value of corresponding actual parameters at the
time of call, (b) input-output parameters, which enable access and
assignment to thecorresponding actual parameters, either throughout
execution or only upon call and prior to any exit, and (c) output
parameters, whose values are transferred to the corresponding actual
parameter only at the time of normal exit. In the latter two cases the
corresponding actual parameter shall be determined at time of call and
must be a variable or an assignable component of a composite type."

http://www.adahome.com/History/Steelman/steelman.htm

Re: Language design by by committee ( was Re: Try J# ( was Re: J# is there ))

[Dale Stanbrough]

Israel Raj T <israelrt@optushome.com.au> wrote:

Dale Stanbrough wrote:
> >Now repeat after me...
> >   Ada was not designed by a committee.
> >   Ada was not designed by a committee.
> >   Ada was not designed by a committee.
> 
> Yes, you are absolutely right Dale....
> 
> At least 21 people and TWO committees were involved.
> 
> "In 1975 the U.S. Department of Defense (DoD) established a   A High
> Order Language Working Group (HOLWG) ...to formulate the DoD
> requirements for high order languages . The requirements were widely
> distributed for comment throughout the military and civil communities,
> producing successively more refined versions from Strawman through
> Woodenman, Tinman, Ironman, and finally Steelman."
> http://www.adahome.com/History/Steelman/steeltab.htm

Yes, this was the requirements section.

> "A high-order language working group (HOLWG) was formed with Whitaker
> as chairman. Other representatives included Cmdr. Jack Cooper, the
> Navy representative (along with Bernie Zempolich and Robert Kahane),
> Bill Carlson of ARPA, Maj. Tom Jarrell of the Air Force, Paul Cohen of
> the Defense Communications Agency (DCA), Lt. Col. Schamber of the
> Marine Corps, and Maj. Breault of the Army."
> http://www.adapower.com/adafaq.htm


...and what was the structure of the group. Perhaps it was a committee,
perhaps Col. Whitaker had veto over all decisions (i personally don't
know).


> "The Ada design team was led by Jean D. Ichbiah and has included
> Berned Krieg-Bruechner,  Brain A. Wichmann, Henry F. Ledgard,
> Jean-Cluade Heliard, Jean-Loup Gailly, Jean-Ryanmond  Abrial, John G.
> P. Barnes, Mike Woodger, Olivier Roubine, Paul N. Hilfinger, and
> Robert Firth. "
> http://archive.adaic.com/pol-hist/history/histada.txt


Jean Ichbiah definately did have the power to overrule, and examples
of this being used have been posted to the Ada newsgroup in the past.
   
  
> As for the use of the word "committee":
> 
> "Dear Lord Lytton 
> [...]
> This effort will shortly reach its climax with the publication of the
> language design in April 1979.  Until now, the language has not had a
> distinctive name, and the steering committee of the project has been
> open to suggestions for such a name.  The only serious contender, and
> one the committee would like to adopt, is Ada - in honour of Countess
> Lovelace. "
> http://archive.adaic.com/pol-hist/history/holwg-93/3.htm

This was still in the requirements phase.

> As for protests that Steelman was not a design document but was merely
> a requirements document, here is a brief extract from Steelman:
> 
[examples of requirements that look suspiciously like design removed]

I went to the website that you specified, and also found the following...


13E. Translator Characteristics. Translators for the language will be 
written in the language and will be able to produce code for a variety 
of object machines. The machine independent parts of translators should 
be separate from code generators. Although it is desirable, translators 
need not be able to execute on every object machine. The internal 
characteristics of the translator (i.e., the translation method) shall 
not be specified by the language definition or standards.


which was a bizzare requirement, yet it was clearly not followed
by a lot of implementors, nor did it find it's way into the
final design. Clearly the -design- team removed it from consideration.
Perhaps the team considered all of the requirements, and removed
those that they didn't like, and kept those they did (once again
I don't know the process that was followed - i suspect we need
a more authoriatative history than one that is presumed by looking
through some of the available documentation).

What I see as the implicit assumption in the original posting
that the design team was a committee (where committee is being
used in the pejorative sense) is one that cannot be sustained
on the available evidence. Do you have any more evidence from
the people involved in the design process that indicates that
it was a mish mash of competing interests, rather than being
reasonably well thought out?

BTW more than a couple of people involved does not equal bad
design. The Java API had thread.stop, thread.resume right from
the word go; anybody familiar with threading research would have
told you they are not good routines to have.

Dale

Re: Language design by by committee ( was Re: Try J# ( was Re: J# is there ))

[Israel Raj T]

On Sun, 14 Oct 2001 05:50:22 GMT, Dale Stanbrough
<dale@cs.rmit.edu.au> wrote:
>> "A high-order language working group (HOLWG) was formed with Whitaker
>> as chairman. Other representatives included Cmdr. Jack Cooper, the
>> Navy representative (along with Bernie Zempolich and Robert Kahane),
>> Bill Carlson of ARPA, Maj. Tom Jarrell of the Air Force, Paul Cohen of
>> the Defense Communications Agency (DCA), Lt. Col. Schamber of the
>> Marine Corps, and Maj. Breault of the Army."
>> http://www.adapower.com/adafaq.htm

>...and what was the structure of the group. Perhaps it was a committee,
>perhaps Col. Whitaker had veto over all decisions (i personally don't
>know).

Neither do I .

However, whether or not he had veto rights, in practice the committee
worked by consensus ie: classic committee mode. In Whitaker's own
words:

"The organization and procedures of the HOLWG were up to the chairman
- anything I could make work.  The only reporting was to DDR&E and I
made the reports.  This sounds dictatorial, and to a large degree it
was, but it only worked as long as I held it together.  In fact, it
was a consensus operation.  Every formal vote that the HOLWG ever took
was unanimous!  That is not to say that there were not many lively
discussions and opposing views, but I waited until everybody agreed on
a course of action before posing a formal vote.  The question was
usually not "which of these is your favorite?", but "which should be
the HOLWG choice?"  Under those conditions, the HOLWG functioned
smoothly. "
http://archive.adaic.com/pol-hist/history/holwg-93/holwg-93.htm

Re: Language design by by committee ( was Re: Try J# ( was Re: J# is there ))

[Israel Raj T]

On Sun, 14 Oct 2001 05:50:22 GMT, Dale Stanbrough
<dale@cs.rmit.edu.au> wrote:

>Do you have any more evidence from
>the people involved in the design process that indicates that
>it was a mish mash of competing interests, rather than being
>reasonably well thought out?

Tony Hoare was an early member of the design committee until he left
in disgust. In his ACM Turing Award lecture "The Emperor's Old Clothes
" he says just that. 

Re: Language design by by committee ( was Re: Try J# ( was Re: J# is there ))

[Dale Stanbrough]

Israel Raj T wrote:

> Tony Hoare was an early member of the design committee until he left
> in disgust. In his ACM Turing Award lecture "The Emperor's Old Clothes
> " he says just that. 

Tony Hoare left because he thought the language was way too big.
Later on he wrote a foreward to a book in which he recanted this
view, and hope people would have the opportunity to use Ada (I
think he said "this fine language", but I can't be sure).

Dale

Re: Language design by by committee ( was Re: Try J# ( was Re: J# is there ))

[Dale Stanbrough]

Israel Raj T wrote:

> Neither do I .
> 
> However, whether or not he had veto rights, in practice the committee
> worked by consensus ie: classic committee mode. In Whitaker's own
> words:

So it seems. He also reports that it was a rather successful one, with
one comment being...

"At this time there was an initiative called the "Two Way Street", which 
was to promote Defense acquisition cooperation between the United States 
and its NATO allies. The DDR&E once told me that he thought that the 
HOLWG program was the only example that was working."


Dale

Re: Language design by by committee ( was Re: Try J# ( was Re: J# is there ))

[Israel Raj T]

On Sun, 14 Oct 2001 07:23:52 GMT, Dale Stanbrough
<dale@cs.rmit.edu.au> wrote:

>Israel Raj T wrote:
>
>> Neither do I .
>> 
>> However, whether or not he had veto rights, in practice the committee
>> worked by consensus ie: classic committee mode. In Whitaker's own
>> words:
>
>So it seems. He also reports that it was a rather successful one

True.
In any case, Ada is probably the only programming language that I
still have fond memories of...

Re: Language design by by committee ( was Re: Try J# ( was Re: J# is there ))

[Dale Stanbrough]

Israel Raj T wrote:

> True.
> In any case, Ada is probably the only programming language that I
> still have fond memories of...

I found the tiny amounts of Smalltalk and Scheme I did to be a lot
of fun. I suspect that I should play with Haskell (or O-Caml?) 
one day as well :-)

Dale

Re: Language design by by committee ( was Re: Try J# ( was Re: J# is there ))

[Mike Silva]

Dale Stanbrough <dale@cs.rmit.edu.au> wrote in message news:<dale-400CAE.17165114102001@mec2.bigpond.net.au>...
> Israel Raj T wrote:
> 
> > Tony Hoare was an early member of the design committee until he left
> > in disgust. In his ACM Turing Award lecture "The Emperor's Old Clothes
> > " he says just that. 
> 
> Tony Hoare left because he thought the language was way too big.
> Later on he wrote a foreward to a book in which he recanted this
> view, and hope people would have the opportunity to use Ada (I
> think he said "this fine language", but I can't be sure).
> 
> Dale

A google search finds this:


 Here is the text of Mr. Hoare's foreward to an Ada book in 1987.  You
 may judge for yourself whether he was as anti-Ada as you suggest.

 C.A.R. Hoare's comments in the foreward to Ada Language and
Methodology

"  'I enjoyed reading the Algol 60 report;  it taught me a lot about
programming.'  This
is the comment of a data processing manager of a major motor
manufacturing company,
who had no conceivable prospect of ever using the language to program
a computer. It is
a most perceptive comment, because it describes an important goal in
the design of a new
programming language:  that it should be an aid in specification,
description, and design of
programs, as well as in the construction of reliable code.

This was one of the main aims in the design of the language which was
later given the name
Ada.  As a result, the language incorporates many excellent structural
features which have
proved their value in many precursor languages such as Pascal and
Pascal Plus.

The combination of many complex features into a single language has
led to an unfortunate
delay in availability of production-quality implementations.  But the
long wait is coming to
an end, and one can now look forward to a rapid and widespread
improvement in programming
practice, both from those who use the language and from those who
study its concepts and structures.

I hope that this book will contribute directly to these ideals, which
have inspired many of the other
books in the same series. It continues the tradition of the series in
that it describes how the language
can be used as the target of sound programming methodology, embracing
the full life-cycle of a programming
project.  It explains not just the features and details of the
language, but also their purpose
and method of effective use.

The complexities and difficulties are not glossed over;  they are
explained within the appropriate context,
with hints on how to avoid any consequent problems.  I hope the book
will be useful, both to those who have the
privilege or obligation to use the language, and to those who have the
interest and curiosity to understand and
appreciate its rationale. "

               from the foreward to Ada Language and Methodology
                                                 David A. Watt, Brian
A. Wichmann, and William Findlay,
                                                 Prentice-Hall
International Series in Computer Science ISBN 0-13-004078-9
                                                 Published in 1987


--------------------------------------------------------------------------------

Re: Language design by by committee ( was Re: Try J# ( was Re: J# is there ))

[Robert Dewar]

Israel Raj T <israelrt@optushome.com.au> wrote in message news:<nc6istc54r252g98893pn2itn3875birhm@4ax.com>...
> 
> Yes, you are absolutely right Dale....
> 
> At least 21 people and TWO committees were involved.
> 
> "In 1975 the U.S. Department of Defense (DoD) established 
> a   A High
> Order Language Working Group (HOLWG) ...to formulate the > DoD
> requirements for high order languages

Requirements /= language design

> "A high-order language working group (HOLWG) was formed with Whitaker
> as chairman. Other representatives included Cmdr. Jack Cooper, the
> Navy representative (along with Bernie Zempolich and Robert Kahane),
> Bill Carlson of ARPA, Maj. Tom Jarrell of the Air Force, Paul Cohen of
> the Defense Communications Agency (DCA), Lt. Col. Schamber of the
> Marine Corps, and Maj. Breault of the Army."
> http://www.adapower.com/adafaq.htm

The function of this committee was to organize the effort
and coordinate the work of the design teams, HOLWG did NOT
do the language design.

> "The Ada design team was led by Jean D. Ichbiah and has included
> Berned Krieg-Bruechner,  Brain A. Wichmann, Henry F. Ledgard,
> Jean-Cluade Heliard, Jean-Loup Gailly, Jean-Ryanmond  Abrial, John G.
> P. Barnes, Mike Woodger, Olivier Roubine, Paul N. Hilfinger, and
> Robert Firth. "
> http://archive.adaic.com/pol-hist/history/histada.txt

There is a big difference between a team and a committee.
The Superbowl cannot be won by a single player, but it 
also cannot be won by a commitee (see my letter to GCN
on this issue :-)


> "Dear Lord Lytton 
> For some years now, the United States Department of Defense has been
> engaged in a project to define a new computer programming language for
> use in weapon systems, as opposed to scientific or business and
> commercial applications.
> This effort will shortly reach its climax with the publication of the
> language design in April 1979.  Until now, the language has not had a
> distinctive name, and the steering committee of the project has been
> open to suggestions for such a name. 

The steering commitee, as suggested by its name, was a
coordinating commitee, it did not do language design!

> The only serious contender, and
> one the committee would like to adopt, is Ada - in honour of Countess
> Lovelace. "
> http://archive.adaic.com/pol-hist/history/holwg-93/3.htm

Yes, it is fair to say that the name of the language was
the product of commitee discussions.

> As for protests that Steelman was not a design document but was merely
> a requirements document, here is a brief extract from Steelman:

Just look at Blue, Red, Yellow, Green, to see how different
languages meeting these requirements could be. Yes, there
were some specific requirements established which influenced the
design, that's what requirements do.

Basically the only people who claim Ada was designed
by a committee are people who weren't around and are
ignorant of the actual facts. If you were around, you
would know how remarkably false this was (indeed there
were some occasions on which i would have liked the
commitees involved to have had more say in the design
of the language -- one example, the DR's voted close
to unanimously to get rid of derived types in their
current form -- the design team simply ignored this vote :-)

Re: Language design by by committee ( was Re: Try J# ( was Re: J# is there ))

[Darren New]

> Just look at Blue, Red, Yellow, Green, to see how different
> languages meeting these requirements could be. 

Are these designs online anywhere, out of curiousity?

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
                   Who is this Dr. Ibid anyway, 
                  and how does he know so much?

Re: Language design by by committee ( was Re: Try J# ( was Re: J# is there ))

[Philip Anderson]

Israel Raj T wrote:
>  
> Tony Hoare was an early member of the design committee until he left
> in disgust. In his ACM Turing Award lecture "The Emperor's Old Clothes
> " he says just that.

By "design committee", do you mean the design team or the steering
committee?  (two rather different animals)

-- 
hwyl/cheers,
Philip Anderson
Alenia Marconi Systems
Cwmbr�n, Cymru/Wales

Re: Language design by by committee ( was Re: Try J# ( was Re: J# is there ))

[Ted Dennison]

In article <dale-400CAE.17165114102001@mec2.bigpond.net.au>, Dale Stanbrough
says...
>
>Israel Raj T wrote:
>
>> Tony Hoare was an early member of the design committee until he left
>> in disgust. In his ACM Turing Award lecture "The Emperor's Old Clothes
>> " he says just that. 
>
>Tony Hoare left because he thought the language was way too big.
>Later on he wrote a foreward to a book in which he recanted this
>view, and hope people would have the opportunity to use Ada (I
>think he said "this fine language", but I can't be sure).

..and compared to C++, Ada is fairly small. 

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: Language design by by committee ( was Re: Try J# ( was Re: J# is there ))

[Ray Blaak]

Israel Raj T <israelrt@optushome.com.au> writes:
> On Sun, 14 Oct 2001 04:39:14 GMT, Dale Stanbrough
> <dale@cs.rmit.edu.au> wrote:
> >Now repeat after me...
> >   Ada was not designed by a committee.
> >   Ada was not designed by a committee.
> >   Ada was not designed by a committee.

To me whether or not Ada was designed by a committee is irrelevant, and
perhaps semantic quibbling. Why should we care? Why does anyone care? I have
never understood this objection of "designed by a committee".

One should evaluate a language on its own merits. Whether 1, 2 or N people
designed it simply shouldn't matter; the language stands or falls based on its
own characteristics and not those of its authors.

Things get silly otherwise: "here is a great language that can do these
wonderful things". "But it was designed by a committee, so we can't use it!".
-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
blaak@telus.net                                The Rhythm has my soul.

Re: Language design by by committee ( was Re: Try J# ( was Re: J# is there ))

[Marin David Condic]

Excellent point. The "designed by committee" criticism is practically an ad
hominem attack - if a language can be said to be "hominem" :-) The truth or
falsity of that accusation is basically irrelavent. The question ought to be
"Is the language well designed for its intended application?" If not, then
let's here some specific criticisms of what is "bad" about it. ("Too big"? -
Level that one against lots of languages these days! C++ is almost certainly
bigger - especially considering the convoluted semantics of many features.
"Too many features"? Which ones would you get rid of and why?)

Ada was designed for large, long-lived applications that may have a high
reliability requirement. To that end, I think it satisfies its requirements
rather well. It is a very consistent and orthogonal language that has well
defined & consistent behaviors for its various features. Plenty of error
checking is included to help insure reliable code. If one thinks it is
designed with too many competing requirements that created too many oddball
features, then describe those and explain why they are bad. I'd think it is
interesting to note that many languages that came after Ada have included
many of its features in some other form - a testament that perhaps they
really are useful? Or is it that all languages get "designed by committee" -
one consisting of its more vocal user base. :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Ray Blaak" <blaak@telus.net> wrote in message
news:uzo6s26q7.fsf@telus.net...
>
> Things get silly otherwise: "here is a great language that can do these
> wonderful things". "But it was designed by a committee, so we can't use
it!".

Re: Language design by by committee ( was Re: Try J# ( was Re: J# is there ))

[Pascal Obry]

Ray Blaak <blaak@telus.net> writes:

> To me whether or not Ada was designed by a committee is irrelevant, and
> perhaps semantic quibbling. Why should we care? Why does anyone care? I have
> never understood this objection of "designed by a committee".

Me too. I have never ever really understood this point. Good to hear I'm not
the only one :)

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--|
--| "The best way to travel is by means of imagination"

Re: Language design by by committee ( was Re: Try J# ( was Re: J# is there ))

[Wes Groleau]

Ray Blaak wrote:
> To me whether or not Ada was designed by a committee is irrelevant, and

It's a defense mechanism.  If something is
reasonable and logical, the only way to fight
it is hype and emotion.

Like I was recently informed elsewhere,
"that article was on an anarchist web-site,
therefore its medical journal citations are
meaningless."

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Language design by by committee ( was Re: Try J# ( was Re: J# is there ))

[Marin David Condic]

Well, here is a sad thing about the human condition. We'd all like to think
that we base our decisions about what we prefer on logic and rationality,
yet all too often, its the reverse. We decide what we like, then we go about
looking for reasons and logic to support our prejudices.

Too many people have based their decisions about Ada on hearsay,
misinformation, cursory glances and preconceived notions. Its too bad
because they end up missing out on what they could learn from the language -
even if they were using something else more regularly. Most of the Ada crowd
has some reasonable level of experience with things like C++ and Java and,
sometimes we irrationally beat up on them because they aren't what we are
used to or prefer. We can be guilty of the same prejudices.

I think many times the criticisms are fair and balanced since most of us Ada
guys know there are applications where we are better off using C++ or Java.
If we know C++ and Java with some level of intimacy and still prefer Ada,
then perhaps that gives us some credibility that the other side may not
have. I've constructed and worked on major systems built in C & C++. Can
your garden variety Ada critic say the same? I'm sure others from C.L.A
could tell similar stories.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/

"Wes Groleau" <wwgrol@sparc01.ftw.rsc.raytheon.com> wrote in message
news:3BCB3F96.20817310@sparc01.ftw.rsc.raytheon.com...
>
> It's a defense mechanism.  If something is
> reasonable and logical, the only way to fight
> it is hype and emotion.
>
> Like I was recently informed elsewhere,
> "that article was on an anarchist web-site,
> therefore its medical journal citations are
> meaningless."
>

Re: Language design by by committee ( was Re: Try J# ( was Re: J# is there ))

[Florian Weimer]

Ted Dennison<dennison@telepath.com> writes:

>>Tony Hoare left because he thought the language was way too big.
>>Later on he wrote a foreward to a book in which he recanted this
>>view, and hope people would have the opportunity to use Ada (I
>>think he said "this fine language", but I can't be sure).
>
> ..and compared to C++, Ada is fairly small. 

I'm not sure if this is true if you look at the language core only
(and don't take into account any non-essential run-time library
components, such as containers or valarrays).

"Size" of Ada vs. C++

[Ted Dennison]

In article <87ofn8a9dv.fsf@deneb.enyo.de>, Florian Weimer says...
>
>I'm not sure if this is true if you look at the language core only
>(and don't take into account any non-essential run-time library
>components, such as containers or valarrays).

Then explain in one simple paragraph how C++ constructors and destructors work
(how they are invoked, what you have to do to make one "default", how you
prevent their use in parameter passing or as implicit casts, how you have to
invoke the parent's constructors from the constructor of a child, how to ensure
all destructors in a object's type hierarchy get called during delete, etc.)
This is all stuff that is pretty much required for basic C++ programming, and
its more arcane and exception-riddled than most English spelling rules.

If we throw out annex-based libraries as you suggest, Ada doesn't even *have*
constructors and destructors to talk about. :-)

Or we can compare the "cast system" of the two languages. Ada's rule is pretty
simple: the types have to be derived from each other, or predefined numeric
types. C++ on the other hand, has at least 3 different types of cast, plus an
old fashioned implicit one. To make things more interesting, constructor writers
can inadvertently create new implicit ones if they aren't careful...

I'm not saying all this extra stuff in C++ is *bad*. But there certianly is way
more of it.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: Language design by by committee ( was Re: Try J# ( was Re: J# is there ))

[minyard]

Florian Weimer <fw@deneb.enyo.de> writes:

> Ted Dennison<dennison@telepath.com> writes:
> 
> >>Tony Hoare left because he thought the language was way too big.
> >>Later on he wrote a foreward to a book in which he recanted this
> >>view, and hope people would have the opportunity to use Ada (I
> >>think he said "this fine language", but I can't be sure).
> >
> > ..and compared to C++, Ada is fairly small. 
> 
> I'm not sure if this is true if you look at the language core only
> (and don't take into account any non-essential run-time library
> components, such as containers or valarrays).

It's true, especially if you include the language core.  Things like:

 * Number of operators
 * Number of reserved words
 * Size of the specification (Note: This particular item is from vague
   memory, but I think it's right).
 * Number of ways to shoot yourself in the foot :-).  Sorry, I couldn't
   resist.

It's probably true that the amount of C++ constructs that an average
C++ designer uses may be smaller than the amount of Ada constructs an
average Ada designer uses, but, to quote someone else, "most C++
designers program in 'C++--'".  (I think it was Bill Gates).

-Corey

Re: Language design by by committee ( was Re: Try J# ( was Re: J# is there ))

[Tim Tyler]

In comp.lang.java.advocacy Ray Blaak <blaak@telus.net> wrote:
: Israel Raj T <israelrt@optushome.com.au> writes:
:> Dale Stanbrough <dale@cs.rmit.edu.au> wrote:

:> >Now repeat after me...
:> >   Ada was not designed by a committee.
:> >   Ada was not designed by a committee.
:> >   Ada was not designed by a committee.

: To me whether or not Ada was designed by a committee is irrelevant, and
: perhaps semantic quibbling. Why should we care? Why does anyone care? I have
: never understood this objection of "designed by a committee".

: One should evaluate a language on its own merits. Whether 1, 2 or N people
: designed it simply shouldn't matter; the language stands or falls based
: on its own characteristics and not those of its authors.

Maybe in an ideal world.  In practice languages get judged for all sorts
of reasons that have nothing to do with their own merits.  Looking at the
merits of something can be a time-consuming process.  Far easier and
quicker to make a snap-decision based on popular opinion and hearsay.
-- 
__________
 |im |yler  Index of my domains: http://timtyler.org/  tt@iname.com

Re: Language design by by committee ( was Re: Try J# ( was Re: J# is there ))

[Tim Tyler]

In comp.lang.java.advocacy Pascal Obry <p.obry@wanadoo.fr> wrote:
: Ray Blaak <blaak@telus.net> writes:

:> To me whether or not Ada was designed by a committee is irrelevant, and
:> perhaps semantic quibbling. Why should we care? Why does anyone care? I have
:> never understood this objection of "designed by a committee".

: Me too. I have never ever really understood this point. Good to hear I'm not
: the only one :)

Here's a quick stab at explaining it: the creative process often works
best when all the elements involved are connected together by high-speed
axons.  When some of the communications channels involved have to go onto
the speech level, across to other individuals and back again, everything
is slowed down, and garbled.  Also a collection of individuals is less
likely to behave as a coherent unit that an collection of an individuals
neurons.  The result is perhaps more likely to be an "average" - a
compromise between different design aims.

As consequences of this sort of thing design-by-committee is likely to
produce systematically different results to (say) design by
individual creative genius.  Not everyone always likes the differences.
-- 
__________
 |im |yler  Index of my domains: http://timtyler.org/  tt@iname.com

Re: Language design by by committee ( was Re: Try J# ( was Re: J# is there ))

[Ray Blaak]

Tim Tyler <tt@iname.com> writes:
> Here's a quick stab at explaining it: the creative process often works
> best when all the elements involved are connected together by high-speed
> axons.  When some of the communications channels involved have to go onto
> the speech level, across to other individuals and back again, everything
> is slowed down, and garbled.  Also a collection of individuals is less
> likely to behave as a coherent unit that an collection of an individuals
> neurons.  The result is perhaps more likely to be an "average" - a
> compromise between different design aims.

This is quite possible, and I have encountered this before. On the other hand,
a group of people very often catches things the lone genious overlooked.

On yet the other hand, it still shouldn't matter. Both lone genious or the
committee might have produced solid gold or complete crap. You cannot know
until you check.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
blaak@telus.net                                The Rhythm has my soul.

Re: "Size" of Ada vs. C++

[Florian Weimer]

Ted Dennison<dennison@telepath.com> writes:

>>I'm not sure if this is true if you look at the language core only
>>(and don't take into account any non-essential run-time library
>>components, such as containers or valarrays).
>
> Then explain in one simple paragraph how C++ constructors and
> destructors work

I'm going to do that if you describe how to implement smart pointers
in Ada (without taking advantage of an implementation permission). ;-)

> This is all stuff that is pretty much required for basic C++ programming, and
> its more arcane and exception-riddled than most English spelling rules.

This is very true, but it doesn't make Ada a smaller language than C++
per se.

> If we throw out annex-based libraries as you suggest, Ada doesn't even *have*
> constructors and destructors to talk about. :-)

Section 7.6 is not in Annex A.

> Or we can compare the "cast system" of the two languages. Ada's rule
> is pretty simple: the types have to be derived from each other, or
> predefined numeric types. C++ on the other hand, has at least 3
> different types of cast, plus an old fashioned implicit one.

What about Ada.Unchecked_Conversion?  It's comparable to
reinterpret_cast<>.

> To make things more interesting, constructor writers
> can inadvertently create new implicit ones if they aren't careful...

That's why the "explicit" keyword was introduced.

Anyway, I think it's rather strange to judge a language by the "size"
of its definition.

Re: Language design by by committee ( was Re: Try J# ( was Re: J# is there ))

[Florian Weimer]

minyard@acm.org writes:

>> > ..and compared to C++, Ada is fairly small. 
>> 
>> I'm not sure if this is true if you look at the language core only
>> (and don't take into account any non-essential run-time library
>> components, such as containers or valarrays).
>
> It's true, especially if you include the language core.

>  Things like:
>
>  * Number of operators
>  * Number of reserved words
>  * Size of the specification (Note: This particular item is from vague
>    memory, but I think it's right).

250 vs. 300 pages is not a huge margin.

What about:

   * Number of different forms of type declarations
   * Number of representation control mechanisms
   * Elaboration issues
   * Tasking semantics

These language features are much more complex in Ada than in C++
(simply because C++ hasn't got some of these features).

In any case, I doubt that the "size" of the language tells us much
about the language itself.  Perhaps there are additional factors
that indicate that the language is too big (for example, if no
complete implementations exist), but size is not a problem per se.
For example, I think most if not all Ada programmers appreciate the
elaboration semantics.  They are rather complex, but without them,
very annoying problems would arise.

Re: "Size" of Ada vs. C++ is there ))

[Florian Weimer]

minyard@acm.org writes:

>> > ..and compared to C++, Ada is fairly small. 
>> 
>> I'm not sure if this is true if you look at the language core only
>> (and don't take into account any non-essential run-time library
>> components, such as containers or valarrays).
>
> It's true, especially if you include the language core.

>  Things like:
>
>  * Number of operators
>  * Number of reserved words
>  * Size of the specification (Note: This particular item is from vague
>    memory, but I think it's right).

250 vs. 300 pages is not a huge margin.

What about:

   * Number of different forms of type declarations
   * Number of representation control mechanisms
   * Elaboration issues
   * Tasking semantics

These language features are much more complex in Ada than in C++
(simply because C++ hasn't got some of these features).

In any case, I doubt that the "size" of the language tells us much
about the language itself.  Perhaps there are additional factors
that indicate that the language is too big (for example, if no
complete implementations exist), but size is not a problem per se.
For example, I think most if not all Ada programmers appreciate the
elaboration semantics.  They are rather complex, but without them,
very annoying problems would arise.

Re: "Size" of Ada vs. C++

[Robert*]

In article <87y9mcoz6s.fsf@deneb.enyo.de>, Florian says...
>
 
>Anyway, I think it's rather strange to judge a language by the "size"
>of its definition.

I always thought this is funny. I read that M3 designers aimed for 50 
pages, but they had to settle for 60 pages. 

Give me any language specification manual, the Ada RM for example, and 
I can print it using half the number of pages, making the language half 
as big in an instance. 

I'll simply use smaller fonts, reduce the margine size, print it 
on 11x17 in paper, use small words instead of big ones, and explain
things in more terse sentences. So, why do people measuer how big
a language by the number of pages that makes up the language reference?

Also, size is not everything you know.

Re: "Size" of Ada vs. C++

[Marin David Condic]

You need not even go that far - although I agree that the
constructor/destructor thingie is so confusing and filled with "I before E
except after C..." kinds of rules that you could probably write a novel on
that subject alone. Just consider the rules about infix operators and
expression evaluation - throw in side effects just for grins - and see how
fast you've asked for an arcane, cryptic, and turgid monograph be written on
the subject.

Feature for feature, C++ may in some sense be smaller - no tasks for one
thing. However, in terms of all the options and semantics of the features it
*does* have, I think one would have to conclude that it is definitely a
bigger language. Perhaps a half-way fair comparison might be based on the
size of the compiler front-ends required for both languages? (Although any
comparison of any code size is extremely problematic - as we've discussed
here before.) The weight of the ISO standard documents as a metric?)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Ted Dennison" <dennison@telepath.com> wrote in message
news:bMIy7.30243$ev2.36939@www.newsranger.com...
>
> Then explain in one simple paragraph how C++ constructors and destructors
work
> (how they are invoked, what you have to do to make one "default", how you
> prevent their use in parameter passing or as implicit casts, how you have
to
> invoke the parent's constructors from the constructor of a child, how to
ensure
> all destructors in a object's type hierarchy get called during delete,
etc.)
> This is all stuff that is pretty much required for basic C++ programming,
and
> its more arcane and exception-riddled than most English spelling rules.
>
> If we throw out annex-based libraries as you suggest, Ada doesn't even
*have*
> constructors and destructors to talk about. :-)
>
> Or we can compare the "cast system" of the two languages. Ada's rule is
pretty
> simple: the types have to be derived from each other, or predefined
numeric
> types. C++ on the other hand, has at least 3 different types of cast, plus
an
> old fashioned implicit one. To make things more interesting, constructor
writers
> can inadvertently create new implicit ones if they aren't careful...
>
> I'm not saying all this extra stuff in C++ is *bad*. But there certianly
is way
> more of it.
>
> ---
> T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
>
> No trees were killed in the sending of this message.
> However a large number of electrons were terribly inconvenienced.

Re: Language design by by committee ( was Re: Try J# ( was Re: J# is there ))

[Wes Groleau]

Tim Tyler wrote:
> As consequences of this sort of thing design-by-committee is likely to
> produce systematically different results to (say) design by
> individual creative genius.  Not everyone always likes the differences.

Who cares what it's likely to produce?  It's already produced--all one
has to do is look at it and see whether it's good or bad.  The evidence
is available.  The "designed by committee" slogan is just a red herring
used for two purposes:

1. To rationalize someone's choice to avoid Ada
2. To distract other people from finding out how good Ada is.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Language design by by committee ( was Re: Try J# ( was Re: J# is there ))

[Arthur Evans Jr]

In article <m3n12sp1l7.fsf@blight.transcend.org>, Ray Blaak
<blaak@telus.net> wrote:

> This is quite possible, and I have encountered this before. On the other hand,
> a group of people very often catches things the lone genious overlooked.

You've picked up on what I see as the great strength of the Ada
design process.  Although the design itself was largely the work of
a single immensely talented individual, Jean Ichbiah, there were
(at least) two "committees" surrounding the design.

Jean's Design Team in France included first rate people who
influenced the design in many ways.  They all contributed.

And the Distinguished Reviewers carefully examined all aspects of
the design and gave their feedback to the Design Team.

Thus while the Ada design was controled by a single induvidual, he
had the benefit of many talented people ofering analyses and
opinions of the design at each step.

Was Jean really in control?  Surely!  As someone reported earlier
on this thread, he retained derived types in the face of an
overwhelming vote of the DRs to delete that feature.  And in
hindsight I'm happy to say we were wrong and he was right.  OTOH,
there were many occasions when the DRs raised objections that Jean
accepted, leading to redesign.  In other words, he listened to us
but didn't necessarily follow us.  In the end, he decided.

Although I was of course not privy to the inner workings of the
Design Team, I have no doubt that the same kinds of interactions
took place there, too.

Art Evans

Re: Language design by by committee ( was Re: Try J# ( was Re: J# is there ))

[Arthur Evans Jr]

In article <m3n12sp1l7.fsf@blight.transcend.org>, Ray Blaak
<blaak@telus.net> wrote:

> This is quite possible, and I have encountered this before. On the other hand,
> a group of people very often catches things the lone genious overlooked.

You've picked up on what I see as the great strength of the Ada
design process.  Although the design itself was largely the work of
a single immensely talented individual, Jean Ichbiah, there were
(at least) two "committees" surrounding the design.

Jean's Design Team in France included first rate people who
influenced the design in many ways.  They all contributed.

And the Distinguished Reviewers carefully examined all aspects of
the design and gave their feedback to the Design Team.

Thus while the Ada design was controled by a single induvidual, he
had the benefit of many talented people ofering analyses and
opinions of the design at each step.

Was Jean really in control?  Surely!  As someone reported earlier
on this thread, he retained derived types in the face of an
overwhelming vote of the DRs to delete that feature.  And in
hindsight I'm happy to say we were wrong and he was right.  OTOH,
there were many occasions when the DRs raised objections that Jean
accepted, leading to redesign.  In other words, he listened to us
but didn't necessarily follow us.  In the end, he decided.

Although I was of course not privy to the inner workings of the
Design Team, I have no doubt that the same kinds of interactions
took place there, too.

Art Evans

Re: Language design by by committee ( was Re: Try J# ( was Re: J# is there ))

[Ted Dennison]

In article <uelo4kc1t.fsf@wanadoo.fr>, Pascal Obry says...
>
>
>Ray Blaak <blaak@telus.net> writes:
>
>> To me whether or not Ada was designed by a committee is irrelevant, and
>> perhaps semantic quibbling. Why should we care? Why does anyone care? I have
>> never understood this objection of "designed by a committee".
>
>Me too. I have never ever really understood this point. Good to hear I'm not
>the only one :)

I think this is probably an American cultural thing. However, being an American,
I do believe there is some truth in it. :-)

Perhaps Tucker Taft (and Jean Ichabah before him) weren't better programming
language designers than everyone on their respective Ada steering committes.
However, they were certianly better than the *average* of everyone on those
committes. So to my mind having the committes making all the design decisions
instead would have been just insane. Fortunately for us all, that's not the way
it worked.

Interestingly, C++'s development between 1990 and its standarization in 1998
*does* seem to have been performed by committe. Actually, not just by *a*
committe, but by a group of committees. (Stroustrup referred to them in his book
as "the joint C++ standard committees"). 

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: Sice of C++ vs Ada

[Marin David Condic]

Size, in and of itself, should not be the issue. Size is an issue if it
creates needless complexity and/or inhibits implementation and use. Just
because Ada is "big" (bigger than C at least) doesn't mean that the size
makes it "bad". One can always start and continue programming with a
Pascal-like subset of Ada and do just fine. The extra features do not
intrude on everyday life. To some extent this is true of C++ because you can
stick to a C-subset of the language, but I think that the instant one gets
to classes and anything in the OO realm, the C++ stuff gets far more twisted
and convoluted than does Ada with packages/tagged-types.

It would be useful to have some sort of complexity metric, but I suspect
this is not the kind of thing that lends itself to being measured in an
unambiguous way. The judgement is going to end up subjective for the most
part.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Ted Dennison" <dennison@telepath.com> wrote in message
news:8sXy7.31264$ev2.37455@www.newsranger.com...
> In article <87y9mcoz6s.fsf@deneb.enyo.de>, Florian Weimer says...
>
> >Anyway, I think it's rather strange to judge a language by the "size"
> >of its definition.
>
> I'd agree with that. It was Hoare's(?) comment, not mine. I was just
pointing
> out that if one takes this attitude towards Ada, then one also has to
judge C++
> as even worse.
>

Re: "Size" of Ada vs. C++ is there ))

[minyard]

Florian Weimer <fw@deneb.enyo.de> writes:

> minyard@acm.org writes:
> 
> >> > ..and compared to C++, Ada is fairly small. 
> >> 
> >> I'm not sure if this is true if you look at the language core only
> >> (and don't take into account any non-essential run-time library
> >> components, such as containers or valarrays).
> >
> > It's true, especially if you include the language core.
> 
> >  Things like:
> >
> >  * Number of operators
> >  * Number of reserved words
> >  * Size of the specification (Note: This particular item is from vague
> >    memory, but I think it's right).
> 
> 250 vs. 300 pages is not a huge margin.
> 
> What about:
> 
>    * Number of different forms of type declarations
>    * Number of representation control mechanisms
>    * Elaboration issues
>    * Tasking semantics
> 
> These language features are much more complex in Ada than in C++
> (simply because C++ hasn't got some of these features).
> 
> In any case, I doubt that the "size" of the language tells us much
> about the language itself.  Perhaps there are additional factors
> that indicate that the language is too big (for example, if no
> complete implementations exist), but size is not a problem per se.
> For example, I think most if not all Ada programmers appreciate the
> elaboration semantics.  They are rather complex, but without them,
> very annoying problems would arise.

I'm not arguing that point, the "size" of a language is quite
meaningless, otherwise we would all be programming Turing machines :-).
Someone was saying that Ada might not be smaller than C++, and I
was giving some fuel for the debate.

But, it's quite amazing to me that Ada can include all the tasking
semantics, a full set of I/O libaries, all the fancy numeric types,
annexes for real-time, systems programming, information systems,
distributed systems, and safety and security, and still weigh in with
a smaller and more usable specification than C++ and a simpler syntax.

-Corey

Re: Language design by by committee ( was Re: Try J# ( was Re: J# is there ))

[Darren New]

Tim Tyler wrote:
> When some of the communications channels involved have to go onto
> the speech level, across to other individuals and back again, everything
> is slowed down, and garbled.

On the other hand, a language specification understood only by a lone
genius is not going to make for a very easy language to use. If you
can't communicate the design without it getting garbled, you need to do
a better job designing.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
                   Who is this Dr. Ibid anyway, 
                  and how does he know so much?

Re: "Size" of Ada vs. C++

[Richard Riehle]

Florian Weimer wrote:

> Anyway, I think it's rather strange to judge a language by the "size"
> of its definition.

Absolutely correct.  I have seen people compare languages based on the
number of reserved words (less is better),  the size of a "hello world"
program's executable (less is better),  the number of predefined libraries
(more is better),  the number of people who use it for programming (more
is better), the number of ads in the help wanted section (more is better),
and on and on and on.    There is no end to the silliness that people use
to compare programming languages.   The Modula-3 exercise that attempts
to define a language in some number of pages of the reference manual also
approaches absurdity.

A programming language needs to be judged on its expressiveness first.  One
factor in this judgement is, how well it expresses the software problems it
is intended to solve.  We could reframe this as, how well does the solution
space (represented by the language and its corresponding tools) map to
the problem space?   Another factor derives from Donald Knuth's notion of
"Literate Programming."   This notion suggests the question, how well
does the language support the human process of developing software?
There are other factors, but this margin is too small to enumerated them all.

In evaluating a programming language, we need to define qualitative
criteria as well as quantitative criteria.    Sadly, most of quantitative
criteria are flawed due to the immature reasoning that leads to their
selection.   Sadder still, such reasoning is likely to prevail for a very
long time, given the current state of software engineering practice.

Sorry for my pessimism.

Richard Riehle

Where is jean Ichibiah now ?

[Israel Raj T]

The answer is rather interesting:

http://www.pmn.co.uk/public/piloteerviii/views/21.htm
http://www.twsolutions.com/

Re: Where is jean Ichibiah now ?

[john]

In article <51kqst0gada6ub8r861a588bn8trobsti7@4ax.com>, Israel says...
>
>The answer is rather interesting:
>
>http://www.pmn.co.uk/public/piloteerviii/views/21.htm
>http://www.twsolutions.com/


I wonder if he is using Ada to program the palm with?

Re: Where is jean Ichibiah now ?

[Wes Groleau]

Israel Raj T wrote:
> 
> The answer is rather interesting:
> 
> http://www.pmn.co.uk/public/piloteerviii/views/21.htm
> http://www.twsolutions.com/

Does the following mean that Beaujolais is out of style?

http://www.twsolutions.com/domperignon/domperignon2.htm

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Where is jean Ichibiah now ?

[Israel Raj T]

On 17 Oct 2001 04:57:02 -0700, john@-- <john_member@newsguy.com>
wrote:

>I wonder if he is using Ada to program the palm with?

Codewarrior.

Re: Where is jean Ichibiah now ?

[JTK]

Wes Groleau wrote:
> 
> Israel Raj T wrote:
> >
> > The answer is rather interesting:
> >
> > http://www.pmn.co.uk/public/piloteerviii/views/21.htm
> > http://www.twsolutions.com/
> 
> Does the following mean that Beaujolais is out of style?
> 
> http://www.twsolutions.com/domperignon/domperignon2.htm
>

Pretty much.  Ripple's all the rage nowadays.

Re: Language design by by committee ( was Re: Try J# ( was Re: J# is there ))

[Richard Riehle]

Ted Dennison wrote:

> In article <dale-400CAE.17165114102001@mec2.bigpond.net.au>, Dale Stanbrough
> says...
> >
> >Israel Raj T wrote:
> >
> >> Tony Hoare was an early member of the design committee until he left
> >> in disgust. In his ACM Turing Award lecture "The Emperor's Old Clothes
> >> " he says just that.
> >
> >Tony Hoare left because he thought the language was way too big.
> >Later on he wrote a foreward to a book in which he recanted this
> >view, and hope people would have the opportunity to use Ada (I
> >think he said "this fine language", but I can't be sure).
>

In a book by David Watt, Brian Wichmann, and William Findlay titled
"Ada Language and Methodology" published in 1987 by Prentice-Hall,
C. Anthony R. Hoare writes, of Ada,

"... a new programming language: that it should be an aid in specification,
description, and design of programs, as well as in the construction of
reliable code.

"This was one of the main aims in the design of the language which was later
given the name Ada.  As a result, the language incorporates many excellent
structural features which have proved their value in many precursor
languages ...

"The combination of many complex features into a single language has led
to an unfortunate delay in availability of production-quality implementations.
But the long wait is coming to an end, and one can now look forward to
a rapid and widespread improvement in programming practice, both from
those who use the language and from those who study its concepts
and structures ... "

Note that these remarks were published long after the Turing Award Lecture.
However, even in that lecture, Mr. Hoare's criticisms were directed less at
the entire language and more at some specific features he felt were prone
to risky programming practice.  In particular, he was concerned about the
inclusion of exception handling in a language intended for safety-critical
software.  In his view, if a language included built-in exception handling,
programmers would be tempted to misuse it.  That is, instead of writing
robust code, they would too often rely on exception handling.

His concerns, it seems, were prophetic.  In the early days of Ada programming,
and even today, we see exception handling being misued.   This misuse
is not exclusive to Ada.   We too frequently see exceptions misused
in programs written in Java and C++.    Note that the SPARK Ada model
completely eschews the Ada exception handling model in favor of a more
rigorous assertion structure.  Dr. Chapman can probably elucidate on
that point, if anyone wants to know more about it.

Richard Riehle

Re: Language design by by committee ( was Re: Try J# ( was Re: J# is there ))

[mike]

 
>Dale Stanbrough <dale@cs.rmit.edu.au> wrote in message news:<dale- 
>> 
>> Tony Hoare left because he thought the language was way too big.
>> Later on he wrote a foreward to a book in which he recanted this
>> view, and hope people would have the opportunity to use Ada (I
>> think he said "this fine language", but I can't be sure).
>> 
>> Dale

FYI;

Prof Tony Hoare is now a member of the MicroSoft Research group for
programming principles and tools.
 
http://research.microsoft.com/ppt/

 
"Contact Information / Location

 
Nick Benton          Cambridge 
Luca Cardelli          Cambridge 
Cedric Fournet          Cambridge 
Andy Gordon          Cambridge 
Tony Hoare          Cambridge 
Andrew Kennedy    akenn        Cambridge 
Simon Marlow          Cambridge 
Simon Peyton Jones    simonpj        Cambridge 
Don Syme    dsyme        Cambridge "

Re: Language design by by committee ( was Re: Try J# ( was Re: J# is there ))

[David Thompson]

Ted Dennison <dennison@telepath.com> wrote :
...
> Interestingly, C++'s development between 1990 and its standarization in 1998
> *does* seem to have been performed by committe. Actually, not just by *a*
> committe, but by a group of committees. (Stroustrup referred to them in his
book
> as "the joint C++ standard committees").
>
Most of my books are presently inaccessible so I can't check
the ones I think you are likely referring to, but I would bet what
he was talking about was that the international subcommittee
ISO/IEC JTC1 SC22 WG21 and the ANSI subcommittee X3J16
worked very closely together, including meeting at the same times
and places (although AIUI legally they can't actually meet jointly),
to ensure that when the ISO standard was adopted it would be
immediately approved without objections as an ANSI standard.
The C committees WG14 and J11 have been doing the same.

And although "development" is a (perhaps deliberately) vague term,
my recollection of D&E (= The Design & Evolution of C++, one of
the inaccessible books) is that essentially all of the core language
features are standardized as BS designed them -- based partly on
feedback from early users -- except for a few template things.
The standards committees certainly developed the _document_,
and in the process cleaned up some previously ignored nooks
and crannies, but did not make any significant changes in the
language.  They did make some, but still relatively minor,
changes in the STL before incorporating it into the standard.

Whether this was for good or ill, I make no claim.

--
- David.Thompson 1 now at worldnet.att.net