jt> The subtle and arcane references to sub-sub-sub...sections of the
jt> C++ standard seem to have created a priesthood in the model of the
jt> ancient religions where arguments on how many angels could dance
jt> on the head of a pin provided endless hours of 'enjoyment'.

... or would if such arguments had ever in fact taken place.  But they
didn't.  See http://www.liv.ac.uk/Philosophy/angels.html and
http://www.straightdope.com/classics/a4_132.html for two debunkings of this
popular misconception.

jt> Isn't simplicity as an end in itself a reasonable goal for C++ in
jt> order not to keep programmers away in droves [?]

Standardising or designing a programming language is not a popularity
contest.  It is the creation of a tool to be used.  Simplicity is not an end
in itself when it comes to tool creation.  The tool may need to be complex in
order to perform the task it is designed to perform.

As for the unlikely notion of keeping programmers away in droves: The fact
that some craftsmen may be afraid of a complex tool is not necessarily a
measure of the inherent worth of that particular tool.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <8evn9a$4uq$1@nnrp1.deja.com>, AllanW <allan_w@my-deja.com>
writes
>The committee effect seems to apply to everything that passes
>through standardization, even good OO languages like C++. But
>the alternative -- well, how many products have you seen that
>bill themselves as "BASIC"? Believe me, porting between
>Microsoft C++ and Borland C++ is simple, compared to porting
>between two different brands of BASIC!

But there is an ISO Standard BASIC <g>

Francis Glassborow      Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

> >And even if they were to produce the specification in a precise language
> >like denotational semantics, there would undoubtedly be bugs.
>
> I could be completely wrong but I think that the overlap between those
> who can write/read DS and those who can design/develop/use a language
> like C++ is small.  Add in the requirement that somehow the process be
> financed and I suspect that would be vanishingly small.

i agree with the above, but i'd like to point out that DS might not
be the right vehicle for such a task. only with the advent of game
semantics
in the last few years, it has been possible to give convincing
denotational semantics to more than the most trivial of sequential
languages.
to give denotational semantics to really complex languages especially
when
concurrency is involved is beyond the state of the art.

fortunately, DS is not the only type of formal semantics: there is also
operational and axiomatic (logical) semantics. operational semantics
in particular should be accessible to any ambitious working programmer.

recently there has been a lot of work in formalizing (parts of)
java. some people have succeeded in showing that core java is type save,
using automatic theorem proving techniques.

i believe that things like proof-carrying code and typed assembly
language
are the next big step in programming languages and they require sound
formal semantics

martin

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <3916C42D.F05B629D@dcs.qmw.ac.uk>,
Martin Berger  <martinb--remove--me--@dcs.qmw.ac.uk> wrote:
>fortunately, DS is not the only type of formal semantics: there is also
>operational and axiomatic (logical) semantics. operational semantics
>in particular should be accessible to any ambitious working programmer.

And do you think that the complexity of specifying a language like C++ in
one of these notations would be significantly easier than DS?  I feel the
the complexity is inherent in the task, not really dependent on the
particular specification language.  I was only using DS in my message
because it was the only formal specification language I'm actually familiar
with (and that familiarity is only in passing).

--
Barry Margolin, barmar@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Barry Margolin wrote:

> > fortunately, DS is not the only type of formal semantics:
> > there is also operational and axiomatic (logical) semantics.
> > operational semantics in particular should be accessible to
> > any ambitious working programmer.

> And do you think that the complexity of specifying a language like
> C++ in one of these notations would be significantly easier than DS?
> I feel the the complexity is inherent in the task, not really
> dependent on the particular specification language.

there is no free lunch. in some way or other the complexity of modern
programming languages will be reflected in any formal specification,
for otherwise the specification would be inappropriate. nevertheless
one could ask what additional complexities any chosen specification
framework adds.  one could then distinguish between difficulty of
specifying the language and difficulty of reasoning about the
language.

wrt the former, operational semantics is a clear winner: the basic
idea behind operational semantics is no more complicated than, say,
finite state automata (see for example

 http://www.daimi.au.dk/~bra8130/Wiley_book/wiley.html

for an easy freely available tutorial); on the other hand,
denotational semantics uses sophisticated mathematical tools, category
theory, topology, lattics theory and game theory (accessible to
non mathematicians only when willing to do a lot of work ...), even
for sequential languages.

The situation is different for reasoning about languages. here
denotational semantics, because of its compositional character,
because it is more abstract, and because of its ties with established
and well studied mathematical fields, looks better: more reasoning
principles are known. reasoning about operational semantics is
currently mostly ad hoc. the results about java subsets were obtained
using theorem provers because theorems about operational semantics
tend to consist of very large numbers of (in itself easy) special
cases, so many in fact that humans tend to loose track

martin

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Ron Natalie schrieb:
> You're participating in a group whose purpose is to discuss and underta=
nd
> the minutae.  Such is the standards processes.  If you want to just dis=
cuss
> how to program in C++ try comp.lang.c++ or alt.comp.lang.earn.c-c++

not to forget comp.lang.c++.moderated!

 robert

--=20
Robert Klemme
Software Engineer
-------------------------------------------------------------
myview technologies GmbH & Co. KG
Riemekestra=DFe 160 ~ D-33106 Paderborn ~ Germany
E-Mail: mailto:robert.klemme@myview.de
Telefon: +49/5251/69090-321 ~ Fax: +49/5251/69090-399
-------------------------------------------------------------

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

jeffturneresq@my-deja.com writes:
> The subtle and arcane references to sub-sub-sub...sections of the C++
> standard seem to have created a priesthood in the model of the ancient
> religions where arguments on how many angels could dance on the head of
> a pin provided endless hours of 'enjoyment'.  Isn't there a way to
> simplify some of the minutia without compromising the overall language?

This is comp.std.c++, used by people involved in the standards process and
by compiler vendors to discuss precisely the subtle and arcane minutiae
of the language.  There are onlookers (like me) who monitor it out of interest
or because there is a (high, for me) chance that some interesting topic will
appear.

For people who want a simpler, more down to earth view, there are groups like
comp.lang.c++.moderated (which is still reasonably sane), and comp.lang.c++
(anything goes, and most questions seemed to be specific to one particular
compiler by one particularly notorious vendor the last time I looked at it).

Regards,
 Jens.
--
mailto:jjk@acm.org                 phone:+49-7031-464-7698 (HP TELNET 778-7698)
  http://www.bawue.de/~jjk/          fax:+49-7031-464-7351
PGP:       06 04 1C 35 7B DC 1F 26 As the air to a bird, or the sea to a fish,
0x555DA8B5 BB A2 F0 66 77 75 E1 08 so is contempt to the contemptible. [Blake]

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

 <jeffturneresq@my-deja.com> wrote:
+ The subtle and arcane references to sub-sub-sub...sections of the C++
+ standard seem to have created a priesthood in the model of the ancient
+ religions where arguments on how many angels could dance on the head of
+ a pin provided endless hours of 'enjoyment'.

Thus raising the question:  is this due to the inherent complexity of
{religion,C++} or to an imprecise standardization procedure?

In God We Trust; all others must submit an X.500 certificate.


+  Isn't there a way to
+ simplify some of the minutia without compromising the overall language?

Well... it's akin to the zero-overhead "you shouldn't have to pay for
what you don't use" argument that drives many of the C++ language design.
You shouldn't have to memorize what you don't need to be an expert in.
(Er, there went my English grammar.)

As a very simple example, I don't understand the ins and outs of Koenig
lookup.  I understand the starting points, and the results, but in between
is a big black box labeled "deep magic happens" -- and that's just fine
for me, since I don't expect to have to implement it anytime soon.  If ever.


+ Isn't simplicity as an end in itself a reasonable goal for C++ in order
+ not to keep programmers away in droves.

The complexity of C++ seems mostly due to two things which nobody can do
anything about:

  1)  Its history.  If we knew that we wanted to be where we are now, we
      could have gotten here a lot easier.  It's a process of discovery.

  2)  Its goals.  If a language is going to be used to closely model
      real-world phenomenea, it's debatable that such a language must be
      arbitrarily as complex as the world it's modelling.  The closer the
      model, the more complex it gets.

Yeah, I said it was "debatable;" I've seen lots of arguments for and against
that point.  I didn't take nearly enough courses in philosophy and logic to
follow any of those arguments.  I got a headache just writing this post.  :-)


Phil

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

> An even closer parallel might be legislators.
a kinder alternative, considering our overwhelming love for lawers, :)
max.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <8en454$7ll$1@dmapub.dma.org>,
Phil Edwards <pedwards@dmapub.dma.org> wrote:
>
> <jeffturneresq@my-deja.com> wrote:
>+ The subtle and arcane references to sub-sub-sub...sections of the C++
>+ standard seem to have created a priesthood in the model of the ancient
>+ religions where arguments on how many angels could dance on the head of
>+ a pin provided endless hours of 'enjoyment'.
>
>Thus raising the question:  is this due to the inherent complexity of
>{religion,C++} or to an imprecise standardization procedure?

I don't think it's possible to create a natural language specification for
a sophisticated language that doesn't have some abiguity.  Standardization
committee members are only human, human languages are notoriously
imprecise, and like any other product they have to eventually release their
work, even if they know it isn't 100% perfect.

And even if they were to produce the specification in a precise language
like denotational semantics, there would undoubtedly be bugs.  Denotational
semantics is basically a form of programming, but it's a language that
relatively few computer scientists or software engineers have much
expertise in (it's mostly used in academia, not the real world), so errors
in a DS for a large language like C++ are practically inevitable.

Basically, defining a programming language is a difficult task.  The
"language lawyering" analogy is quite apropos, since loopholes and
ambiguities in language specs are there for many of the same reasons as
they are in legislation.

--
Barry Margolin, barmar@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <tTiQ4.21$TM.611@burlma1-snr2>, Barry Margolin
<barmar@genuity.net> writes
>And even if they were to produce the specification in a precise language
>like denotational semantics, there would undoubtedly be bugs.

I could be completely wrong but I think that the overlap between those
who can write/read DS and those who can design/develop/use a language
like C++ is small.  Add in the requirement that somehow the process be
financed and I suspect that would be vanishingly small.

>

Francis Glassborow      Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Francis Glassborow wrote:

> I could be completely wrong but I think that the overlap between those
> who can write/read DS and those who can design/develop/use a language
> like C++ is small.  Add in the requirement that somehow the process be
> financed and I suspect that would be vanishingly small.

And by the time they were done, we would all be programming
in Design Pattern Oriented Microsoft Application Basic anyway :-)

--
Jack J. Woehr        # Ceterum censeo
PO Box 51, Golden, CO 80402   # in herbas belli
http://www.well.com/~jax/rcfb # ab idem desistamus.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Barry Margolin  <barmar@genuity.net> wrote:
+ In article <8en454$7ll$1@dmapub.dma.org>,
+ Phil Edwards <pedwards@dmapub.dma.org> wrote:
+ >
+ > <jeffturneresq@my-deja.com> wrote:
+ >+ The subtle and arcane references to sub-sub-sub...sections of the C++
+ >+ standard seem to have created a priesthood in the model of the ancient
+ >+ religions where arguments on how many angels could dance on the head of
+ >+ a pin provided endless hours of 'enjoyment'.
+ >
+ >Thus raising the question:  is this due to the inherent complexity of
+ >{religion,C++} or to an imprecise standardization procedure?
+
+ I don't think it's possible to create a natural language specification for
+ a sophisticated language that doesn't have some abiguity.  Standardization
+ committee members are only human, human languages are notoriously
+ imprecise, and like any other product they have to eventually release their
+ work, even if they know it isn't 100% perfect.

I think you and I are in violent agreement.  When I wrote that sentence I
failed to add, "or merely a combination of the two because that's just life."


+ Basically, defining a programming language is a difficult task.  The
+ "language lawyering" analogy is quite apropos, since loopholes and
+ ambiguities in language specs are there for many of the same reasons as
+ they are in legislation.

The problem being, of course, that accidental ambiguities are a source of
joy and large income to lawyers, whereas language designers view them as an
"oh, CRAP!" occasion.

Either way, they provide the "endless hours of enjoyment" the original
poster mentioned.  :-)


Phil

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <39130213.D50E60BE@ibm.net>,
  "Jack J. Woehr" <jwoehr@ibm.net> wrote:
> Francis Glassborow wrote:
>
> > I could be completely wrong but I think that the overlap
> > between those who can write/read DS and those who can
> > design/develop/use a language like C++ is small.  Add in
> > the requirement that somehow the process be
> > financed and I suspect that would be vanishingly small.
>
> And by the time they were done, we would all be programming
> in Design Pattern Oriented Microsoft Application Basic anyway :-)

Any idea where to download the ANSI DPOMAB public comment spec? :)

Q: What is a camel?
A: It's a horse, designed by committee.
The committee effect seems to apply to everything that passes
through standardization, even good OO languages like C++. But
the alternative -- well, how many products have you seen that
bill themselves as "BASIC"? Believe me, porting between
Microsoft C++ and Borland C++ is simple, compared to porting
between two different brands of BASIC!

--
Allan_W@my-deja.com is a "Spam Magnet," never read.
Please reply in newsgroups only, sorry.


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

The subtle and arcane references to sub-sub-sub...sections of the C++
standard seem to have created a priesthood in the model of the ancient
religions where arguments on how many angels could dance on the head of
a pin provided endless hours of 'enjoyment'.  Isn't there a way to
simplify some of the minutia without compromising the overall language?
Isn't simplicity as an end in itself a reasonable goal for C++ in order
not to keep programmers away in droves.

--Jeff
using std::disclaimers


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

jeffturneresq@my-deja.com writes:
> The subtle and arcane references to sub-sub-sub...sections of the C++
> standard seem to have created a priesthood in the model of the ancient
> religions where arguments on how many angels could dance on the head of
> a pin provided endless hours of 'enjoyment'.  Isn't there a way to
> simplify some of the minutia without compromising the overall language?
> Isn't simplicity as an end in itself a reasonable goal for C++ in order
> not to keep programmers away in droves.

Well, this thread has presented cases of overloaded functions declared
with very similar parameter types, and asked which would be called. We
have a standard with rules for this kind of thing, and we need to read
the rules carefully to understand what they mean. It should come as no
surprise that fine distinctions require close reading to disambiguate.

Waving your hands about and declaring that something simpler is needed
will not cause that simpler something to spring into existence. If you
have a proposal to make, make it, and we can evaluate its merits.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

jeffturneresq@my-deja.com wrote:
>
> The subtle and arcane references to sub-sub-sub...sections of the C++
> standard seem to have created a priesthood in the model of the ancient
> religions where arguments on how many angels could dance on the head of
> a pin provided endless hours of 'enjoyment'.  Isn't there a way to
> simplify some of the minutia without compromising the overall language?
> Isn't simplicity as an end in itself a reasonable goal for C++ in order
> not to keep programmers away in droves.

You're participating in a group whose purpose is to discuss and undertand
the minutae.  Such is the standards processes.  If you want to just discuss
how to program in C++ try comp.lang.c++ or alt.comp.lang.earn.c-c++

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On Wed, 3 May 2000 10:22:34 CST, Ron Natalie <ron@sensor.com> wrote:
>jeffturneresq@my-deja.com wrote:
>> The subtle and arcane references to sub-sub-sub...sections of the C++
>> standard seem to have created a priesthood in the model of the ancient
>> religions where arguments on how many angels could dance on the head of
>> a pin provided endless hours of 'enjoyment'.

I sympathize with this point of view, but a closer parallel would be to
compare us to lawyers. Don't forget that a formal standard is indeed a
legal document and must be written that way -- we even, only
half-jokingly, call those who can read/write standardese "language
lawyers." This is the newsgroup for the language lawyers, and many of
the participants are committee members; comp.lang.c++.moderated is a
good place for real-world programmers who use the language, although
some of that discussion gets pretty detailed too.

As another analogy, consider the different kinds of postings you'd
expect in: a) a newsgroup for automotive design engineers who discuss
differential equations describing the wind resistance of various shapes
of car bodies and the precise nature and timing of key chemical
reactions in a modern engine and how to design a car to crumple the
right way to minimize cockpit damage under specific impact conditions;
and b) a newsgroup for Ford minivan owners who discuss favorite factory
options and recommended maintenance schedules and the latest recall
notices to correct a defective ignition switch or something. This is a);
groups like comp.lang.c++.moderated are b).

>>  Isn't there a way to
>> simplify some of the minutia without compromising the overall language?
>> Isn't simplicity as an end in itself a reasonable goal for C++ in order
>> not to keep programmers away in droves.
>
>You're participating in a group whose purpose is to discuss and undertand
>the minutae.  Such is the standards processes.  If you want to just discuss
>how to program in C++ try comp.lang.c++ or alt.comp.lang.earn.c-c++

Ron summarizes it well, with a hilarious typo: I'm sure you can earn
lots of money as a C++ programmer, but I'm sure Ron meant the last URL
to be alt.comp.lang.learn.c-c++ :-)

Herb

---
Herb Sutter (mailto:hsutter@peerdirect.com)

CTO, PeerDirect Inc. (http://www.peerdirect.com)
Chair, ANSI SQL Part 12: SQL/Replication
Editor-in-Chief, C++ Report (http://www.creport.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]