Intérprete (Informática)
Intérprete (Informática)
Intérprete (Informática)
Usando un intérprete, un solo archivo fuente puede producir resultados iguales incluso en sistemas
sumamente diferentes (ejemplo. una PC y una PlayStation 4). Usando un compilador, un solo archivo
fuente puede producir resultados iguales solo si es compilado a distintos ejecutables específicos a cada
sistema.
Los programas interpretados suelen ser más lentos que los compilados debido a la necesidad de traducir el
programa mientras se ejecuta, pero a cambio son más flexibles como entornos de programación y
depuración (lo que se traduce, por ejemplo, en una mayor facilidad para reemplazar partes enteras del
programa o añadir módulos completamente nuevos), y permiten ofrecer al programa interpretado un
entorno no dependiente de la máquina donde se ejecuta el intérprete, sino del propio intérprete (lo que se
conoce comúnmente como máquina virtual).
Índice
Intérpretes de bytecode
Eficiencia
Interpretadores de árbol de sintaxis abstracta
Compilación justo a tiempo
Ejemplos
Lenguaje interpretado
Antecedentes históricos de interpretado y compilado
Ventajas de interpretar un lenguaje
Desventajas de los lenguajes interpretados
Lista de lenguajes más usados de forma interpretada
Lenguajes normalmente compilados a código byte
Notas y referencias
Véase también
Enlaces externos
Intérpretes de bytecode
Hay un espectro de posibilidades entre la interpretación y la compilación, dependiendo de la cantidad de
análisis realizados antes de que el programa sea ejecutado. Por ejemplo, el Emacs Lisp es compilado a
bytecode, que es una representación altamente comprimida y optimizada del código fuente del Lisp, pero
no es código de máquina (y por lo tanto no está atado a cualquier hardware particular). Este bytecode es
entonces interpretado por un intérprete de bytecode (que está escrito en C). En este caso, el código
compilado es el código de máquina para una máquina virtual, que no está implementada en el hardware,
sino en el intérprete de bytecode. El mismo acercamiento es utilizado con el código Forth usado en sistemas
Open Firmware: el lenguaje fuente es compilado en "código F" (un bytecode).
Eficiencia
La desventaja principal de los interpretadores es que cuando se interpreta un programa, típicamente corre
más lentamente que si hubiera sido compilado. La diferencia en velocidades puede ser minúscula o grande;
a menudo un orden de magnitud y a veces más. Generalmente toma más tiempo correr un programa bajo
un interpretador que correr el código compilado, pero puede tomar menos tiempo para interpretarlo que el
tiempo total requerido para compilarlo y ejecutarlo. Esto es especialmente importante si se está haciendo y
probando un código prototipo cuando un ciclo de editar, interpretar y depurar del interpretador, a menudo
puede ser mucho más corto que el ciclo de editar, compilar, ejecutar y depurar del compilador.
La interpretación de código es más lenta que la ejecución de código compilado porque el interpretador debe
analizar cada sentencia en el programa cada vez que es ejecutada y entonces realizar la acción deseada,
mientras que el código compilado solo realiza la acción dentro de un determinado contexto fijo por la
compilación. Este análisis en tiempo de ejecución se conoce como "sobrecarga interpretativa". En un
interpretador, el acceso a las variables es también más lento porque el mapeo de identificadores hacia las
localizaciones de almacenamiento debe hacerse repetidamente en tiempo de ejecución en vez de en el
tiempo de compilación. Hay varios compromisos entre la velocidad de desarrollo al usar un interpretador y
la velocidad de ejecución al usar un compilador. Algunos sistemas (ej., algunos LISPs) permiten al código
interpretado y al compilado llamarse el uno al otro y compartir variables. Esto significa que una vez que
una rutina ha sido probada y depurada bajo el interpretador puede ser compilada y por lo tanto beneficiarse
de una ejecución más rápida mientras que otras rutinas están siendo desarrolladas. Muchos interpretadores
no ejecutan el código fuente tal y como está sino que lo convierten en una forma interna más compacta. Por
ejemplo, algunos interpretadores BASIC reemplazan palabras clave (keywords) con tokens de un simple
byte que pueden ser usados para encontrar la instrucción en una tabla de saltos. Un interpretador puede
bien usar el mismo analizador lexicográfico y el analizador sintáctico (parser) que el compilador y entonces
interpretar el árbol de sintaxis abstracta resultante.
Así, el AST se ha propuesto como un mejor formato intermedio para los compiladores justo a tiempo que el
bytecode. También, permite realizar un mejor análisis durante tiempo de ejecución. Un interpretador Java
basado en AST ha demostrado ser más rápido que un interpretador similar basado en bytecode,3 gracias a
las más poderosas optimizaciones permitidas al tener la estructura completa del programa, así como tipos de
datos de alto nivel, disponibles durante la ejecución.
Ejemplos
Algunos ejemplos de intérpretes:
Motor Zend
CPython
Ruby MRI
YARV
en:Basic
Lenguaje interpretado
Un lenguaje interpretado es un lenguaje de programación para el que la mayoría de sus implementaciones
ejecuta las instrucciones directamente, sin una previa compilación del programa a instrucciones en lenguaje
máquina. El intérprete ejecuta el programa directamente, traduciendo cada sentencia en una secuencia de
una o más subrutinas ya compiladas en código máquina.
Los términos lenguaje interpretado y lenguaje compilado4 no están bien definidos porque, en teoría,
cualquier lenguaje de programación puede ser interpretado o compilado. Cada vez es más popular, en las
implementaciones más modernas de un lenguaje de programación, ofrecer ambas opciones.
Los lenguajes interpretados también pueden diferenciarse de los lenguajes de máquina. Funcionalmente,
tanto la ejecución y la interpretación significan lo mismo -obtener la siguiente instrucción/sentencia del
programa y su ejecución-. Aunque el bytecode (código byte) interpretado es además idéntico a su forma en
código máquina y tiene una representación en ensamblador, el término "interpretado" se reserva en la
práctica para lenguajes "procesados por software" (como las máquinas virtuales o emuladores) por encima
del procesado nativo (por ejemplo, por hardware).
En principio, los programas de muchos lenguajes se pueden compilar o interpretar, emular o ejecutar
nativamente, así que esta designación se aplica solamente a la implementación práctica más usual, en vez de
representar una propiedad esencial del lenguaje. De forma parecida al microcódigo del procesador, muchos
intérpretes, internamente recaen en una compilación en tiempo de ejecución.
Evitando la compilación, los programas interpretados son más fáciles de evolucionar durante el desarrollo y
la ejecución (transformándose en ocasiones de uno en la otra). De otra parte, ya que la compilación implica
una traducción a un formato más amigable con la máquina, los programas interpretados corren más
lentamente y menos eficientemente (es decir, gastan considerablemente más energía). Esto es especialmente
verdad para los lenguajes de guion, cuyas sentencias son más complejas de analizar comparadas con las
instrucciones máquina.
Muchos lenguajes se han implementado usando tanto compiladores como intérpretes, incluyendo BASIC,
C, Lisp, Pascal y Python. Java y C# se compilan a código byte, el lenguaje interpretado específico para la
máquina virtual. Muchas implementaciones de Lisp pueden mezclar libremente código interpretado y
compilado.
En los comienzos de la computación, el diseño de lenguajes fue fuertemente influenciado por la decisión de
usar la compilación o la interpretación como modos de ejecución. Por ejemplo, algunos lenguajes
compilados requieren que los programas deban indicar explícitamente el tipo de dato de una variable en el
momento en que sea declarada o al ser usada por primera vez, mientras que algunos lenguajes interpretados
toman ventaja de los aspectos dinámicos de la interpretación para hacer tales declaraciones innecesarias.
Por ejemplo, Smalltalk (1980), que fue diseñado para ser interpretado en tiempo de ejecución, permite a
objetos genéricos interactuar dinámicamente entre sí.
Inicialmente, los lenguajes interpretados eran compilados línea por línea, es decir, cada línea era compilada
a medida que estaba a punto de ser ejecutada, y si un bucle o una subrutina hicieran que ciertas líneas se
ejecutaran múltiples veces, serían recompiladas repetidamente. Esto ha llegado a ser mucho menos común.
La mayoría de los lenguajes interpretados usan una representación intermedia, que combina tanto la
compilación como la interpretación. En este caso, un compilador puede producir el código byte o el código
enhebrado, que entonces es ejecutado por un intérprete de código byte.
Java
Python
Ruby (de forma similar, utiliza un árbol de sintaxis abstracta como representación
intermedia)
Forth
La representación intermedia se puede compilar una sola vez (como en Java), cada vez que se vaya a
ejecutar (como en Perl o Ruby), o cada vez que se detecte un cambio en el código fuente antes de la
ejecución (como en Python).
Interpretar un lenguaje da a las implementaciones una flexibilidad adicional sobre las implementaciones
compiladas. Algunas características son más fáciles de implementar en intérpretes que en compiladores son
(pero no se limitan a estas):
La principal desventaja de la interpretación es una velocidad de ejecución del programa mucho más lenta,
comparada con la ejecución directa del código máquina en la CPU del ordenador. Una técnica utilizada
para mejorar las prestaciones es la compilación en tiempo de ejecución, que convierte las secuencias
ejecutadas más frecuentes en código máquina del ordenador.
Muchos lenguajes interpretados son primero compilados a código byte, que luego es normalmente
interpretado por la máquina virtual usando la compilación en tiempo de ejecución, del código byte a código
nativo. Sin embargo, algunas veces, el código byte también puede ser compilado a un binario nativo
usando un compilador Ahead-of-time compilation (compilación por adelantado), o ejecutado nativamente,
por el procesador hardware.
Java (se compila en código byte Java para que sea interpretado por la JVM)
Groovy
Join Java
ColdFusion
Scala
Lua
.NET Framework (traducidos a código byte, llamado CIL)
C/C++
C#
Visual Basic .NET
Pike
Python
Squeak Smalltalk
Visual FoxPro
Lisp
AppleScript
Notas y referencias
1. AST intermediate representations (http://lambda-the-ultimate.org/node/716), Lambda the
Ultimate forum
2. A Tree-Based Alternative to Java Byte-Codes (http://citeseer.ist.psu.edu/article/kistler97treeb
ased.html), Thomas Kistler, Michael Franz
3. Trees Versus Bytes (http://central.kaserver5.org/Kasoft/Typeset/JavaTree/index.html),
BComp Honours thesis by Kade Hansson
4. Colburn, Rafe (2003). Sams Teach Yourself CGI in 24 Hours (https://books.google.cl/books?i
d=GkdEn-VewaQC&pg=PA48&dq=Interpreted+Language&hl=es-419&sa=X&ei=SYUDVfW
GAoagNt2WgIgJ&ved=0CC4Q6AEwAg#v=onepage&q=Interpreted%20Language&f=false)
(2003 edición). Estados Unidos: Sams Publishing. p. 48. ISBN 0672324040. Consultado el 13
de marzo de 2015.. Consultado el 13 de marzo de 2015.
Véase también
Lenguaje de programación
Proceso de traducción de programas
Compilador
Depurador
Lenguaje interpretado
Lenguaje compilado
Enlaces externos
DrPubaGump (http://drpubagump.ouaibou.info/) (enlace roto disponible en Internet Archive;
véase el historial (https://web.archive.org/web/*/http://drpubagump.ouaibou.info/), la primera versión (h
ttps://web.archive.org/web/1/http://drpubagump.ouaibou.info/) y la última (https://web.archive.org/web/
2/http://drpubagump.ouaibou.info/)). A tiny Interpreter written in Scheme, which provides to
interpret PUBA-GUMP (a subset of BASIC) in Scheme
IBM Card Interpreters (http://www.columbia.edu/acis/history/interpreter.html) page at
Columbia University
Obtenido de «https://es.wikipedia.org/w/index.php?title=Intérprete_(informática)&oldid=148221404»
Esta página se editó por última vez el 27 dic 2022 a las 18:26.
El texto está disponible bajo la Licencia Creative Commons Atribución Compartir Igual 3.0; pueden aplicarse
cláusulas adicionales. Al usar este sitio, usted acepta nuestros términos de uso y nuestra política de privacidad.
Wikipedia® es una marca registrada de la Fundación Wikimedia, Inc., una organización sin ánimo de lucro.