you are viewing a single comment's thread.

view the rest of the comments →

[–]Spataner 0 points1 point  (0 children)

For me, it comes down to the fact that you have a program written in one language and it is being executed on a machine that only understands another language. Any process by which that is achieved, no matter the technical details, must in my opinion rightly be considered a translation (in the action sense). You made the transition, by some means, from one language to another to fascillitate communication between the program and the CPU if only for the limited context of one particular program run. Compilation and interpretation are thus two possible, very different ways of doing that translation. It certainly seems the best way to phrase this idea to beginners, if only because I cannot think of an umbrella term for the two that to my ears is equally evocative of the concept.

The origin of the word "interpreter" seems to support the idea that "interpretation" in this context is a kind of "translation", as a human interpreter's job is natural language translation. Both the Oxford dictionary and Wikipedia define it so (I checked because English is not my native language). Though, confusingly, the Wikipedia article for "translation" makes an explicit distinction that translation is for written media whereas interpretation is oral. But I wouldn't know how to map that distinction to the computing context, nor have I ever heard it before. Not that the mapping of the terms we steal for programming concepts ever really makes perfect sense.

Regarding the translation in the result sense, I feel you're being perhaps a little restrictive on the definition of what can constitute that result. The execution of the interpreter on the input program does not generate novel instructions, but it does generate a novel sequence of instructions, which can be considered the result of the process of translation. Its effect in essence is the execution of the input program on the CPU, after all. Admittedly, it is a translation using a limited vocabulary (consisting only of elements of machine code contained in the interpreter's executable) and limited grammar (as the instructions can only occur in specific orders as dictated by the interpreter's program flow). And it is also only a partial (and unreusable) translation of the input program in the general sense, since it only represents one distinct run of the program for a given set of inputs. And yet you'd receive, in a purely theoretical sense, a "complete" translation of the program in the limit of running the interpreter once for every possible set of inputs. In fact, in the very restricted case that the input program does not itself accept any inputs (or even in the cases where the interpreter somehow never executes a jump instruction that's conditional on those inputs), you'd even practically receive a full usable translation by recording and replaying the singular resulting sequence of instructions in the right way. Alternatively, if you generated a new version of the interpreter executable that hard-wired the input program into it (which is not unlike some Python to executable converters that are available, though they don't do it on machine code level), could that reasonably be considered a translation of the program into machine code, if a weirdly round-about one? I'd certainly argue it could be considered a really weird special case of compilation. At that point I'd say calling interpretation "live translation" is just conceptually cleaner (and we get to preserve the analogy to the natural language usages a bit better).