Why do language converters suck?

Question

Why do language converters/interpreters function poorly. Its seems that if you have function x(,) and functions x() takes blah, blah, for parameters and can return x,x and x, then it should be easy for the interpreter programmer to make the function in the converted language to act in the exact same way. I know that programmers writing those interpreters work there ass off, but it seems like there a stumbling block somewhere. What is it?

EDIT1:

I understand that there a lot more to it then functions and class and data types.

Answer 1

The problem usually arises when the constructs of the languages do not have equivalents. Converting simple functions is easy. What about something more complicated, like classes, or templates? Converting C++ to C# would be nearly impossible because converting templates to generics is more than just syntax. It requires rethinking how the code is written, from the ground up.

If you want an example that works, take a look at C#/VB.NET converters. For the most part, the languages are semantically the same. If you attempt to convert code that uses constructs that are available in both languages, the conversion should be mostly perfect.

Answer 2

You consider only the simplest case. A complete interpreter has to handle much more complicated cases, involving things like type promotion, GOTO, classes, etc...

Answer 3

Well first, they aren't used very often. The most bug free applications didn't start out that way. They got to be 99% bug free because hundreds or even millions of people used them in all sorts of different situations so practically every condition that can be encountered has. How many times would you use a perfect language converter? Once or twice?

Second, even if the syntactical converters work well, there's the library names that must be converted. This isn't the case for say, VB.Net to C#... but what about C# to Java? Java's library structure is vastly different than that of C#'s and even then there simply aren't any straight equivalents for say, the SqlConnection and SqlCommand classes in C# for example.

And then there's languages that have whole different approaches to programming. Obviously converting from a procedural language to a functional language gets hairy rather quickly. But even converting from ASP Classic to (Proper) ASP.Net isn't a straight syntax conversion.

Answer 4

Converting, or translating, files, or source code, from programming language A to B it is not big deal, even for what we think that it is impossible, but converting libraries and modules dependencies is pain in neck, and near to impossible. Even if there is a perfect converter from A to B, even then there come extensions to languages which are mostly written in C for performance reasons, what is case for Python, Ruby, Lua, etc.

Answer 5

Why are there some language converters out there that don't horribly fail - that are, indeed, even somewhat good?

The problem of translating from one language to another is enormously complex and far beyond the capabilities of everything we know. You can see it in the way automatic translation services translate websites from one language to another. It is no different in programming languages.

Answer 6

Why do language converters/interpreters function poorly.

Do they? Would you say that javascript, python, ruby, ... interpreters function poorly? I wouldn't.

Converters are a completely different story. I guess they're not perfect, because people don't use converters that often. Also it is difficult to convert one thing into another reliably.

Take this C code for example:

void crazy_function(char *ptr) {
    ptr[-100] = '\123';
}

Maybe that's an extreme example, but it is not possible to translate it to most languages. It's also impossible to translate it to any other language to get a perfect equivalent. This also affects dynamic languages - take python for example:

self.xxx = 'abc';

Now if you want to translate it into a language where objects are not easily extendible, you have to create runtime support for those extra fields that works with the target language's native notation. And these are only 1-line examples. Expect much more complicated cases if you want to translate real programs.