In our third article, Mark Homnack makes some incisive, interesting and sometimes infuriating comments on the industry, its technology, its process and its reality.

In our second article, Tim Stevens give us more details on the nature of Java locales and introduces us to some problems and solutions in client-server environments.

And in our first article, Translator X is back again! Having received rave reviews for his recent article, Towards a More Equitable Pricing Structure, he targets compilers and development environments this time around. As a translator, he needs many things to get his job done, some of which a programmer might never think of, if only because some of them seem impossible at first sight. Which brings us to…

Computability and Impossibility

The first thing we learn in computability theory is that some problems are solvable and some are not. For example, it would be nice to know if a given program will stop, or will continue executing forever. Can we write a general-purpose program that could tell us if another program will ever stop or not?

Computability theory allows us to prove formally that such a general purpose program to predict the outcome of another cannot exist. Consider that if it did exist, we could easily prove Fermat's last theorem, by simply determining if the following program will ever stop:

n=2;
repeat {
   n= n+1;
   IF  xn + yn = zn has non-zero integer solutions THEN stop;
}

(An interesting history of the proof of Fermat's last theorem can be seen here).

In fact, if we were capable of predicting which programs will stop, we could solve a lot of problems, mathematical theorems and otherwise. But there are still others we could not solve, which means that some problems are more impossible than others! Computability theory shows us that there are classes of impossibility and even that there is an infinite hierarchy of such classes, and in fact, an infinite hierarchy of hierarchies, in a manner exactly similar to the infinite number of classes of infinity brought to us by Cantor (after his first mental breakdown). Infinite infinities is as close as you'll ever get to a mathematical definition of God and it is not surprising that Cantor had more support among theologians than among mathematicians! (All this is a nerd's version of Stairway to Heaven). (For more info, see here).

Getting to the point now, we know that in the general case we cannot create a tool that will automatically generate all possible visual contexts for a given application (which is something a translator would like to have). This begs two questions:

• Can we nevertheless achieve some results with imperfect tools?
• Can we better design programming languages to allow better translatability?

Translatability and Testability

While the general problem cannot be solved, there are still many useful things that can be done. Consider coverage tools for Software Quality Assurance (i.e. testing). Coverage tools are designed to analyze source code, sometimes modify it, with the objective of making sure all parts of the software have been exercised during testing (sometimes by pointing out those parts that have not been executed).

In effect, a translator's need of seeing text in all its contexts is also a coverage problem: the translator would like to see all user interface possibilities and be able to access them by string, or word, etc. The fact is translators and testers have very similar needs with respect to the User Interface part of the program.

All programs have to be tested and, if you believe in the survival of human culture, as time goes on more and more programs will need to be translated. Translation and testing often happen after the main development, and the needs both are often under-represented. There is a natural synergy between testing and translation that may be beneficial to both domains: it may lead to better tools, better process, better visibility.

Globalizing Programming Languages

Can programming languages be globalized? Can we design languages with globalizability in mind? The answer is yes, numerous cases already exist. Consider, for example, the following printf statement in C:

printf ("There were %d errors found in file %s", ErrCount, Filename);

The problem with the above statement is that even if one externalizes the string, the order in which the parameters (ErrCount, Filename) are substituted in the message is hard-coded as part of the program (whereas in fact it is language dependent). This is why we need message formatters. The PERL syntax below has no such problems:

print "There were $ErrCount errors found in file $Filename"

Here the message pulls in the variables it needs (as with a message formatter).

Java introduced Unicode as THE native character set. Forcing the character set would have been heresy 10 years earlier. Standardizing on Unicode has helped a lot, but this is still just the foundation of globalization. We still have a long way to go. Consider that just what is text and what is not (char vs. byte) is still not obvious in many languages. Today, removing native text types and forcing text to be handled exclusively by class methods may be heresy; tomorrow it may not.

Remember, globalization is pervasive. It affects programming language design also. And, yes, resistance is futile.