¿Cuál es la definición industrial de un intérprete (a diferencia de un compilador)?

7

En mis cursos de diseño de compiladores, aprendí y trabajé con una definición académica clara de intérprete y compilador, con un intérprete

  

un programa Pi de un lenguaje M capaz de tomar un programa i de un lenguaje I y una entrada y ejecutar i con la entrada dada y la semántica correcta para I en una máquina capaz de ejecutar programas desde M

y un compilador siendo

  

un programa Pc que, cuando se le da un programa válido i de un idioma I como entrada, produce un programa semánticamente equivalente o en un idioma O

Esta definición pondría claramente la ejecución habitual del código de bytes de Java por parte de una JVM en el dominio de interpretación, sin importar cuánta compilación JIT se realice. (Por supuesto, Java también se compila antes, desde el código de Java al código de bytes de Java). He encontrado opiniones en las discusiones en este sitio que indican clara y vehementemente lo contrario, es decir, que las cosas de ejecución del Código de Java son compiladores. Como estoy a punto de dar el salto de lo académico a la industria, estoy un poco confundido aquí:

¿La definición anterior de intérpretes es falsa desde el punto de vista de la gente de la industria en general? ¿O es simplemente falso para la gente de Java? ¿Es la vista de Java como un lenguaje completamente compilado una vista alternativa pero minoritaria? ¿O solo unos cuantos locos?

(PS: Por favor, no mueva esto a la teoría. He formulado esta pregunta aquí deliberadamente, ya que me gustaría conocer la opinión de la comunidad industrial profesional, no de la comunidad académica).

    
pregunta thiton 29.09.2011 - 09:05

6 respuestas

7
  

Esta definición colocaría claramente la ejecución habitual del código de bytes de Java en el dominio de interpretación, sin importar cuánto se realice la compilación JIT. He encontrado opiniones en discusiones en este sitio que indican clara y vehementemente lo opuesto, es decir, que las cosas de ejecución de Bytecode de Java son compiladores.

Bueno, las dos definiciones no son mutuamente excluyentes. Un intérprete puede contener un compilador (de hecho, la mayoría de los intérpretes modernos contienen al menos un compilador de bytecode).

Pero creo que la definición intuitiva que la mayoría de la gente usa aquí es algo como:

  • un compilador crea código nativo que luego es ejecutado directamente por la CPU
  • un intérprete tiene algún tipo de "bucle principal de intérprete" que lee las instrucciones (ya sea enunciados de código fuente o algo así como P-Code o bytecode precompilado) y realiza las instrucciones en consecuencia.

Por esta distinción, un "intérprete" suele ser un orden de magnitud más lento que un programa "compilado". Entonces, cuando hablamos de rendimiento, esta definición es más útil que la definición CS clásica.

    
respondido por el nikie 29.09.2011 - 09:27
3

De Pragmática del lenguaje de programación de Michael Scott, tercera edición .

La explicación de alto nivel de la compilación es:

  

El compilador traduce el programa fuente de alto nivel en un programa objetivo equivalente (generalmente en lenguaje de máquina) y luego desaparece. En algún momento posterior arbitrario, el usuario le dice al sistema operativo que ejecute el programa de destino. El compilador es el lugar de control durante la compilación; El programa objetivo es el lugar de control durante su propia ejecución.

Una explicación de alto nivel para la interpretación es:

  

A diferencia de un compilador, un intérprete permanece alrededor de la ejecución de la aplicación. De hecho, el intérprete es el lugar de control durante esa ejecución. En efecto, el intérprete implementa una máquina virtual cuyo "lenguaje de máquina" es el lenguaje de programación de alto nivel. El intérprete lee las declaraciones en ese idioma más o menos una a la vez, ejecutándolas a medida que avanza.

Sin embargo, algunas implementaciones de lenguaje también combinan compilación e interpretación, por lo que las líneas se vuelven un poco más borrosas. En tal caso, el programa fuente se traduce en un programa intermedio que se ejecuta en una máquina virtual. Se compila el código fuente y se interpreta la salida de la compilación.

La compilación ocurre cuando un traductor analiza a fondo los archivos de origen de entrada y crea una salida que no se parece a la fuente original. Eso significa que la compilación requiere, según Scott, "análisis y transformaciones no triviales".

    
respondido por el Thomas Owens 29.09.2011 - 11:50
3
  

¿La definición anterior de intérpretes es falsa desde el punto de vista de la gente de la industria en general?

No

  

¿O es simplemente falso para la gente de Java?

No

  

¿Es la vista de Java como un lenguaje completamente compilado una vista alternativa pero minoritaria?

No

  

¿O solo unos pocos locos?

No

El entorno de ejecución de Java es más complicado de lo que se prevé en esas definiciones de CS teóricas. Pero tanto los teóricos como los desarrolladores prácticos son geniales con esto.

Definiciones teóricas como estas están diseñadas para un propósito particular; es decir, razonamiento formal sobre cómo se "compilan" y "ejecutan" los programas. Si necesita modelar Java de esa manera e incluir la compilación JIT en el modelado, entonces hay formas de manejar esto. Por ejemplo, podría hacer que "llamar al método compilado nativo" una operación primitiva del intérprete.

La realidad es que la plataforma de ejecución Java utiliza tanto la compilación como la interpretación tanto en el sentido intuitivo como en el teórico. Entonces, si necesita modelar la plataforma Java a ese nivel de detalle, necesita incorporar esto en el modelado.

    
respondido por el Stephen C 29.09.2011 - 09:27
1

Por lo general, considero que cualquier programa que analiza y convierte el código en un nivel inferior forma un compilador. Así que definitivamente consideraría a Java un compilador. Como serían los compiladores C #, Python, PHP, etc., ya que todos ellos reducen el código fuente a un código de bytes, que luego se ejecuta. C ++, Delphi y algunos otros que compilan directamente al código ejecutado de forma nativa que llamaría (y veo que mucha gente llama) 'compiladores de código nativo'.

Un intérprete, al menos la forma en que lo aprendí cuando , es un programa que analiza las líneas de un script de una en una y las ejecuta directamente. Es decir, no hay código de nivel intermedio o inferior. No tengo conocimiento de ningún idioma "moderno" que sea intérprete.

Con respecto a su definición de 'compilador', no creo que eso implique necesariamente que el código Java no esté compilado. Solo tiene que interpretar 'lenguaje O' como el conjunto de instrucciones de código de bytes.

    
respondido por el GrandmasterB 29.09.2011 - 09:42
0

Desde el punto de vista práctico, puedes pensar que algo se interpreta tan pronto como puedes hacer este pseudo código:

a = 6
b = 7
eval("c = a + b")
print c

No discutiré los problemas de seguridad, las mejores prácticas sobre cuándo usar y cuándo no usar eval, etc.

JVM y .NET permiten (con algunas llamadas a funciones de biblioteca estándar, envoltorios y otros problemas) compilar código sobre la marcha:

a = 6
b = 7
assembly = my_implementation_of_eval("function sum(x,y) { return x + y} ")
print assembly.call("sum",a,b);

Pero eso es solo un compilador con capacidad para cargar dinámicamente un módulo. Compare la integración profunda con las variables locales y la creación de nuevas variables en el intérprete.

    
respondido por el ZeusTheTrueGod 29.09.2011 - 12:33
0

Un compilador generalmente traduce algo del lenguaje A al idioma B. El lenguaje B puede ser un código de máquina (para una CPU existente o virtual), pero hay compiladores que generan código fuente en un idioma diferente.

Un intérprete generalmente ejecuta un programa escrito en lenguaje X.

    
respondido por el oenone 29.09.2011 - 14:52

Lea otras preguntas en las etiquetas