Oracle Blog

Joseph D. Darcy's Oracle Weblog

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.

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.

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.

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.

@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?

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.