The Balkanization Of A Popular Programming Language

by

Dare Obasanjo

In the constantly changing world of software, programming language standards are aimed at providing stability and consistence in a dynamic industry.

Unfortunately there are many problems with standards created by standards bodies including: the standard attempts to satisfy too many interested parties and ends up so full of compromises that it is bloated yet satisfies few; the standards body is not quick enough to react to changes in the market place; or the body may be paralyzed by internal bickering over controversial decisions which may lead to seeming inactivity. The end result of the aforementioned problems is that the technology being standardized eventually is fractured as different vendors being dissatisfied with the standard do their own thing.

This is a story about one such standard and the contentious future of the programming language it represents.

Bjarne Stroustrup's "C with Classes" is one of the most popular application development languages currently in use. In the relatively short history of C++ it has flourished without an official standard (although there was the de facto ARM standard) until quite recently when in early 1998 the draft standard was ratified by the ANSI/ISO C++ Committee.The new standard made major additions to the language as well as changed old behavior of the language but was heralded by most as a welcome occurence.

Fast forward to 2001. Sun Microsystem's Java programming language begins to deliver in places where C++ has notoriously shown failings. The massive standard library which included platform independent threading and networking APIs, the elimination of memory related errors and leaks, a framework that allows for relatively easy building of medium and large scale component architectures as well as increased productivity versus languages like C have begun to make C++ look less and less attractive in comparison to the likes of Java. The main advantage C++ has over Java for most developers is performance but this may soon be irrelevant with growing hardware advances as well as improvements in Just In Time compilers.

C++'s principal designer, Bjarne Stroustrup, in an interview with Linux World early this year described the features he would like to see added to the language to make it more useful to the modern developer. He listed features like concurrency, reflection and extended type information, garbage collection, platform independent system facilities and compatibility with C99 as high on the list of potential additions to future drafts of the language. Bjarne Stroutrup has since followed up this interview with a meeting with other top C++ luminaries such as Scott Meyers, Herb Sutter and Dan Saks.


Stuck in First Gear

There is one little problem with the fact that new additions to the C++ standard are currently being proposed. The current standard is yet to be implemented fully. The C/C++ User's Journal recently had a C++ Compiler Conformance Roundup in which they declared the following:
There is no C++ compiler or library today that implements the Standard perfectly, but some are getting close.
Harsh words but true nonetheless. The C++ standard turned out to have features with more complex interrelationships and ramifications than were realized at the time the standard was being discussed. A good example of a subtle complexity that was not obvious at first glance is this discourse on namespaces which describes how Stroustrup claimed that the feature could be "imlemented in ten days" and explained to develepors "in ten minutes". Later on it turned out that the implementations at the time used for reference had gotten it wrong and in fact there isn't a compiler that has gotten it a hundred percent right.

The GCC 3.0 release criteria page displays that the C++ functionality is the major bottleneck preventing the release of GCC 3.0. What is particularly interesting is that while most other criteria have Done or Partly Done besides them to indicate their level of completion, the C++ functionality is strangely bare as if to indicate that there is still a significant amount of work to do. A Microsoft employee recently released a list of features that won't be supported in the upcoming release of Visual C++ 7.0 which means that a standards compliant Microsoft C++ compiler is still years away.

One begins to wonder if it's been almost four years since the draft discussions and yet no single compiler implements the entire standard, then when will the additions currently being proposed finally make it into the standard and then into the real world in a way that is compatible across platforms and compilers? Two years? Four? Six maybe? Where will C99, Java and C# be by then? Will C++ then have to perenially play catchup to match the usefulness of languages that have simpler grammars and thus easier to create compilers for?


"Managed" Extensions to C++ and Other Tales

The microsoft.public.dotnet.languages.vc newsgroup thread where the Microsoft employee listed the C++ features that will keep Microsoft's C++ compiler from compliance contained a number of interesting comments (143 at the last count) which seemed to have one overreaching theme. C++ standards compliance is a minor issue in Microsoft's plans when compared to the long term goal to out-Java the Java platform with the creation of .NET.

The difficulty of finding experienced compiler writers as well as the fact that the Visual C++'s team's main priority is to make sure that the Managed Extensions for C++ which allow C++ programmers to utilize the .NET framework is in place and ready to go as soon as possible makes it seem unlikely that full standards compliance will be forthcoming for quite a while. Also the fact that creating a C++ compiler and libraries which conform to the standard is more complex than for most other programming languages in existence also increases the difficulty of task.

Finally the fact that some of Microsoft's extensions seem to already tackle solutions to problems being considered by Stroustrup (e.g. garbage collection) it looks like it is even more likely that any future additions to the C++ standard will make it into Visual C++ quickly.

As for other compiler vendors and standards compliance, I leave you with this quote from Paul Mensonides on the microsoft.public.dotnet.languages.vc newsgroup obtained from the thread linked above.
As far as a split goes...what do you think that we have now? MS C++ (with managed extensions, attributed code, MFC, ATL, and a bunch of other 'extensions.') vs. Borland C++ (with VCL, MS copy-cat extensions) vs. IBM C++ (who now only supports AIX (conveniently their own OS)) vs. Comeau & EDG which is actually trying hard for compliance but they still have a huge amount of 'options' to try to make VC++ legacy code still work, etc., etc.. The split HAS happened

Java, Perl, or C: Which Language Will Be Next To Face The Spectre of Balkanization?

The C++ programming language is currently fractured and will probably remain so for a long time. C++ developers now left trying to figure out how to reconcile the different versions of C++ that they encounter from platform to platform or IDE to IDE for an indefinite amount of time. One question I am left asking myself is "Where else could this happen?"

  1. C99: The C99 standard has gotten very little industry press and very few of the C/C++ compiler writers (e.g. Microsoft, Borland, etc) have any mention of it on their sites. Also it seems few, if any, authors are writing books targetting C99 even though the standard is two years old. It is thus quite conceivable that when it does finally gain acceptance that it will face the same problems with inertia that C++ has had to deal with. At least it has a much simpler grammar and the changes are not as vast.


  2. Java: It turns out Sun may have been smart to hold on to their language and fight tooth and claw to keep anyone from altering it. With the amount of alterations and extensions Java has faced, from J++ to Generic Java it is a good thing that there was a powerful corporation to make sure the actual Java™ standard didn't get abused instead of a toothless committee that can only complain.


  3. Perl:In a talk at the Atlanta Linux showcase, Larry Wall discussed potential features for Perl 6. Amongst these potential features was
    "The language will be dynamically extensible, using modules written in Perl. So you can program in a language that looks like Python, Latin, or Java, if you want.".
    This seems to imply that the language which already can be rather undecipherable in hands of even a reasonably competent programmer can now be altered drastically almost at whim. This can only lead to fracturization but in this case it may be expected and maybe even encouraged.
© 2001 Dare Obasanjo