Plauger resigned as convener?
georg...@gmail.com
software/rational/cafe/blogs/cpp-standard/2009/10/24/the-view-or-trip-
report-from-the-oct-2009-c-standard-meeting) insinuates Plauger
resigned due his opinions issues surrounding scope control of the next
standard.
Wong makes a troubling statement about the proposal: "But the problem
with that model of triage (which is often done in software industry),
is that we are all volunteers and you just can't easily make
volunteers do the hard thing, when they would rather do what they
like."
I would like to have the optimism that software professionals (even
volunteers) can do the "hard thing" rather than "what they like."
Anyone care to balance out Wong's point of view here, and perhaps give
some insight into what happened? :-)
--
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std...@netlab.cs.rpi.edu]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Steve Clamage
<georg...@gmail.com> wrote:
>This Santa Cruz update by Michael Wong ... insinuates Plauger
>resigned due his opinions issues surrounding scope control of the next
>standard.
>
>Wong makes a troubling statement about the proposal: "But the problem
>with that model of triage (which is often done in software industry),
>is that we are all volunteers and you just can't easily make
>volunteers do the hard thing, when they would rather do what they
>like."
>
>I would like to have the optimism that software professionals (even
>volunteers) can do the "hard thing" rather than "what they like."
Well, Bill Plauger can speak for himself if he chooses, but here is my
take:
The Convener has a responsibility to ISO to shepherd the standards
process through to completion on an agreed-upon schedule. The Convener
also has a responsibility to the committee to help create consensus.
Often a tension exists between these two responsibilities.
The scope of work undertaken for C++0X turned out to be rather
ambitious. Two extensions were sought and granted, the most recent was
promised to be the last such request. Bill pointed out to the
committee that no side tracks or back tracks could be permitted if we
were to make even the newly extended schedule, and no new topics could
be considered. We must make consistent significant forward progress
on existing incomplete issues..
Between meetings, and at the Santa Cruz meeting this past week, topics
that had been dropped were re-raised. Some people felt that the topics
had not been given a fair hearing, and some people said they would
have voted differently had the facts been more fully presented. Bill
did not want to allow the time to re-raise and re-discussed topics
that were closed. Some disagreed.
As noted by Michael Wong, what constitutes a "new issue" is also
subject to debate.
A manager of software projects often runs into the situation of
wanting a really nice feature or a bug fix in the upcoming release,
when the schedule won't permit it. Often, the schedule overrides all
other considerations. In such cases the manager directs the team to
stop working on the new feature or bug, and concentrate on finishing
the higher-priority items.
A volunteer committee like the C++ Committee doesn't have a boss who
can direct subordinates to work on or abandon specific issues.
Committee members are often quite passionate about issues, and don't
want to let them die unless they are decisively voted down. Some felt
the topics to be re-raised were not in fact decisively ruled out.
Managing a software project has famously been compared to herding
cats, a comparison that applies equally well to language standard
committees. One writer described the process as "getting a group of
highly intelligent and opinionated people to agree on trivia."
Bill felt he could not resolve the tension between what the committee
wanted to do and what he thought was necessary to complete the work on
time. A Convener can succeed only by persuasion, and he felt he had
failed in that regard.
That said, Bill is highly regarded by everyone on the committee. The
conflict involved only disagreements on how to proceed. But "how to
proceed" is what the Convener's job is all about, which is why Bill
felt he had to resign.
Steve Clamage
PL22.16 (C++) chair
Ville Voutilainen
wrote:
> This Santa Cruz update by Michael Wong (http://www-949.ibm.com/
> software/rational/cafe/blogs/cpp-standard/2009/10/24/the-view-or-trip-
> report-from-the-oct-2009-c-standard-meeting) insinuates Plauger
> resigned due his opinions issues surrounding scope control of the next
> standard.
> Wong makes a troubling statement about the proposal: "But the problem
> with that model of triage (which is often done in software industry),
> is that we are all volunteers and you just can't easily make
> volunteers do the hard thing, when they would rather do what they
> like."
> I would like to have the optimism that software professionals (even
> volunteers) can do the "hard thing" rather than "what they like."
> Anyone care to balance out Wong's point of view here, and perhaps give
> some insight into what happened? :-)
I'm not sure if I can "balance" out what Michael says, but PJ Plauger
quite
obviously would have liked the committee to completely stop handling
any
new ideas. I agree with Michael's blog entry in the sense that it's
pretty
difficult to separate new ideas from bugfixes that are "new" in the
sense
that their idea has not been proposed before. We have that exact
situation
with the latest proposal for handling exception safety for move
operations.
There's also the point that the Evolution Working Group is partly
there in
order to handle new ideas, even if those ideas may not end up
standardized
this time around. Mr. Plauger apparently felt that he has trouble
agreeing
with the majority of the community about the policy towards new ideas/
issues,
and felt that this disagreement makes it difficult (and I believe
stressful)
for him to represent WG21 in SC22. I respect his decision, and wish
him
all the best, and I urge people to not panic about the situation.
INCITS merely
needs to find a new convener, and that's about that. I believe the
plan is
still to have CD2 out after Pittsburgh.
Francis Glassborow
Yes, but Bill was trying to tell you that that plan will not work if
the Committee repeatedly revisits its decisions. He was also telling
you that SC22 would lose patience.
More to the point the C++ Community will lose patience if WG21
continues to delay release of a new standard. However this time it has
nothing to do with ISO/IEC procedures and everything to do with the
people making up the committee.
Finding a new convenor may not be that simple. It seems to me that
anyone who accepted the job would be accepting a poisoned cup.
georg...@gmail.com
Steve's reply.
I can only speculate on how difficult it would be to manage design-by-
committee, and I hope Mr. Plauger isn't offended by my question. :-)
It's been said a few times that the volume of work exceeds the
capacity of the WGs to address in time frames the user community
desires. Are the extensions a symptom of that problem?
Is there a way to address increasing resources in some way and are
there limitations with on-line (mailing list) collaborations that bog
down the committee meetings?
On Oct 26, 4:09 pm, Steve Clamage <stephen.clam...@sun.com> wrote:
> That said, Bill is highly regarded by everyone on the committee. The
> conflict involved only disagreements on how to proceed. But "how to
> proceed" is what the Convener's job is all about, which is why Bill
> felt he had to resign.
>
> Steve Clamage
> PL22.16 (C++) chair
>
> --
> [ comp.std.c++ is moderated. To submit articles, try just posting with ]
> [ your news-reader. If that fails, use mailto:std-...@netlab.cs.rpi.edu]
Steve Clamage
>It's been said a few times that the volume of work exceeds the
>capacity of the WGs to address in time frames the user community
>desires. Are the extensions a symptom of that problem?
Everyone has a favorite feature they would like to see in the new
standard, some big, some small. Many of the big new features planned
for C++0X were intended to make the language easier to teach, learn,
and use. It's (relatively) easy to propose a new feature and see how
to implement (most of) it. But we try to look for all the interactions
of a new feature, and address in the standard all the corner cases. It
takes time to do all that work. Once a feature looks complete, we let
it sit for one more meeting, so that unseen problems have a chance to
surface. During that time, those who work on implementing the complete
feature in a compiler or library usually discover new problems,
sometimes small, sometimes big.
I don't know of a way to make this process go faster without reducing
accuracy and reliability.
>
>Is there a way to address increasing resources in some way and are
>there limitations with on-line (mailing list) collaborations that bog
>down the committee meetings?
The committee mailing lists actually make the process go faster, given
that we can't meet every week or every month. But final resolution
pretty much requires getting people in a room together with a white
board to hash out details. In recent years, we have also had ad-hoc
sessions between official meetings, formed by people who have the time
to fit in two or three days to work out issues that don't require the
full committee to discuss.
---
Steve Clamage
georg...@gmail.com
> INCITS merely needs to find a new convener, and that's about that.
I hope that kind of cavalier attitude isn't ubiquitous within the
committee. The inability for the convener to maintain a consensus
towards the order of business is not simply a reflection of his or her
abilities, it also reflects on the group's abilities as a whole. The C+
+ user community has been waiting a very long time for updates, bug
fixes, and additions to the language, and while the 0x proposal is
exciting, it doesn't even come close to addressing all of the needs of
the language when compared to alternatives. There is a lot of work to
do, and delays and bad press will not help the community.
On Oct 26, 5:53 pm, Francis Glassborow
<francis.glassbo...@btinternet.com> wrote:
> More to the point the C++ Community will lose patience if WG21
> continues to delay release of a new standard. However this time it has
> nothing to do with ISO/IEC procedures and everything to do with the
> people making up the committee.
As a member of that community, I haven't lost patience yet, but I am
disappointed. The C++ language fills an almost-unique role of
providing high-level constructs with the ability to optimize close to
the hardware. But it often feels like I'm stuck in 1998, and if the
language continues to fail to progress, eventually a suitable
alternative will come along and replace it.
Steve Clamage
Ville Voutilainen wrote:
INCITS merely needs to find a new convener, and that's about that.
I hope that kind of cavalier attitude isn't ubiquitous within the
committee. The inability for the convener to maintain a consensus
towards the order of business is not simply a reflection of his or her
abilities, it also reflects on the group's abilities as a whole. The C+
+ user community has been waiting a very long time for updates, bug
fixes, and additions to the language, and while the 0x proposal is
exciting, it doesn't even come close to addressing all of the needs of
the language when compared to alternatives. There is a lot of work to
do, and delays and bad press will not help the community.
On Oct 26, 5:53 pm, Francis Glassborow
<francis.glassbo...@btinternet.com> wrote:
More to the point the C++ Community will lose patience if WG21
continues to delay release of a new standard. However this time it has
nothing to do with ISO/IEC procedures and everything to do with the
people making up the committee.
As a member of that community, I haven't lost patience yet, but I am
disappointed. The C++ language fills an almost-unique role of
providing high-level constructs with the ability to optimize close to
the hardware. But it often feels like I'm stuck in 1998, and if the
language continues to fail to progress, eventually a suitable
alternative will come along and replace it.
You know, it's easy to stand on the sidelines and complain that the
volunteers who do the actual work have not met your expectations.
If you don't like the pace of progress, become a member of the
committee (see the newsgroup FAQ, B6 and B7) and help.
---
Steve Clamage
Ville Voutilainen
wrote:
> Ville Voutilainen wrote:
> > INCITS merely needs to find a new convener, and that's about that.
> I hope that kind of cavalier attitude isn't ubiquitous within the
> committee.
It probably isn't. We are still on track to get CD2 out according to
our agreed
schedule, so please forgive me if I don't see the current situation as
doomed.
The situation will likely be doomed if there indeed is a big influx of
new features/ideas
but at least in Santa Cruz the work done by EWG seemed to go well. I
don't
know what LWG had on its plate, CWG seemed to be strictly in fixes-
only mode.
Maybe I have a too rosy picture of the situation, but at the moment I
don't see
anything huge coming in and causing delays. That's obviously just my
take on
things.
georg...@gmail.com
that the C++ Community will lose patience if progress isn't made. I
felt it necessary to speak as a member of that community, which I
love, and indicate that he has a very good point. I sometimes do feel
that way.
I apologize if that honesty made me seem ungrateful. I most certainly
am not.
Honestly, if you believe that having additional volunteers to work on
the committee will help the pace of work, then I actually would be
very interested in joining and making a contribution.
> You know, it's easy to stand on the sidelines and complain that the
> volunteers who do the actual work have not met your expectations.
>
> If you don't like the pace of progress, become a member of the
> committee (see the newsgroup FAQ, B6 and B7) and help.
--
Hyman Rosen
> I don't know of a way to make this process go faster without
> reducing accuracy and reliability.
It is believed by some that "given enough eyeballs, all bugs
are shallow". This is the internet age. I believe the standards
process would be improved by making what are now private internal
conversations public - a wiki, or some other form of web document
that interested people could look at and participate in.
The visceral response to this will be to reject it, of course.
The arguments will be that it will waste everyones time, be
disruptive, attract cranks, and accomplish nothing. This reaction
should be fought. When a major feature which has been developed
for years under the old system must be dropped until some
unspecified future version because it cannot yet be properly
specified, it is time to look for different ways of doing things.
Recall the EGCS fork of GCC, when the latter's development process
had grown untenable. Developed in public, with latest source always
available and mailing lists open to all, it quickly became the
canonical version, to the benefit of everyone, and eventually with
the happy agreement of the original GCC team.
georg...@gmail.com
I have found a few errors in documents just by reading what is posted
to the ISO C++ web site; mind you I think one was already fixed. :-) I
know from following this group that others like Scott Meyers has found
issues or raised discussions just by reading those proposals. I don't
know if that proves your point or not. In a sense, by having that site
and this group, we already have an informal open forum for
participation.
In a sibling thread, Mr. Clamage suggested for people to join the
committee and help out. I'd be more than happy to do that, however
there is a substantial financial investment there that is part of that
volunteer effort. But maybe there is some room for people to more
formally help the effort without having to join the committee itself
by calling for non-member participation in some manner - without
having a completely open forum for random people to rant in. I don't
know what the ISO rules allow.
> It is believed by some that "given enough eyeballs, all bugs
> are shallow". This is the internet age. I believe the standards
> process would be improved by making what are now private internal
> conversations public - a wiki, or some other form of web document
> that interested people could look at and participate in.
>
> The visceral response to this will be to reject it, of course.
> The arguments will be that it will waste everyones time, be
> disruptive, attract cranks, and accomplish nothing. This reaction
> should be fought. When a major feature which has been developed
> for years under the old system must be dropped until some
> unspecified future version because it cannot yet be properly
> specified, it is time to look for different ways of doing things.
--
James Kanze
> Steve Clamage wrote:
> > I don't know of a way to make this process go faster
> > without reducing accuracy and reliability.
> It is believed by some that "given enough eyeballs, all bugs
> are shallow".
I don't think that there's any real evidence for that. The
quality of the eyeballs counts as well, as does the intention
behind them.
> This is the internet age. I believe the standards process
> would be improved by making what are now private internal
> conversations public - a wiki, or some other form of web
> document that interested people could look at and participate
> in.
> The visceral response to this will be to reject it, of course.
> The arguments will be that it will waste everyones time, be
> disruptive, attract cranks, and accomplish nothing. This
> reaction should be fought. When a major feature which has been
> developed for years under the old system must be dropped until
> some unspecified future version because it cannot yet be
> properly specified, it is time to look for different ways of
> doing things.
Perhaps, but in that case, I'd suggest the opposite approach.
From what I've seen, most of the problems are due to too many
divergent approaches, with the standard trying to adopt them
all. IMHO, the best approach would be for a (very) small group
of extremely capable individuals to go off and do the work, then
integrate it, without considering alternative approaches (unless
there is some serious error in their results, which can't easily
be fixed).
> Recall the EGCS fork of GCC, when the latter's development
> process had grown untenable. Developed in public, with latest
> source always available and mailing lists open to all, it
> quickly became the canonical version, to the benefit of
> everyone, and eventually with the happy agreement of the
> original GCC team.
That's not quite the way I experienced it. EGCS was generally
unusable in an industrial environment, because it was changing
too fast, and g++ didn't really become an acceptable alternative
until EGCS died (and the version of the day was replaced by
something more stable).
--
James Kanze
Hyman Rosen
> On Oct 28, 5:07 pm, Hyman Rosen <hyro...@mail.com> wrote:
>> It is believed by some that "given enough eyeballs, all bugs
>> are shallow".
>
> I don't think that there's any real evidence for that. The
> quality of the eyeballs counts as well, as does the intention
> behind them.
But there will not be fewer "eyeballs" if the project is
public than if it is private.
> IMHO, the best approach would be for a (very) small group
> of extremely capable individuals to go off and do the work, then
> integrate it, without considering alternative approaches (unless
> there is some serious error in their results, which can't easily
> be fixed).
That's a good idea for language design ab initio. The Ada
programming language was designed this way, by Jean Ichbiah
and his team. Unfortunately, the sprawling "programming by
example" design of C++ means that most of the problems with
new features are in their interaction with existing portions
of the language. Hence modifying C++ is more like debugging
than programming, and having many eyes will help.
(What's "programming by example"? It's my belief that a lot
of C++ design came about through people saying "if I write
this, it should do that" and then coming up with enough
Standardese to hammer it into submission, instead of starting
with a clean design.)
Hyman Rosen
> That's not quite the way I experienced it. EGCS was generally
> unusable in an industrial environment, because it was changing
> too fast, and g++ didn't really become an acceptable alternative
> until EGCS died (and the version of the day was replaced by
> something more stable).
That's not how Wikipedia remembers it:
<http://en.wikipedia.org/wiki/Egcs#EGCS>
In 1997, a group of developers formed EGCS (Experimental/
Enhanced GNU Compiler System), to merge several
experimental forks into a single project. The basis of the
merger was a GCC development snapshot taken between the 2.7
and 2.81 releases. Projects merged included g77 (Fortran),
PGCC (Pentium-optimized GCC), many C++ improvements, and
many new architectures and operating system variants.
EGCS development proved considerably more vigorous than GCC
development, so much so that the FSF officially halted
development on their GCC 2.x compiler, "blessed" EGCS as the
official version of GCC and appointed the EGCS project as the
GCC maintainers in April 1999. Furthermore, the project
explicitly adopted the "bazaar" model over the "cathedral"
model. With the release of GCC 2.95 in July 1999, the two
projects were once again united.
James Kanze
> James Kanze wrote:
> > That's not quite the way I experienced it. EGCS was
> > generally unusable in an industrial environment, because it
> > was changing too fast, and g++ didn't really become an
> > acceptable alternative until EGCS died (and the version of
> > the day was replaced by something more stable).
> That's not how Wikipedia remembers it:
I'm not sure that the Wikipedia is a reference, however...
> <http://en.wikipedia.org/wiki/Egcs#EGCS>
> In 1997, a group of developers formed EGCS (Experimental/
> Enhanced GNU Compiler System), to merge several
> experimental forks into a single project. The basis of the
> merger was a GCC development snapshot taken between the 2.7
> and 2.81 releases. Projects merged included g77 (Fortran),
> PGCC (Pentium-optimized GCC), many C++ improvements, and
> many new architectures and operating system variants.
> EGCS development proved considerably more vigorous than GCC
> development, so much so that the FSF officially halted
> development on their GCC 2.x compiler, "blessed" EGCS as the
> official version of GCC and appointed the EGCS project as the
> GCC maintainers in April 1999. Furthermore, the project
> explicitly adopted the "bazaar" model over the "cathedral"
> model. With the release of GCC 2.95 in July 1999, the two
> projects were once again united.
Which doesn't really contradict what I said. It just leaves out
a few details, like the fact that in production work, you don't
want a compiler whose development is "vigorous"; you want one
which is stable, and not changing. All of the places I know
stuck with g++ 2.7 something through the entire EGCS debacle,
only updating with 2.95.2. Similarly, most stayed with 2.95.2
until 3.2 something, or beyond.
--
James Kanze
georg...@gmail.com
on consensus?
On Oct 29, 6:26 pm, James Kanze <james.ka...@gmail.com> wrote:
> all. IMHO, the best approach would be for a (very) small group
> of extremely capable individuals to go off and do the work, then
> integrate it, without considering alternative approaches (unless
> there is some serious error in their results, which can't easily
> be fixed).
Ken Penpal
>
> Perhaps, but in that case, I'd suggest the opposite approach.
> From what I've seen, most of the problems are due to too many
> divergent approaches, with the standard trying to adopt them
> all. IMHO, the best approach would be for a (very) small group
> of extremely capable individuals to go off and do the work, then
> integrate it, without considering alternative approaches (unless
> there is some serious error in their results, which can't easily
> be fixed).
>
Could an approach similar to the one used by the Boost project be used
instead?
Even if only a select few C++ geniuses were allowed to do the core
work or to decide on the core issues, the entire work could still be
open to the general public from the beginning. Among others, the
mailing list archives and all the communications could be completely
open.
The decision to remove concepts from C++0x has taken the C++ community
by surprise. When the decision to remove concepts from C++0x was
announced, very many C++ programmers who had been eagerly awaiting C+
+0x were in a state of utter disbelief or shock.
Bjarne Stroustrup states in this recent interview
http://www.devx.com/cplus/Article/42448/1954?pf=true :
"The reason we don't already have something like concepts, is that in
1988 I did not know a solution that gave flexibility/generality,
performance, and good early checking. As far as I know, nobody else
knew either. I chose flexibility/generality and performance at the
cost of delayed checking and appalling error messages."
Perhaps more openness could actually help the C++ evolution work a
great deal.
Ken
Ville Voutilainen
wrote:
> It's been said a few times that the volume of work exceeds the
> capacity of the WGs to address in time frames the user community
> desires. Are the extensions a symptom of that problem?
> Is there a way to address increasing resources in some way and are
> there limitations with on-line (mailing list) collaborations that bog
> down the committee meetings?
I believe some steps have already been taken to improve the issue
handling
throughput. The LWG has had unofficial mid-term meetings for issue
handling,
and the CWG has done teleconferences. Both of these seem to have a
positive
impact.
About participating in the work without joining the committee, I think
it's possible
to join the mailing list(s) and help with issue processing via them,
there are plenty
of people who help that way without attending the meetings. Thus it's
possible
to help without substantial financial investment.
About the many-eyeballs, please also remember that even though the
mailing lists
are not completely open to the public, WG21 is relatively open, all
papers are available
to anyone. I have been told that many standards working groups are
much more closed.
To conclude, I'm not saying that WG21 does a perfect job. There's room
for improvement,
but some steps towards such improvement have already been taken.
Florian Weimer
> Steve Clamage wrote:
> > I don't know of a way to make this process go faster without
> > reducing accuracy and reliability.
>
> It is believed by some that "given enough eyeballs, all bugs
> are shallow". This is the internet age. I believe the standards
> process would be improved by making what are now private internal
> conversations public - a wiki, or some other form of web document
> that interested people could look at and participate in.
Isn't it a bit worse than that? I think all ISO editing decisions
require physical presence by the participants (certainly that's true
for other JTC1 standardization activities). This means that quite a
bit of time and money is spent on traveling, which is especially a
problem when corporate budgets tighten.
On the other hand, the rather rigid ISO framework seems the most
important factor that gives direction to the standardization framework
right now.
Hyman Rosen
All of the places I know stuck with g++ 2.7 something through
> the entire EGCS debacle, only updating with 2.95.2. Similarly,
> most stayed with 2.95.2 until 3.2 something, or beyond.
There is no reason for characterizing the EGCS fork as a debacle.
On the contrary, your statement above demonstrates that there was
no useful new release from the old GCC maintainers at all, until
EGCS became the official version.
> It just leaves out a few details, like the fact that in
> production work, you don't want a compiler whose development
> is "vigorous"; you want one which is stable, and not changing.
But you also want a compiler which is able to compile the
programming language you choose to use, not a poorly-defined
subset of it. People who wanted that were royally fed up with
the glacial lack of progress from the GCC developers, and took
matters into their own hands, successfully.
Whether or not to use EGCS for production work would have depended
on how important its newly developed features were as compared to
its lack of stability. That's a decision to be made case by case.
I happen to know from reading your many posts that you value
stability very highly and program very conservatively, but I
think you're projecting what you value onto others who do not
feel that way.
Francis Glassborow
> On Oct 27, 2:15 am, "george.r...@gmail.com" <george.r...@gmail.com>
> wrote:
>> It's been said a few times that the volume of work exceeds the
>> capacity of the WGs to address in time frames the user community
>> desires. Are the extensions a symptom of that problem?
>> Is there a way to address increasing resources in some way and are
>> there limitations with on-line (mailing list) collaborations that bog
>> down the committee meetings?
>
> I believe some steps have already been taken to improve the issue
> handling
> throughput. The LWG has had unofficial mid-term meetings for issue
> handling,
> and the CWG has done teleconferences. Both of these seem to have a
> positive
> impact.
>
True but three six day meetings a year + other meetings in between the
official ones is beginning to strain the personal resources of many
participants. And even those fully supported by their employers may find
that those are less enthusiastic when the time spent away from paid work
is approaching 30 days a year (and that does not count the time spent
reading and writing papers and generally keeping up to date.)
Hyman Rosen
> I think all ISO editing decisions require physical presence by the
> participants
The actual text could still be decided upon in a collaborative
web environment, and then adopted by the meeting attendees.
georg...@gmail.com
Would it be overly naive to assume that if we put a donation link on
the ISO C++ site that it would result in any worthwhile contributions
to help compensate volunteers?
On Oct 30, 10:22 pm, Francis Glassborow
Joe Smith
"Ville Voutilainen" <ville.vo...@gmail.com> wrote in message
news:89839fb3-db10-4234...@a21g2000yqc.googlegroups.com...
This has always been one of my larger complaints about most standards
organizations. Things tend to default to closed, and are made open only if
required. IIRC, it is a WG22 mandate that the working papers be open,
otherwise they probably would be closed. Not that that would be the fault of
the comittee. I blame the standards organizations themselves for this.
The ISO, IEC, and IEEE, have a default-closed policy as far as I can tell,
most likely because the final document is closed.
The W3C has a mixture of open and closed, with working groups apparently
strongly encourage to conduct as much in public as the rules permit,
although some stuff is private. Never the less, most mailing lists on which
development occurs is not only publicly readable, but publicly writable as
well.
IETF working groups are 100% open. It looks as though they don't even keep
member lists, just assignments for specific positions like chair.
Sometimes I think the more open models are better, but it is hard to argue
with the fact that being too open may just slow things down, especially at
certain stages in the process. Somebody coming along and suggesting some new
major change to the language would not be helping at all right now, for
example.
James Kanze
wrote:
> On Oct 29, 6:26 pm, James Kanze <james.ka...@gmail.com> wrote:
> > all. IMHO, the best approach would be for a (very) small group
> > of extremely capable individuals to go off and do the work, then
> > integrate it, without considering alternative approaches (unless
> > there is some serious error in their results, which can't easily
> > be fixed).
> Isn't that opposed to the ISO concept of developing a standard
> based on consensus?
In some ways. But the consensus that is required really only
concerns the final product. Public approval is necessary, but
you don't want a case of too many cooks spoiling the broth---the
public's role should be more or less one of deciding up front
what should go into the soup, and then tasting the results, but
leaving the actual cooking and preparation to the expert chefs.
--
James Kanze
James Kanze
> James Kanze wrote:
> > All of the places I know stuck with g++ 2.7 something
> > through the entire EGCS debacle, only updating with 2.95.2.
> > Similarly, most stayed with 2.95.2 until 3.2 something, or
> > beyond.
> There is no reason for characterizing the EGCS fork as a debacle.
I'm afraid my wording wasn't very clear. The fork itself wasn't
a debacle, and of course, much of 2.95.2 stems from work which
was done in it. The way it was managed, with new versions
almost every day, was a debacle, however, and pretty much meant
that it couldn't be used in any serious development.
> On the contrary, your statement above demonstrates that there
> was no useful new release from the old GCC maintainers at all,
> until EGCS became the official version.
The fact that there was no serious maintenance on gcc was a
problem, albeit not as bit a one as might be imagined; the C
compiler was already pretty good, and the C++ compiler was
usable, provided you avoided the more complicated cases.
> > It just leaves out a few details, like the fact that in
> > production work, you don't want a compiler whose development
> > is "vigorous"; you want one which is stable, and not
> > changing.
> But you also want a compiler which is able to compile the
> programming language you choose to use, not a poorly-defined
> subset of it.
A compiler which compiles it one way one day, and another way
another day, is worse than no compiler.
> People who wanted that were royally fed up with the glacial
> lack of progress from the GCC developers, and took matters
> into their own hands, successfully.
> Whether or not to use EGCS for production work would have
> depended on how important its newly developed features were as
> compared to its lack of stability. That's a decision to be
> made case by case.
> I happen to know from reading your many posts that you value
> stability very highly and program very conservatively, but I
> think you're projecting what you value onto others who do not
> feel that way.
EGCS represents a radical extreme with regards to instability.
I know that there are compromizes to be made, but almost
regardless of the application, the extremes are to be avoided.
There are certainly exceptions for some critical applications,
where extreme stability is required, and I suppose that the
opposite extreme could be justified in an experimental
laboratory in a university---and is obviously necessary within
the compiler development group, if any progress is to be made.
The problem with EGCS wasn't that they were developing too fast;
it was that they were making too many intermediate steps open
and available, without distinguishing what was really
experimental, and what was stable.
--
James Kanze
James Kanze
> James Kanze wrote:
> > Perhaps, but in that case, I'd suggest the opposite
> > approach. From what I've seen, most of the problems are due
> > to too many divergent approaches, with the standard trying
> > to adopt them all. IMHO, the best approach would be for a
> > (very) small group of extremely capable individuals to go
> > off and do the work, then integrate it, without considering
> > alternative approaches (unless there is some serious error
> > in their results, which can't easily be fixed).
> Could an approach similar to the one used by the Boost project
> be used instead?
Perhaps. It certainly seems to work for Boost.
> Even if only a select few C++ geniuses were allowed to do the
> core work or to decide on the core issues, the entire work
> could still be open to the general public from the beginning.
> Among others, the mailing list archives and all the
> communications could be completely open.
I think that wide participation is a good thing at both ends:
what features are needed, and then a final review of their
implementation and integration. Where I think things are
blocking is in the middle, when all of the details are getting
worked out.
--
James Kanze
georg...@gmail.com
> On Oct 30, 6:32 pm, Ken Penpal <penpal....@googlemail.com> wrote:
> > Could an approach similar to the one used by the Boost project
> > be used instead?
>
> Perhaps. It certainly seems to work for Boost.
However the Boost process doesn't have the added burden of being a
formal part of the language, and as such doesn't effect the public's
impression of, or dependence on, the C++ standard itself (I hope). I
can always opt not to use a Boost library for reasons of design,
however I would expect features that are formally in the language to
be more top-notch. Boost can always replace libraries with better
versions if necessary in a manner that is much easier and has less
repercussions than for the standard.
Hyman Rosen
> I would expect features that are formally in the language to
> be more top-notch.
If the standardization process were more public, there would
still be the same small number of core people doing all the
work. That wouldn't change. What would change is that problems
would come to light more quickly.
Richard Corden
> georg...@gmail.com wrote:
>> I would expect features that are formally in the language to
>> be more top-notch.
>
> If the standardization process were more public, there would
> still be the same small number of core people doing all the
> work. That wouldn't change. What would change is that problems
> would come to light more quickly.
What part of the current process do you feel should be made public exactly?
As Ville Voutilainen pointed out in a previous post there are many ways
to contribute to the standardisation process without actually attending
meetings.
At the outer level, you have this and other newsgroups. There are often
mails to the main reflectors with the following:
"After a discussion on comp.std.c++..." or "After a discussion on
comp.lang.c++.moderated...".
So, if you think you have found a problem with a paper or the current
draft and this is confirmed here then that will be seen by the members
of the committee.
The second point is that the majority of work completed by the committee
is public. Changes to the standard require a paper, and from what I
have seen these papers are publicly available.
And of course, you have the public draft standard which you can also review.
Regards,
Richard
Hyman Rosen
> What part of the current process do you feel should be made public exactly?
Discussions. You can get some feel for what's going on by
looking at the mailings, e.g.,
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/#mailing2009-09>,
but look at this in a paper by Stroustrup and Crowl:
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2953.html#Introduction>
Paper N2904 examined the generation of default copy
and move operations when elements are combined into
an aggregate. The proposal was discussed extensively
in the July 2009 meeting, and several changes were
suggested at that meeting. In addition, several changes
surfaced in analysis after the meeting.
The cycle of "think hard, write a paper, discuss at the next
meeting, fix, repeat" would benefit from some kind of public
discussion board. First, feedback would come more quickly,
and second, preserving the discussion makes it available to
inform others.
georg...@gmail.com
> The cycle of "think hard, write a paper, discuss at the next
> meeting, fix, repeat" would benefit from some kind of public
> discussion board. First, feedback would come more quickly,
> and second, preserving the discussion makes it available to
> inform others.
Good idea in theory, but the risk is that the practice of typing all
of the discussions into a forum takes longer to do than any benefit
gained from having every thought public. It's much quicker for those
involved to have a group discussion in person than it is to type out
long essays to each other.
Hyman Rosen
> typing all of the discussions into a forum
You're missing the point. With a properly set up system,
the discussions would happen continually on line.