Title: Editorial

In my days as a schoolteacher, I used to challenge my pupils to read aloud a simple sentence from the blackboard. These were bright youngsters and the idea that I could write something that was correct English that they would not be able to read aloud generally caused disbelief. The sentence I wrote was:

"It was a good row."

This is the kind of thing that makes it difficult to provide file readers. But that is not the point that I want to make. Note that if you pronounced 'row' the same way that you would 'roe', the result would have at least three different meanings; referring to the performance of some rowers (oarsmen or oarswomen), referring to a row of something (such as plants) or referring to a fish roe. Usually the context of our writing or speech is sufficient guide to our meaning. This is more likely to be the case where the meanings are distinct. It becomes harder when the meanings have a degree of overlap.

Computer Science terminology is riddled with cases where a technical term and an English word are homonyms. Three that spring to mind are 'bit', 'byte' and 'nibble'. The only serious problem with these is that too many programmers consider 'byte' and 'octet' to be synonyms. That is a matter for precise definition rather than confusion caused by the sound of the word.

Where confusion takes over is when such specialist terms are recycled within the same general context. Clearing up the distinction between 'prototype' in the sense of a 'test model' and 'prototype' referring to a C function declaration that includes fully typed parameter lists is usually fairly easy. The exact context of use usually disambiguates its use. By the way, there is no need to use the term 'prototype' in C++ because there is no other form of function declaration; 'function prototype' and 'function declaration' are synonyms in C++ though not in C.

Where the problem begins to get serious is with keywords like static. How do you explain the meaning of static as a keyword? I am not talking about the confusion caused be the overloaded meanings of the keyword itself but the confusion between any use of the keyword and the CS concept of compile time. Note that even that sentence relies on your ability to generalise the concept of compile time to include some of the behaviour of an interpreter. It is all too easy to rely on the understanding of our audience. That is fine, so long as that reliance is well founded. It often is not.

It gets worse as we use the same word for a container and its contents. What do we mean by 'pointer' when talking about code. Do we mean a derived type (note that here again we have confusing terminology, C refers to fundamental types and derived types - pointers are included in the later) or a value of such a type? If we are not very careful we find ourselves saying 'A pointer provides storage for a pointer.' The concept of a pointer is already difficult enough without adding such extra confusion.

What can we do about these problems? Unfortunately the honest answer is 'very little.' We should certainly be aware of them and of the potential for misunderstanding and confusion. We should be careful of dangerous or misleading analogies. Telling a C++ programmer that a Java 'inner class' is like a C++ 'nested class' is dangerous. Our audience will hear us saying that the terms are synonyms. However much we then go on to explain the differences some of our audience will not be listening. It is essential to eschew the use of phrases that can easily convert into 'sound bytes.'

At least 'nested class' and 'inner class' are different terms so we can draw a distinction between them. But what about 'reference'? The semantics of references is markedly different in different computer languages.

Now we already have all these language problems when talking about a single computer language. The potential grows when we have more than one language in context at the same time. The keyword const has almost the same syntactic requirements in C and C++. They are not quite the same because const qualified variables in C++ (though not in C) require initialisation at the point of definition and are true compile time (static) constants. The semantics of const are sufficiently different to cause C programmers to talk about 'const poisoning' while C++ programmers talk of 'const correctness.'

Now the differences between C and C++ terminology are small because C++ was deliberately designed as a derivative language. It is not quite true that C source code is also C++ source code (with the same semantics) but it very nearly is. That is no accident. The only places where they diverge is where the designers of C++ decided that the benefits gained from difference were overwhelmingly greater than the penalties.

Java is different, and I think the decision to use so much C and C++ syntax is highly questionable. If Java were to entirely replace C and C++ the syntactic similarities would be tolerable. However any such expectation by the designers of Java is pure hubris. Clearly many programmers were going to have to work in mixed environments. In such circumstances, identical syntax with different semantics is very bad news. (As an aside, I find the Java type system with different semantics for fundamental types and for class types a definite negative. However, it serves to emphasise the need to the semantics of individual types in C++.)

Those who have had any experience of the multitude of BASIC dialects may begin to recognise the symptoms. I can remember when BBC BASIC (the dialect used by Acorn machines) was hailed as being extremely efficient and fast although it was fully interpreted. The problem was that the highly insular British were largely unaware of the fact that many US based dialects of BASIC were fully compiled so the slowness of the interpreted versions was not an issue.

With the advent of Microsoft's C# we have the final (I hope) aid to language confusion. We have K&R C, ISO C (two versions), ISO C++ (though many still use the ARM version), Java, Objective C and C#. Each of these dialects (because that is what they are) has subtle differences. Much worse, any professional programmer is likely to have to use at least two and probably three of them during their work.

You know, if I wrote a novel that was as derivative of an existing work as C# and Java are from C++ I would be sued for breach of copyright. It is a pity that Ritchie never demand intellectual property rights on C.