¿Se interpretan siempre los lenguajes dinámicos?

18

Mirando la mayoría de los lenguajes dinámicos (si no todos) (por ejemplo, Python, PHP, Perl y Ruby), todos se interpretan. Corrígeme si me equivoco. ¿Hay algún ejemplo de lenguaje dinámico que pase por la fase de compilación? ¿Es el lenguaje dinámico idéntico al lenguaje interpretado?

— Joshua Partogi
fuente

44

Definir lenguaje dinámico, ¿está escrito dinámicamente?

— BenjaminB

3

Objective-C exhibe muchas propiedades "dinámicas".

— Edward Strange

44

@ Job, uno podría hacerlo con Lisp por décadas. Y está compilado y escrito dinámicamente. Por lo tanto, nunca hubo un límite exacto entre la compilación y la interpretación.

— SK-logic

2

@Darien También puede compilar eso en tiempo de ejecución y ejecutar código después. Estrictamente hablando, no es interpretación.

— xmm0

3

@Darien Nothing impide que un compilador almacene la información de una tabla de símbolos en el código binario compilado y genere acceso a ella en tiempo de ejecución. Es cierto que algunos idiomas se prestan a la interpretación más que a la compilación, pero el punto es que es posible tener un compilador para ese idioma. Otra cosa importante a tener en cuenta es que algunas personas suponen que un compilador tiene que generar algún tipo de código de máquina. En la práctica, hay compiladores que simplemente realizan una transformación de nivel de origen en dos idiomas (o incluso el mismo idioma, como algunos minificadores de Javascript).

— xmm0

33

Mirando la mayoría (si no todos) los lenguajes dinámicos [es decir, Python, PHP, Perl y Ruby], todos se interpretan.

No es verdad. Puede compilar la fuente de Python. Esa es una prueba existencial.

Hay intérpretes para lenguajes tipados estáticamente y compiladores para lenguajes tipados dinámicamente. Los dos conceptos son ortogonales.

Nota al margen: en general, un lenguaje es solo eso: un lenguaje, con un conjunto de construcciones sintácticas para expresar la semántica. Si escribe Python en una pizarra, ¡todavía se llama Python! Es la implementación que puede ser un intérprete o un compilador. Ser de tipo estático o de tipo dinámico (como una especie de híbrido de ambos) es una propiedad del lenguaje, mientras que la ejecución de un programa mediante interpretación o compilación es una propiedad de la implementación.

— xmm0
fuente

19

¿Con qué precisión deben coincidir las sangrías en una pizarra para que Python sea sintácticamente válido? ;)

— edA-qa mort-ora-y

1

No puedes compilar Python. PYC acelera solo la carga de un módulo. Y py2exe simplemente incrusta el intérprete en el archivo exe con el archivo fuente.

— BenjaminB

8

@ Ubiquité: los .pycarchivos son bytecode. El código fuente de Python se analizó, optimizó y compiló para crearlos. Las instrucciones de bytecode son relativamente de alto nivel y la implementación más popular es un intérprete simple (por contraste, mire PyPy, que JIT compila bytecode a código de máquina muy inteligente en tiempo de ejecución) pero Python no está menos compilado que Java o C#. Python solo "no se compila" si la "compilación" se restringió a la compilación nativa anticipada , pero nadie dijo nada al respecto y, en general, puede referirse a cualquier transformación de lenguaje a lenguaje.

44

@ Ubiquité: Sí, eso es correcto, pero eso no guarda relación con su afirmación de que "No puede compilar Python" o si es posible compilar Python. En primer lugar, estás mezclando Pythony CPython, mientras que el segundo es una implementación del primero, también lo es PyPy.

— phant0m

2

@ClemC TODAS las propiedades de un idioma están integradas en un compilador o intérprete; de lo contrario, el intérprete o compilador es algo para otro idioma.

— Pieter B

15

Common Lisp se escribe de forma dinámica (y fuerte) y generalmente se compila .

Dado que esta dinámica se logra en tiempo de ejecución, hay algunas directivas que puede usar en el código fuente para asegurar al compilador que un símbolo contendrá solo un cierto tipo de valor, de modo que el compilador pueda optimizar el código generado y aumentar el rendimiento.

— Federico klez Culloca
fuente

12

C # 4.0 admite tipos dinámicos (enlace tardío) y se compila.

— Matt H
fuente

4

node.js se basa en el motor javascript V8 de Google. V8 hace compilación en tiempo de ejecución. V8 es cegadoramente rápido dado ese hecho. Simplemente consulte http://shootout.alioth.debian.org y compare V8 con cualquiera de los idiomas interpretados anteriormente.

— LLeo
fuente

3

No, ciertamente es posible compilar lenguajes dinámicos.

Incluso hay algunos lenguajes dinámicos que siempre se compilan por diseño (por ejemplo, Clojure).

Sin embargo, la pregunta toca un punto relacionado importante: aunque los lenguajes dinámicos se pueden compilar, a menudo se da el caso de que los idiomas dinámicos no se pueden compilar en un código que sea tan eficiente como un lenguaje tipado estáticamente . Esto se debe a que hay algunas características inherentes a los lenguajes dinámicos que requieren verificaciones de tiempo de ejecución que serían innecesarias en un lenguaje compilado estáticamente.

Un ejemplo de esto: los lenguajes que permiten el parcheo de objetos en tiempo de ejecución (por ejemplo, Ruby) a menudo requieren que el objeto sea inspeccionado (con una búsqueda de tabla hash o similar) cada vez que invocas un método en el objeto. Incluso si esto se compila, el compilador tendrá que generar código para realizar la búsqueda del método en tiempo de ejecución. Hasta cierto punto, esta búsqueda de métodos no es diferente de lo que un intérprete tendría que hacer.

Esto agrega una sobrecarga significativa en comparación con una llamada a un método en un lenguaje como Java, donde el compilador puede determinar estáticamente el método correcto a partir de la definición de clase y reducirlo a una simple llamada a función en código nativo.

Creo que es este efecto, más que cualquier otra cosa, lo que hace que los lenguajes dinámicos tengan un rendimiento más lento en promedio que sus homólogos compilados estáticamente. Como puede ver en los puntos de referencia defectuosos , son los lenguajes estáticamente escritos (C, Java, Fortran, etc.) los que tienden a ser más rápidos con los lenguajes dinámicos (Perl, Python, Ruby, PHP, etc.) en la parte inferior de la clasificación.

— mikera
fuente

2

Érase una vez, BASIC fue interpretado. Y algunas variantes de BASIC tenían escritura dinámica. Y también puedes obtener compiladores para ellos.

(Esto fue en los días de las unidades de disquete de 100K, cuando los dinosaurios todavía vagaban por la tierra y comían desprevenidos desarrolladores s / w para el desayuno).

— rápidamente_ahora
fuente

... pero solo cuando usaban GOTOs. (Lo cual, por supuesto, era bastante común si se desarrollaban en BASIC. ¡AHA! ¡Eso lo explica!)

— Mason Wheeler

BASIC en su momento de diseño era un lenguaje compilado.

— Programador

2

Las diferentes implementaciones de Smalltalk manejan esto de manera diferente, pero varias de ellas se compilan en bytecodes que se ejecutan en una VM de alto rendimiento.

— Randy Coulman
fuente

2

De hecho, la mayoría de los llamados lenguajes "interpretados" pasan por / permiten una compilación justo a tiempo para que se ejecute más rápido. Y algunos de ellos deben compilarse en código de bytes antes de poder ejecutarlos.

De hecho, dinámico e interpretado son totalmente 2 ideas diferentes, aunque existe una correlación. La razón es que quien siente que la escritura dinámica hace que su trabajo sea más fácil y rápido, no les importaría que el código se ejecute un poco más lento pero portátil.

— usuario658991
fuente

1

Chrome, IE9 y Firefox 3.1+ compilan JavaScript para binarios nativos, y JavaScript se escribe dinámicamente.

Creo que la razón por la que los lenguajes dinámicos históricamente tienden a ser interpretados es porque la escritura y la interpretación dinámicas (o más específicamente, la falta de compilación) tienden a ser características útiles para los lenguajes de scripting y las tareas de scripting en general.

El rendimiento tampoco es (no fue) una gran preocupación para los tipos de programas que se escribieron en estos idiomas, por lo que, una vez más, la sobrecarga de escritura e interpretación dinámicas no fue un problema tan grande como lo sería en los idiomas ese valor de rendimiento.

— Rei Miyasaka
fuente

1

Python es, típicamente, compilado. Es cierto que se compila en un código de bytes que luego se interpreta.

Perl trabaja de manera similar.

Common Lisp, típicamente, compilará uno de código nativo o byte. Esto difiere entre implementaciones (y, hasta cierto punto, dentro de una implementación, dependiendo de varias configuraciones de optimización).

— Vatine
fuente

-5

Si. Todos los lenguajes dinámicos son lenguaje interpretado (pero un lenguaje interpretado podría ser no dinámico).

La razón es simple: si es dinámico, necesita un intérprete para realizar el dinamismo a nivel de la compilación binaria.

ex. : cuando colocamos un dato en una variable PHP, luego otro de un tipo diferente, nuestro programa no pudo compilarse en código binario ya que cada tipo tiene su propio formato de representación binaria; el intérprete gestiona los cambios a nivel binario de forma dinámica

— Mente limpia
fuente

2

Incorrecto. Se pueden compilar lenguajes dinámicos (y a veces de manera muy eficiente, por ejemplo, utilizando JIT y técnicas de compilación adaptativa)

— Basile Starynkevitch

"Aproximadamente, la compilación JIT combina la velocidad del código compilado con la flexibilidad de interpretación, con la sobrecarga de un intérprete ..." es.wikipedia.org/wiki/Just-in-time_compilation su programa no compila: es compilado por el intérprete para usted

— ClearMind

Lea los documentos relacionados con SELF

— Basile Starynkevitch

Seguro. Su enlace menciona: "Una característica de Self es que se basa en el mismo tipo de sistema de máquina virtual que usaban los sistemas Smalltalk anteriores. Es decir, los programas no son entidades independientes como lo están en lenguajes como C, pero necesitan su entorno de memoria completa para poder ejecutar ". no autónomo = sin compilación binaria, se necesita la máquina virtual para realizar la compilación binaria

— ClearMind

1

Su definición de compilador es demasiado restrictiva. No todos los compiladores producen un archivo ejecutable binario. Para un contraejemplo reciente, estudie la implementación de SBCL . Lea el último Libro del Dragón y Lisp In Small Pieces

— Basile Starynkevitch