Automated Language Translation: Pitfalls

[#1]

In my previous entry I talked about Dale Vecchio's recent (17 Feb 2012) report titled Code Transformation Solutions Can Provide a Viable Modernization Alternative. He described the issues involved in applying automation to the challenge of migrating an application from one language and database technology to another and summarized the major vendors in this space. 

Other Automation Pitfalls

Dale discussed the basic approach of many of these automation purveyors. Essentially they parse source into abstract models, transform those models, and generate code in some new target language. Syntax, while important to the parsers and generators, is not the key to translation.

A major trade-off to consider when applying such tools is semantic fidelity. Consider something as simple as an assignment.

  COBOL: MOVE X TO Y;
  Java : X = Y;

A naive syntactic transformation might consider the Java to be a translation of the COBOL.  But even something that appears this simple raises multiple issues.  MOVE has complex semantics, supporting a wide assortment of implicit conversions between COBOL datatypes - types that do not have an obvious translation into simple Java. Tools handle these subtleties in different ways.  Sometimes they define object types that capture the complex rules of the source language type system. So you might define a Java object using something like

  CobolObject x = new CobolObject("PIC 99.99");
  x.set(y);

With the right implementation of CobolObject, this could allow exact preservation of the original program semantics at the expense of comprehensibility.  Assignment becomes a method on the CobolObject class.  More importantly you how have a program that can only be understood by a developer with both Java and COBOL experience.

Sometimes the tools depend on user guidance to abstract away from many of the low level details and help guide the user to comprehend those cases where an implicit conversion might need to be taken into account. For example, the above example might become

  double x = y;

If we had depended on the value contained in y being truncated when assigned to x (e.g.. If y was 123.00, then x was expected to end up 23.00), that computational issue needs to be dealt with.

In addition to the problems driven by type misalignments, similar problems arise with many other semantic concepts; screen and exception handling being prime examples.

This is part of the reason why Dale makes the critical distinction between syntactic and architectural transformation, though some of the issues I have described lie in a gray area in between.