John Max Skaller was interviewed by Sean A. Corfield
Biography
John Max Skaller is the Principal Executive Officer and founder of Maxtal P/L, a small Australian software house, and has been working as a software developer for 18 years. Biggest step forward — going from an O26 to an O29 card punch :-) He has an Arts degree from Queensland University with a double major in abstract algebra.
His most recent (and only) non-ISO publication is the last chapter of “Software Solutions in C” edited by Dale Schumacher, Associated Press 1994. (Rush out and buy it :-) He is a regular comp.lang.c++ and comp.std.c++ contributor as well as being an active, and occasionally controversial, participant in the C++ standardisation process.
His e-mail address maxtal@suphys.physics.su.oz.au
The Interview
Q: Could you give the readers some idea of the C++ activity down under?
Several large corporations use C++. Our telecommunications industry uses it extensively, for example you may have seen the OTC/OSE class libraries designed by Graham Dumpleton of Telstra. In addition, foreign currency dealers have been using it experimentally for trend and transaction analysis.
But in Australia, most software development is on a small scale, and there is lots of it. The average user is an amateur, professional contractor, academic, or member of a four man company sitting in front of a PC 26 hours a day.
Because of its great adaptability, availability, low overhead and compatibility with C software and C programmers, C++ will thrive in Australia.
Q: Is Japan a big market for Australian software developers? And what sort of additional constraints does that trade place on your software?
I’m not sure exactly how big a market Japan is. Japan is a developed nation, more so than Australia, which is developing. Our main markets at present are USA and Europe. But South East Asia and the Pacific are becoming more important — Vietnam, Thaliand, Singapore, Malaysia, China, Indonesia, Nuiguini for example. Our problems both domestically and for export span many languages and cultures.
Q: Do you support the joint ANSI/ISO process?
Absolutely. ANSI needs the international input, and ISO needs the industry base. The double review and double voting will delay Standardisation, but the results will be vastly superior and better in the long run than if either body tried to go it alone.
The last thing the world needs is two C++ Standards.
Q: You represent both Australia and New Zealand, giving you two votes on the ISO committee WG21. Could you explain why, and how you determine which way to vote?
Under the direction of both governments, there has been a move towards regional cooperation in Standardisation between Australia and New Zealand. We’re both small countries with struggling economies and we should share resources rather than duplicating efforts.
My represention of New Zealand at the San Diego meeting of WG21 is an example. It is quite expensive to attend WG21 meetings, since ‘everywhere is a long way from Australia and New Zealand.
On non-political issues (are there any?) I vote in favour of motions which I perceive will improve the performance of our economies. In general, that means simplification and enhancement of the language. Australian software developers are much more able to cope with change than larger, regimented shops, so improvement of the language carries more weight than Standardising a less useful language. (There — its a political issue :-)
At the joint Australia/New Zealand meeting, and subsequently by email, I have gained an appreciation of New Zealands attitude to various issues, which are sometimes distinct from Australias. For example New Zealand is more concerned with precision of the specification than Australia.
Q: How important do you believe the C++ standard is for the two national bodies you represent?
C++ is important for Australia and New Zealand, and so Standardising it is important to our Standards bodies.
Both countries can only survive by moving their economies away from Primary and Secondary production into the Tertiary sector, and by establishing strong trading links in the Asia/Pacific region. That means things like education, research and development and tourism rather than sheep. To compete in any industrial setting depends on automation — computers. And we all know they need software to work. Exporting software, and products and services based on software, or which are made by businesses administered and taxed with the aid of software .. seems to cover the whole economy!
Q: What do you think about the current schedule? Is it realistic?
That question means “Will we produce a document according to the schedule on which there is international consensus?”
I don’t know exactly how all the P members of SC22 will vote. It seems beyond reasonable doubt that ISO procedures will attract lots of comments that require a response — whether they are NO votes, or conditional YES votes. ISO will have no choice but to require the committee to deal with these comments.
The same will happen later when ANSI conducts a US public review. The timing of that review is unfortunate — its way too late in the process for any real public input.
My opinion is that there is a certain minimum level of “quality” required in both the language and its description. The description at least is very poor: even committee members cannot figure out what the Working Paper actually says.
The language C++ itself is quite good, given the constraints of C compatibility.
Q: Of recent extensions, which do you think was the most important? The least important?
The most important are the extensions to templates.
“The language C++ itself is quite good, given the constraints of C eompatability.”
But new style casts and namespaces will also have a significant impact. But the question is misleading
The least important is probably the rule that allows int
main(int, char**)
to return without explicitly returning a value.
Q: Is the language complete yet? about the library?
Of course, that question can’t be answered without some criteria of completeness. My criteria are two fold: common usage and completion of existing features.
In both cases, I judge neither the language nor library is complete.
C++ added dynamic initialisations to C, with the same syntax as non-dynamic ones, but no realistic way to control the order of initialisation.
C++ added pointers to members as a type-safe version of the
offsetof
macro, but there’s no way to add a pointer to member to a pointer like an offset to adjust it to point to a contained object. The semantics of pointer to member casts are the subject of current debate.
We can form closures of functions with wrappers, but there’s no facility for closing class templates. Specialisations are a mess because they were thrown in rather than designed.
There’s no facility for discriminated unions, and the current restrictions on unions make their emulation particularly difficult.
After 20 years of experience with structured programming, there are no nested functions: lack of support for functional decomposition is a pain. For people who criticise the “flatness” of languages like Basic, Cobol and Fortran not to see that C and C++ has the same lack of proper nesting…
There’s also no module system. Header files and translation units are just a bit archaic.
The library currently lacks simple containers like lists, it has no facilities to make use of pointers in the presence of exceptions safe, it has no abstract frameworks or generic algorithms. (Many of these issues are being addressed right now) However, I think one can be more tolerant of incompleteness in the library — you can roll your own. Rolling your own compiler is a bit harder.
Q: In your opinion, what are the most significant deficiencies in the language? Can these be fixed by the standardisation process?
The single biggest flaw in the language is the type system. More generally, there is a lack of modelling of the fundamentals that gives the language the appearance of a complex web of special rules without coherence.
Actually, its not. But there is significant work to be done specifying the memory model, execution model, object model, compilation model, and type system, and resistance to doing this work from those that don’t understand that C++ is quite different to C in may respects, and we simply must account for those differences.
Much of the C terminology has been perverted so far that its C++ meaning is so distinct from its C meaning that retaining the C terminology seems like a deliberate attempt to confuse readers of the Working Paper. And many of the terms in the ARM have so many meanings, many with crucial but subtle differences, that the document in parts is incomprehensible.
I hasten to add that the Project Editor Andrew Koenig has performed a miracle with the San Diego paper, but that document is still far from specifying the level of detail and precision required for the conformance testing of compilers.
The ANSI/ISO Standardisation process can definitely work to resolve all these issues and produce a reasonable document. But not in accordance with the current schedule.
Q: Why do you propose so many extensions?
Because I’m a programmer. I get annoyed when any language makes me repeat things over and over again, or go though hoops to do something intrinsically simple.
Because I’m a mathernatican. I see no other way to precisely and succinctly describe the language in a reasonable amount of time than to simplify it.
Q: Simplifying by extension? Could you explain that comment?
If a set of rules or restrictions can be replaced by a more general one, that is both simpler and an extension.
For example, I have proposed “enhanced unions” in which unions are exactly like classes containing an anonymous union. For example:
union X { int x; complex z; };becomes
struct X { union { int x; complex z; }; };As such, we dont need any special rules for unions. We do need rules for initialising anonymous unions, but we needed them anyhow. In particular, an “enhanced union” may have or be a virtual base and have virtual functions.
Another example - Tom Pennello proposed at San Diego that “File_Scope” was the name of the file scope namespace. That is, it is just a namespace. So file scope rules are subsumed by namespace rules. Such generalisations simultaneously simply the language and make it more powerful.
Q: What’s the most important factor in the long term future of C++?
Keeping the strong focus provided by the C++ committee in place. At the moment, continued problem solving is more important that obtaining an unusable Standard.
The process of formulating adequate description of the language, and that of upgrading it, has been remarkably successful. 1994 C++ is a much better language than that described in the ARM, and most implementors are tracking the Working Paper — some extremely quickly.
Q: What’s the greatest risk to the long term future of C++?
Premature Standardisation.
Thankyou for your time, John!
John Max Skaller was interviewed by Sean A. Corfield
Sean can be reached by e-mail at: Sean.Corfield@PRQA.co.uk
