Project Coin: Solidarity with C++ Evolution

Recently I read with interest Bjarne Stroustrup's HOPL III paper Evolving a language in and for the real world: C++ 1991-2006. Despite the numerous technical differences between Java and C++, I was struck by some of the similarities in community involvement and expectations in the evolution of both languages. Selected excerpts from the paper are in block quotes below.

In particular, this very open process [in the C++ committee] is vulnerable to disruption by individuals whose technical or personal level of maturity doesn’t encourage them to understand or respect the views of others. Part of the consideration of a proposal is a process of education of the committee members. Some members have claimed — only partly in jest — that they attend to get that education.

The Project Coin mailing list is a world-readable and world-writable list. While this approach does let anyone join in, the traffic can be very high and at times the signal to noise ratio was quite low. In the future, I'll be inclined to impose temporary moderation on the list to quell unproductive email storms.

The answer to “Why didn’t we provide a much more useful library?” is simpler: We didn’t have the resources (time and people) to do significantly more than we did.

The most common reaction to these extensions among developers is “that was about time; why did it take you so long?” and “I want much more right now”. That’s understandable (I too want much more right now — I just know that I can’t get it), but such statements reflect a lack of understanding what an ISO committee is and can do.

As ever, there are far more proposals than the committee could handle or the language could absorb. As ever, even accepting all the good proposals is infeasible. As ever, there seems to be as many people claiming that the committee is spoiling the language by gratuitous complicated features as there are people who complain that the committee is killing the language by refusing to accept essential features. If you take away consistent overstatement of arguments, both sides have a fair degree of reason behind them. The balancing act facing the committee is distinctly nontrivial.

Viewed over the long term, one goal to evolving a platform is trying maximize value delivered over time. This is analogous to a net present value-style consideration from economics. A feature delivered in the future is less valuable than having the feature today, but the value of choosing to do a feature needs to be weighed against the opportunity costs of doing something else instead. Developers are chronically optimistic and eager to deliver something sooner rather than later, especially when the next release vehicle may be in the relatively distant future. As previously indicated, I too would prefer to see additional language changes as part of Project Coin in JDK 7. However, given the available resources, overcommitting to a large set of features is not responsible; either the large set won't get done in the end, it won't get done well, or the schedule would slip — all of which lead to reduced value too.

Much of the best standards work is invisible to the average programmer and appears quite esoteric and often boring when presented. The reason is that a lot of effort is expended in finding ways of expressing clearly and completely “what everyone already knows, but just happens not to be spelled out in the manual” and in resolving obscure issues that—at least in theory—don’t affect most programmers. The maintenance is mostly such “boring and esoteric” issues.

Some attendees of my JavaOne talk this year were not happy with the length of time spent relating complications with adding enum types in JDK 5. However, I included such a large section on the apparent simplicity of enums still leading to many surprising complexities to help convey the disproportionate efforts that adding even modest features to the language can take.

I fully expect to be surprised in the future with novel interactions and issues as experience is gained with the Project Coin features and prudent planning anticipates the need to deal with such surprises.


Although now a pretty regular critic of the Java language, Bruce Eckel has an interesting perspective on working with the C++ committee over on Artima:

Posted by Patrick Wright on September 04, 2009 at 07:40 PM PDT #

C++ failed in trying to do up-front overloading of keywords for different semantics. Java is a little better, though it can still be frustrating explaining "final" to someone new to Java.

So with this in mind, how come context-sensitivity is not employed more than it is when evolving the language? We've all heard Joshua Bloch's tale over the trouble of introducing "assert" which appears to stand as a reminded that keywords can't be introduced. Was/is context-sensitivity (>1 token look-ahead) ruled out in Coin?

Trying to come up with an analogy here that none experts (me) can relate to in a practical fashion. The best I arrived at is how, when writing unit tests, it's not about making the test pass but about how to make it fall. Only when you have shot enough bullets at it from a sufficiently diverse number of trajectories, can you assert non-failure.

Posted by Casper Bang on September 05, 2009 at 01:23 AM PDT #


As stated on the coin-dev list, new keywords were off the table for JDK 7. The modularity language changes being done in JSR 294 are using "module" as a restricted keyword, that is, a context sensitive one. In particular, "module" can still be used as the name of a class, or a field, etc.

Such restricted keywords were also allowable in the Project Coin design space.

Posted by Joe Darcy on September 05, 2009 at 04:15 AM PDT #


Yes, I saw Bruce's article when it first came out earlier this year. I disagree with much of his analysis, but I will just comment a bit on the different standardization processes. While well-considered, the ANSI process is also quite slow; the last full C++ standard is from 1998 with an amendment adopted in 2003. The next full standard is now expected to be ready for voting in 2010. JDK 1.2 shipped in 1998 and Java has enjoyed regular updates to the platform libraries if not the language every few years since then.

As a standardization process, the JCP requires the triple of a specification, a reference implementation, and a test suite before the project can be considered complete. I think the latter two are extremely important. Having to produce a reference implementation at the same time as the specification gives an existence proof that the specification can be implemented and the tests ensure some level of quality and consistency is always present.

Posted by Joe Darcy on September 05, 2009 at 04:57 AM PDT #

For all those who think that the Java language should have the latest feature that every other programming language has to offer, here is a quote that is attributed (correctly?) to Dennis Ritchie:

"A language that doesn't have everything is actually easier to program in than some that do."

Posted by Bharath R on September 07, 2009 at 06:34 PM PDT #

@Bharath: With all due respect, that quote means little in the real world and out of context. It also happens to be from a time where software was quite a bit simpler.

Remember object orientation is also just a language feature. Prior to C++, people would roll their own vtable indirections to implement polymorphism. Aren't you happy you don't have to do that anymore?

Posted by Martin S. on September 07, 2009 at 08:48 PM PDT #

I think both C++ and Java illustrate the failure of the "committee-driven language design" tactic. I wish James Gosling had managed to be a benevolent dictator.

Posted by Elizabeth on September 08, 2009 at 12:28 AM PDT #

Creation of a programming language is first of all a design problem, a question of the purpose of the language and then a technical problem.
Hundreds of research languages plus the original ideas of the language designer define the pool of features available.
A few of the available features have to be picked and combined to a well designed result. You can't include too much or it will get too complicated. This selection is no process that can be done "committee-driven", just like it is impossible for a committee to create a painting. Someone has to take the lead. Out of practical experience with the language however some SMALL improvements can be suggested and very few of them can be included. This is project Coin. I think it is good work and as you explained it is much work. I think you are doing it really well and sensible.

Posted by aehrenr on September 08, 2009 at 02:25 AM PDT #

Post a Comment:
Comments are closed for this entry.



« April 2014

No bookmarks in folder