Compilado vs Lenguajes Interpretados

Un lenguaje en sí no es compilado ni interpretado, solo una implementación específica de un lenguaje lo es. Java es un ejemplo perfecto. Hay una plataforma basada en bytecode (la JVM), un compilador nativo (gcj) y un interpeter para un superconjunto de Java (bsh). Entonces, ¿qué es Java ahora? Bytecode-compilado, nativo compilado o interpretado?

Otros lenguajes, que son compilados e interpretados, son Scala, Haskell u Ocaml. Cada uno de estos idiomas tiene un intérprete interactivo, así como compilador de código de bytes o código máquina nativo.

Así que generalmente categorizar lenguajes por "compilado" e "interpretado" no tiene mucho sentido.

Empieza a pensar en términos de una: explosión del pasado

Érase una vez, hace mucho tiempo, vivía en la tierra de la informática intérpretes y compiladores. Todo tipo de alboroto se produjo sobre los méritos de uno sobre el otro. La opinión general en ese momento era algo así como:

• Intérprete: Rápido de desarrollar (editar y ejecutar). Lento para ejecutar porque cada instrucción tuvo que ser interpretada en código máquina cada vez que fue ejecutado (piense en lo que esto significaba para un bucle ejecutado miles de veces).
• Compilador: Lento para desarrollar (editar, compilar, enlazar y ejecutar. Los pasos de compilación/enlace podrían tomar mucho tiempo). Rápida ejecutar. Todo el programa ya estaba en código máquina nativo.

Una diferencia de uno o dos órdenes de magnitud en el tiempo de ejecución el rendimiento existía entre un programa interpretado y un programa compilado. Otras características distintivas puntos, mutabilidad en tiempo de ejecución del código, por ejemplo, también fueron de interés pero el mayor la distinción giraba en torno a los problemas de rendimiento en tiempo de ejecución.

Hoy en día el paisaje ha evolucionado hasta tal punto que la distinción compilada/interpretada es bastante irrelevante. Muchos los lenguajes compilados llaman a servicios en tiempo de ejecución que no son completamente basado en código máquina. Además, la mayoría de los lenguajes interpretados son "compilados" en código de bytes antes de la ejecución. Los intérpretes de código de bytes pueden ser muy eficientes y rivalizar con algunos compiladores generados código desde un punto de velocidad de ejecución de vista.

La diferencia clásica es que los compiladores generan código máquina nativo, los intérpretes leen código fuente y código máquina generado sobre la marcha usando algún tipo de sistema de tiempo de ejecución. Hoy en día quedan muy pocos intérpretes clásicos, casi todos ellos compilar en código de bytes (o algún otro estado semi-compilado) que luego se ejecuta en una "máquina"virtual.

Los casos extremos y simples:

• Un compilador producirá un ejecutable binario en el formato ejecutable nativo de la máquina de destino. Este archivo binario contiene todos los recursos necesarios, excepto las bibliotecas del sistema; está listo para ejecutarse sin más preparación y procesamiento y se ejecuta como un rayo porque el código es el código nativo para la CPU en la máquina de destino.

• Un intérprete le presentará al usuario un prompt en un bucle donde puede ingresar instrucciones o código, y al pulsar RUN o su equivalente el intérprete examinará, escaneará, analizará y ejecutará interpretativamente cada línea hasta que el programa se ejecute en un punto de detención o un error. Debido a que cada línea se trata por sí sola y el intérprete no "aprende" nada de haber visto la línea antes, el esfuerzo de convertir el lenguaje legible por humanos en instrucciones de máquina se incurre cada vez para cada línea, por lo que es lento para perros. En el lado positivo, el usuario puede inspeccionar y de lo contrario, interactuar con su programa en todo tipo de formas: Cambiar variables, cambiar código, ejecutar en modo de seguimiento o depuración... Lo que sea.

Con aquellos fuera del camino, permítanme explicar que la vida ya no es tan simple. Por ejemplo,

• Muchos intérpretes pre-compilarán el código que se les da para que el paso de traducción no tenga que repetirse una y otra vez.
• Algunos compiladores compilan no a instrucciones de máquina específicas de la CPU sino a bytecode, una especie de código de máquina artificial para una máquina ficticia. Esto hace que el programa compilado sea un poco más portable, pero requiere un intérprete de bytecode en cada sistema de destino.
• Los intérpretes de bytecode (estoy viendo Java aquí) recientemente tienden a recompilar el bytecode que obtienen para la CPU de la sección de destino justo antes de la ejecución (llamado JIT). Para ahorrar tiempo, esto a menudo se hace solo para el código que se ejecuta con frecuencia (hotspots).
• Algunos sistemas que se ven y actúan como intérpretes (Clojure, para instancia) compilar cualquier código que obtengan, inmediatamente, pero permitir el acceso interactivo al entorno del programa. Eso es básicamente la conveniencia de los intérpretes con la velocidad de compilación binaria.
• Algunos compiladores no compilan realmente, solo pre-digieren y comprimen el código. Escuché hace un tiempo que así es como funciona Perl. Así que a veces el compilador solo está haciendo un poco del trabajo y la mayor parte sigue siendo interpretación.

Al final, en estos días, interpretar vs. compilar es un trade-off, con el tiempo dedicado (una vez) a la compilación a menudo se ve recompensado por un mejor rendimiento en tiempo de ejecución, pero un entorno interpretativo que brinda más oportunidades de interacción. Compilar vs. interpretar es sobre todo una cuestión de cómo el trabajo de "entender" el programa se divide entre diferentes procesos, y la línea es un poco borrosa en estos días como idiomas y productos tratan de ofrecer lo mejor de ambos mundos.

Desde http://www.quora.com/What-is-the-difference-between-compiled-and-interpreted-programming-languages

No hay diferencia, porque "compiled programming language" y "lenguaje de programación interpretado" no son conceptos significativos. Cualquier lenguaje de programación, y realmente me refiero a cualquiera, puede ser interpretado o compilar. Por lo tanto, la interpretación y la compilación son la aplicación técnicas, no atributos de idiomas.

La interpretación es una técnica mediante la cual otro programa, el intérprete, realiza operaciones en nombre del programa siendo interpretado para ejecutarlo. Si te imaginas leyendo un programa y hacer lo que dice hacer paso a paso, decir en un pedazo de rasguño papel, eso es lo que hace un intérprete también. Una razón común para interpretar un programa es que los intérpretes son relativamente fáciles de escribir. Otra razón es que un intérprete puede controlar lo que un programa trata de hacer como se ejecuta, para hacer cumplir una política, digamos, para seguridad.

La compilación es una técnica mediante la cual un programa escrito en un idioma (el "idioma de origen" ) se traduce a un programa en otro lenguaje (el "lenguaje objeto"), que con suerte significa lo mismo como el programa original. Al hacer la traducción, es común para el compilador también tratar de transformar el programa de maneras que haga que el programa de objetos sea más rápido (¡sin cambiar su significado!). Un razón común para compilar un programa es que hay una buena manera de ejecutar programas en el lenguaje de objetos rápidamente y sin la sobrecarga de interpretar el idioma de origen en el camino.

Usted puede haber adivinado, basado en las definiciones anteriores, que estos dos las técnicas de implementación no son mutuamente excluyentes, e incluso pueden ser complementario. Tradicionalmente, el lenguaje objeto de un compilador era código máquina o algo similar, que se refiere a cualquier número de lenguajes de programación entendidos por CPUs de ordenador particulares. El el código de máquina entonces correría "en el metal" (aunque uno podría ver, si uno mira lo suficientemente de cerca, que el" metal " funciona mucho como un interprete). Hoy en día, sin embargo, es muy común utilizar un compilador para generar código objeto que está destinado a ser interpretado-por ejemplo, esto es como Java solía (y a veces todavía lo hace) trabajar. Hay compiladores que traducen otros idiomas a JavaScript, que es entonces a menudo se ejecuta en un navegador web, que podría interpretar el JavaScript, o compilar una máquina virtual o código nativo. También contamos con intérpretes para el código de máquina, que se puede utilizar para emular un tipo de hardware en otro. O bien, uno podría usar un compilador para generar código objeto que es luego el código fuente para otro compilador, que incluso podría compilar código en la memoria justo a tiempo para que se ejecute, que a su vez . . . usted consigue idea. Hay muchas maneras de combinar estos conceptos.

La mayor ventaja del código fuente interpretado sobre el código fuente compilado es PORTABILIDAD.

Si su código fuente está compilado, necesita compilar un ejecutable diferente para cada tipo de procesador y/o plataforma en la que desea que se ejecute su programa (por ejemplo, uno para Windows x86, uno para Windows x64, uno para Linux x64, y así sucesivamente). Además, a menos que su código sea completamente compatible con los estándares y no use ninguna función/biblioteca específica de la plataforma, en realidad necesidad de escribir y mantener múltiples bases de código!

Si su código fuente es interpretado, solo necesita escribirlo una vez y puede ser interpretado y ejecutado por un intérprete apropiado en cualquier plataforma! Es portable ! Tenga en cuenta que un intérprete en sí es un programa ejecutable que es escrito y compilado para una plataforma específica.

Una ventaja del código compilado es que oculta el código fuente del usuario final (que podría ser intelectual property) porque en lugar de implementar el código fuente original legible por humanos, se implementa un archivo ejecutable binario oscuro.

Un compilador y un intérprete hacen el mismo trabajo: traducir un lenguaje de programación a otro lenguaje pgoramming, generalmente más cerca del hardware, a menudo directamente código máquina ejecutable.

Tradicionalmente, "compilado" significa que esta traducción ocurre de una sola vez, es realizada por un desarrollador, y el ejecutable resultante se distribuye a los usuarios. Ejemplo puro: C++. La compilación generalmente toma bastante tiempo e intenta hacer una gran cantidad de optmización costosa para que el ejecutable resultante se ejecute más rápido. Los usuarios finales no tienen las herramientas y el conocimiento para compilar cosas por sí mismos, y el ejecutable a menudo tiene que ejecutarse en una variedad de hardware, por lo que no puede hacer muchas optimizaciones específicas de hardware. Durante el desarrollo, el paso de compilación separado significa un ciclo de retroalimentación más largo.

Tradicionalmente, "interpretado" significa que la traducción ocurre "sobre la marcha", cuando el usuario quiere ejecutar el programa. Ejemplo puro: vanilla PHP. Un intérprete ingenuo tiene que analizar y traducir cada pieza de código cada vez que se ejecuta, lo que hace que sea muy lento. No puede realizar optimizaciones complejas y costosas porque tomarían más tiempo que el ahorrado en la ejecución. Pero puede utilizar completamente las capacidades del hardware en el que se ejecuta. La falta de un paso de compilación por separado reduce el tiempo de retroalimentación durante el desarrollo.

Pero hoy en día "compilado vs.interpretado" no es una cuestión de blanco o negro, hay matices en el medio. Los intérpretes ingenuos y sencillos se han extinguido. Muchos idiomas utilizan un doble paso proceso donde el código de alto nivel se traduce a un bytecode independiente de la plataforma (que es mucho más rápido de interpretar). Luego tienes "compiladores justo a tiempo" que compilan el código como máximo una vez por ejecución de programa, a veces almacenan en caché los resultados, e incluso deciden inteligentemente interpretar el código que se ejecuta rara vez, y hacen optimizaciones poderosas para el código que se ejecuta mucho. Durante el desarrollo, los depuradores son capaces de cambiar código dentro de un programa en ejecución incluso para lenguajes compilados tradicionalmente.

En primer lugar, una aclaración, Java no es completamente estático-compilado y vinculado de la manera C++. Se compila en bytecode, que luego es interpretado por una JVM. La JVM puede ir y hacer la compilación justo a tiempo en el lenguaje nativo de la máquina, pero no tiene que hacerlo.

Más al grano: Creo que la interactividad es la principal diferencia práctica. Dado que todo se interpreta, puede tomar un pequeño fragmento de código, analizarlo y ejecutarlo en función del estado actual del entorno. Por lo tanto, si si ya hubiera ejecutado el código que inicializó una variable, tendría acceso a esa variable, etc. Realmente se presta a cosas como el estilo funcional.

La interpretación, sin embargo, cuesta mucho, especialmente cuando se tiene un sistema grande con muchas referencias y contexto. Por definición, es un desperdicio porque el código idéntico puede tener que ser interpretado y optimizado dos veces (aunque la mayoría de los tiempos de ejecución tienen algo de almacenamiento en caché y optimizaciones para eso). Aún así, usted paga un costo de tiempo de ejecución y a menudo necesitan un entorno de tiempo de ejecución. También es menos probable que vea optimizaciones interprocedurales complejas porque en la actualidad su rendimiento no es lo suficientemente interactivo.

Por lo tanto, para sistemas grandes que no van a cambiar mucho, y para ciertos lenguajes, tiene más sentido precompilar y prelazar todo, hacer todas las optimizaciones que pueda hacer. Esto termina con un tiempo de ejecución muy reducido que ya está optimizado para la máquina objetivo.

Como para generar ejecutantes, eso tiene poco que ver, en mi humilde opinión. A menudo puede crear un ejecutable a partir de un lenguaje compilado. Pero también puede crear un ejecutable a partir de un lenguaje interpretado, excepto que el intérprete y el tiempo de ejecución ya están empaquetados en el ejecutable y ocultos para usted. Esto significa que generalmente todavía paga los costos de tiempo de ejecución (aunque estoy seguro de que para algunos idiomas hay formas de traducir todo a un ejecutable de árbol).

No estoy de acuerdo en que todos los idiomas se puedan hacer interactivo. Ciertos lenguajes, como C, están tan atados a la máquina y a toda la estructura de enlaces que no estoy seguro de que pueda construir una versión interactiva completa y significativa

Es bastante difícil dar una respuesta práctica porque la diferencia está en la definición del lenguaje en sí. Es posible construir un intérprete para cada lenguaje compilado, pero no es posible construir un compilador para cada lenguaje interpretado. Se trata mucho de la definición formal de un idioma. Así que eso de la informática teórica a nadie le gusta en la universidad.

El Libro de Python © 2015 Imagine Publishing Ltd, simplemente desmiente la diferencia con la siguiente sugerencia mencionada en la página 10 como:

Un lenguaje interpretado como Python es aquel en el que el código fuente se convierte en código máquina y luego se ejecuta cada vez que se ejecuta el programa. Esto es diferente de un lenguaje compilado como C, donde el código fuente solo se convierte en código máquina una vez – el código máquina resultante se ejecuta cada vez que el programa ejecutar.

Compile es el proceso de crear un programa ejecutable a partir de código escrito en un lenguaje de programación compilado. La compilación permite al ordenador ejecutar y entender el programa sin la necesidad del software de programación utilizado para crearlo. Cuando se compila un programa, a menudo se compila para una plataforma específica (por ejemplo, IBM platform) que funciona con computadoras compatibles con IBM, pero no con otras plataformas (por ejemplo, Apple platform). El primer compilador fue desarrollado por Grace Hopper mientras trabajaba en el Computadora Harvard Mark I. Hoy en día, la mayoría de los lenguajes de alto nivel incluirán su propio compilador o tendrán kits de herramientas disponibles que se pueden usar para compilar el programa. Un buen ejemplo de un compilador usado con Java es Eclipse y un ejemplo de un compilador usado con C y C++ es el comando gcc. Dependiendo de lo grande que sea el programa, debería tomar unos segundos o minutos compilar y si no se encuentran errores mientras se compila, se crea un archivo ejecutable.compruebe esta información