Flutterby™! : Machine Translation 2006-08-22 23:43:06.841023+00

Machine Translation

2006-08-22 23:43:06.841023+00 by Dan Lyke 4 comments

Argh. Next time I have a bunch of code to translate from one language (our expression graph description language) to another (C++), I write a Perl script to do it. No "A couple of Emacs macros and it should be fine!", just start with Perl and acknowledge that it really demands a more complete solution.

I've always found it best to just translate line by line - at least when I've done REXX to Perl, or Avenue to VBA, or C++ to Java... It would be WAY too much work to write an effective translator...

My experience with some of these tasks is that they don't need a full parser for the input language, just something that handles the most common idioms.

Kind of like the indentation systems of modern editors. Yeah, you can confuse 'em if you try, but overall they do pretty darned well for knowing only a little bit of the various languages.

I'm finding, moving some code from C++ to Java, that it's not as straight-forward as one would think. The biggest hurdles: 1. finding a good way to integrate procedural code into objects, 2. deciding whether new objects should be created or exist objects in the existing Java code should be used (basically, I'm taking some functionality from some C++ code that preceded the Java code - and they both use similar objects but the Java uses a much newer implementation).

So, maybe I'm not doing a straight-forward translation. I'm sure I could probably pipe the C++ code through a translator and get a Java program out the backend that was pretty much plug-and-play. But it always seems that code translation is really just the first step in a larger process of understanding what's going on and extending it much further once the end-users start getting a taste of it all redone and integrated. This is what kept the bills paid for about six months post-game-development as I ported an application from MS Access to straight VB... spending about 5X as much time adding new functionality to the VB version that didn't exist in the Access version. Same went for the REXX to Perl translation... Once I got the code running on Perl and Linux, the customer started a steady stream of modification requests. In the end, it paid off that I really understood the code.

Ahhh, I think you've nailed the difference between the applications I'm looking at and the ones you've tackled.

In this specific case, we've got a really good feel for how our modeling language maps to the C++ constructs that provide the implementation. So we're not having the issue of "you can write BASIC in any language" and having to figure out how to write correctly for the native environment, we know that we can write RML in C++.

And, the nature of the RML execution model promotes fairly simplistic constructs. It's building an expression tree which gets pulled, so there's no re-use of variables, and because the idea is that we want to work this towards SIMD execution (evaluate these portions of the graph at the following times, because we need to see what the scene looks like to show you how your animation is going to be moving through it), conditionals are discouraged.

So my task (and this is not the first time I've tackled something an awfully lot like this) is really more a matter of "define these inputs with their defaults, define these outputs, rearrange these fairly simplistic expressions to map these inputs to these outputs so that they're valid C++". Not nearly on the same level as converting REXX

to Perl