Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!nrl-cmf!ukma!rutgers!bellcore!faline!thumper!ulysses!andante!alice!bs
From: bs@alice.UUCP (Bjarne Stroustrup)
Newsgroups: comp.lang.c++
Subject: Re: Standards For C++
Keywords: standards growthrate
Message-ID: <8219@alice.UUCP>
Date: 20 Sep 88 01:40:59 GMT
References: <255@itivax.UUCP>
Distribution: na
Organization: AT&T Bell Laboratories, Murray Hill NJ
Lines: 135



Steve C. Simmons from the Industrial Technology Institute,
Ann Arbor writes

 > From the first "release" of C outside of Bell Labs to the
 > first commercial C compiler was years.  From the first release
 > of C++ to the first commercial compiler was a much shorter
 > period.

 > C++ is going through a much faster "public acceptance" path
 > than C did.  In fact, it's faster than any language I can
 > think of except maybe pascal.

Yes, that is both nice and scary.

 > One of the major problems with Pascal was dialectization (sp?).
 > Everybody had their own features to make up for lacks (whether
 > real or perceived) and everybody did it differently.  This lone
 > fact probably did more to stunt Pascal as a portable language
 > than anything else.

I am among the ones who think that the main reason for the fragmentation
of Pascal was that extensions were needed, but that nobody took it
upon themselves to provide ways for needed extensions to find their
way into a common language. Until it was too late, too many pretended
either that Pascal was perfect or that Pascal was only an educational
tool anyway. I don't think we need to worry about those fallacies in
the context of C++, but we do need to worry about how we can evolve
without language fragmentation. Attempting to freeze the language,
say, at the level described in my book would almost certainly guarantee
that we will suffer the problems of Pascal to the worst degree.

 > The same process has already started with C++.  There are ads
 > for C++ compilers (well, one) with parameterized types, a feature
 > not (yet) in cfront or g++.

Ads for a C++ with parameterized types? I haven't seen them. There has
been much talk, a little writing, and a few experiments, but I haven't
seen an extended C++ for sale.

 > Zortech is apparently selling like crazy.
 > Library packages are springing up all over the place,
 > each with it's own set of compiler dependancies.

Nice, Nice, and Bad.

 > We need to start thinking seriously about standardization.  "But
 > the language isn't complete" you cry?  True, but only to a limited
 > degree.  "But it'll stifle innovation" you say?  What's more
 > important, innovation or code reusability?  [[hey, cool down.  i'm
 > kicking straw men here.]]

I happen to agree. As a matter of fact some of us started doing things
many months ago. The drift of things and the needs of the users in this
respect were made quite clear at the C++ ``workshop'' in Santa Fe.

The first step, a much more detailed and specific manual, has been in the
works for months. This is needed independently of what further features
are needed in the language. Such a manual revision does not necessarily
stifel innovation. As a matter of fact I consider it essential for
further growth. Unless the basic language features are well defined
in a way that people can understand and agree on, further progress is
irrellevant.

The work of the ANSI C committee alone makes a revision necessary. 

The language does not yet measure up to where I think it ought to be,
but given the 2.0 features (mostly described in quite some detail already)
the major ``missing'' parts are parameterized types and (probably) exception
handling (this too is no secret either: I have been telling people for years
that this is the way I would like C++ to evolve and my views here reflect
those of quite a number of users). Fortunately, these improvements can be
done as compatible extensions. Much more about that at the C++ conference
in Denver.

And no, I am not under the illusion that I can complete such a revision
of the C++ reference manual single handed, but we must avoid the multi-year
delay that a formal standadization implies. I hope to produce a revised
and rather extensively reviewed manual in half a year or so. That ought
to give us sufficient stability for formal proceedings to take their
necessary time. We don't just need time for formal proceedings, but also
to gain experience as C++ programmers (as opposed to experience as C,
Pascal, Modula2, Ada, etc. programmers).

 > C managed to live for so long without a standard because there
 > was a de-facto one in K&R.  This is not true of C++ *because* of
 > Stroustrup -- he's being very flexible.

Hmmm. I feel tempted to argue about that, but maybe I ought to keep out
of this particular discussion.

 > It's time to start talking about a standards effort.  Starting
 > the discussion today means it will be one to two years before
 > we have a real committee, and one to two years before we have a
 > standard.  Figure three years from now *at best*.  Starting today
 > is not too soon; starting today will not unreasonably stifle
 > the innovation that is under way and will wrap up in the next
 > two years.

Again. I agree fully. We need work on at least three fronts:

	(1) Language definition and direction of extensions.
	(2) ``Simple'' urgent things such as header file layout,
		file suffixes, and the most basic libraries.
	(3) more ambitious libraries and programming environments.

	I'm trying to do something about (1) with the help of (hopefully
	all of) the purveyers of C++ compilers and tools and some
	experienced users.

	The purveyers of C++ compilers and tools ought to get together
	with some experienced users to solve (2). There are immediate
	problems that are amenable to immediate solutions given cooperation.
	I think the will is there. What we need is a time and a place;
	maybe we can come up with a suggestion for that at the C++
	conference in Denver.

	(3) is too open ended to allow specific solutions. For starters,
	we can start looking for a good forum for such discussions at
	the conference in Denver.

 > I will now go and don my asbestos suit!  :-)

Really? This isn't comp.lang.c. We are usually more polite here.

Thanks for bringing up a serious and really tricky problem.
Hope to see you in Denver!

	- Bjarne
-- 
 > Steve Simmons		...!umix!itivax!vax3!scs
 > Industrial Technology Institute, Ann Arbor, MI.
 > "You can't get here from here."