¿Es Ruby realmente un lenguaje interpretado si todas sus implementaciones se compilan en código de bytes?

Question

En la respuesta elegida para esta pregunta sobre rubí azul, Chuck dice:

Todas las implementaciones actuales de Ruby se compilan en Bytecode.Al contrario de las afirmaciones de SAP, a partir de Ruby 1.9, la MRI en sí incluye un compilador de código de byto, aunque la capacidad de salvar el bytecodo compilado al disco desapareció en algún lugar del proceso de fusión de la máquina virtual YARV.Jruby se compila en archivos Java .class.No tengo muchos detalles sobre Maglev, pero parece seguro decir que también tomará ese camino.

Estoy confundido acerca de este problema de compilación/interpretación con respecto a Ruby.

Aprendí que Ruby es un lenguaje interpretado y es por eso que cuando guardo cambios en mis archivos Ruby no necesito reconstruir el proyecto.

Pero si todas las implementaciones de Ruby ahora están compiladas, ¿sigue siendo justo decir que Ruby es un lenguaje interpretado?¿O estoy entendiendo mal algo?

Answer 1

Sí, sigue siendo un lenguaje interpretado de Ruby, o más precisamente, de Matz Rubí Intérprete (MRI), que es lo que la gente por lo general se habla cuando se habla de Ruby, sigue siendo un intérprete. El paso de compilación es simplemente allí para reducir el código a algo que es más rápido de ejecutar que la interpretación y reinterpretación de la misma hora de código una y otra vez.

Answer 2

Casi todos los idiomas es "compilado" hoy en día, si se cuenta el código de bytes como ser compilado. Incluso Emacs Lisp es compilado. Ruby era un caso especial porque hasta hace poco, fue no compilado en código de bytes.

Creo que tienes razón para cuestionar la conveniencia de caracterizar lenguas como "compilado" frente a "interpretado". Una distinción útil, sin embargo, es si el lenguaje crea código máquina (por ejemplo ensamblador x86) directamente desde el código de usuario. C, C ++, muchos Lisps, y Java JIT habilitado con hacer, pero Ruby, Python, Perl y no lo hacen.

Las personas que no saben mejor será llamar a cualquier idioma que tiene un paso separado guía para la compilación "compilado" y los que no "interpretados".

Answer 3

Una pregunta realmente sutil...Solía ​​ser que los lenguajes "interpretados" se analizaban y transformaban en una forma intermedia que era más rápida de ejecutar, pero la "máquina" que los ejecutaba era un programa bastante específico del lenguaje.En cambio, los idiomas "compilados" se tradujeron a las instrucciones de código de máquina admitidas por la computadora en la que se ejecutó.Una de las primeras distinciones fue muy básica: estática vs.alcance dinámico.En un lenguaje de tipo estático, una referencia de variable podría prácticamente resolverse en una dirección de memoria en unas pocas instrucciones de máquina: se sabía exactamente a qué parte del marco de llamada se refería la variable.En los idiomas escritos dinámicamente había que buscar (en una lista A o en un marco de llamada) la referencia.Con el advenimiento de la programación orientada a objetos, la naturaleza no inmediata de una referencia se expandió a muchos más conceptos: clases (tipos), métodos (funciones), incluso interpretación sintáctica (DSL integrados como expresiones regulares).

De hecho, la distinción, que se remonta quizás a finales de los años 70, no era tanto entre compilaciones e interpretaciones. idiomas, sino si se ejecutaron en un entorno compilado o interpretado.Por ejemplo, Pascal (el primer idioma de alto nivel que estudié) se presentó por primera vez en UC Berkeley con el programa de Bill Joy. pxp intérprete, y más tarde el compilador que escribió PCC.Mismo lenguaje, disponible tanto en entornos compilados como interpretados.

Algunos lenguajes son más dinámicos que otros, el significado de algo (un tipo, un método, una variable) depende del entorno de ejecución.Esto significa que, compilado o no, existe un mecanismo de tiempo de ejecución sustancial asociado con la ejecución de un programa.En cuarto lugar, Smalltalk, NeWs, Lisp, todos fueron ejemplos de esto.Inicialmente, estos lenguajes requerían tanto mecanismo para su ejecución (a diferencia de un C o un Fortran) que eran naturales para la interpretación.

Incluso antes de Java, hubo intentos de acelerar la ejecución de lenguajes complejos y dinámicos con trucos, técnicas que se convirtieron en compilación por subprocesos, compilación justo a tiempo, etc.

Sin embargo, creo que fue Java, que fue el primer lenguaje ampliamente difundido, el que realmente enturbió la brecha entre compilador e intérprete, irónicamente no para que se ejecutara más rápido (aunque eso también), sino para que se ejecutara en todas partes.Al definir su propio lenguaje de máquina y "maquinar" el código de bytes de Java y la VM, Java intentó convertirse en un lenguaje compilado en algo parecido a cualquier máquina básica, pero no en una máquina real.

Los lenguajes modernos combinan todas estas innovaciones.Algunos tienen la naturaleza dinámica, abierta y de "no sabes lo que obtienes hasta el tiempo de ejecución" de los "lenguajes interpretados" tradicionales (ruby, lisp, smalltalk, python, perl(!)), algunos intentan tener el rigor de la especificación que permite una detección profunda de errores estáticos basada en tipos de lenguajes compilados tradicionales (java, scala).Todos se compilan en representaciones reales independientes de la máquina (JVM) para obtener una semántica de escritura una vez y ejecución en cualquier lugar.

Entonces, compilado vs.¿interpretado?Lo mejor de ambos, diría yo.Todo el código está en la fuente (con documentación), cambie cualquier cosa y el efecto es inmediato, las operaciones simples se ejecutan casi tan rápido como el hardware puede hacerlo, las complejas son compatibles y lo suficientemente rápidas, los modelos de hardware y memoria son consistentes en todas las plataformas.

La mayor polémica en los lenguajes hoy en día es probablemente si se escriben estática o dinámicamente, es decir, no qué tan rápido se ejecutarán, sino si el compilador encontrará los errores de antemano (a costa de que el programador tenga que especificar tipos de escritura bastante complejos). información) o los errores surgirán en las pruebas y la producción.

Answer 4

Puede ejecutar programas de Ruby interactivamente utilizando IRB , el Rubí intérprete interactivo. Si bien puede generar código de bytes intermedia, que ciertamente no es un "compilador" en el sentido tradicional.

Answer 5

Un compilado lenguaje generalmente se compila en código de máquina, en lugar de simplemente el código de bytes. Algunos generadores de código de bytes realmente pueden recopilar aún más el código de bytes en código máquina sin embargo.

código de bytes en sí es sólo un paso intermedio entre el código literal escrito por el usuario y la máquina virtual, que todavía tiene que ser interpretado por la máquina virtual, aunque (como se hace con Java en una máquina virtual Java y PHP con una caché de código de operación ).

Answer 6

Este es posiblemente un poco fuera de tema, pero ...

hierro rubíes es una aplicación basada en .NET de rubí y por lo tanto, generalmente se compila a código de bytes y luego JIT compilado a lenguaje de máquina en tiempo de ejecución (es decir, no interpretada). También (al menos con otros lenguajes .NET, así que supongo que con el rubí) NGEN se puede utilizar para generar un binario nativo compilado antes de tiempo, por lo que es efectivamente una versión en código máquina compilado de código ruby.

Answer 7

En cuanto a la información que obtuve de RubyConf 2011 en Shanghai, Matz está desarrollando un 'MRuby' (siglas de Rubí de Matz) a la orientación que se ejecuta en dispositivos embebidos. Y Matz dijo que la del MRuby, proporcionará la capacidad para compilar el código de rubí en código máquina para aumentar la velocidad y reducir el uso de los recursos (limitados) en los dispositivos integrados. Por lo tanto, hay diversos tipos de aplicación Ruby y definitivamente no todos ellos son sólo interpretaron durante el tiempo de ejecución.