Hoy se cumple el décimo aniversario del trabajo más extraño y posiblemente más triste que jamás haya tenido. El año fue 2005. Mi interés en escribir un sistema de gestión de contenido en Java para la empresa que compró nuestra startup, se había ido agotando, mientras que mi verdadera pasión era trabajar en compiladores y otra infraestructura de lenguaje de programación (principalmente SBCL). Un día descubrí un anuncio de trabajo para especialistas en compiladores, algo raro en aquel momento y lugar. Volé a la entrevista de trabajo, pero no hice las preguntas correctas e ignoré un par de señales de advertencia. Oops. Resultó ser una aventura en retrocomputing.
Comentarios
#13 en realidad, para abrir esta discusión, habría que definir muy bien que es un interprete, para ver si la jvm funciona o no como un interprete. Este debate ya ha pasado en meneame, incluso recuerdo a gallir escribiendo a Larry Wall (perl), que nos arrojo algo de luz, diciendo basicamente que la mayoría de lo que la gente hoy en día llama interpretes, son en realidad maquinas virtuales.
#22 A ver, ya en 1983, el Basic de Microsoft usaba "opcode" para codificar los programas en la memoria e interpretarlos mas rápidamente después. Y cito el Basic de Microsoft de los 80 porque es LA referencia del lenguaje interpretado.
De ahí al bytecode que usan Java o .NET en la actualidad no hay mucha diferencia.
Cuando se habla de "interpretes" se entiende por cualquier código que necesite de otro programa para poder ejecutarse, ya sea un interprete puro y duro en tiempo real o un compilador en tiempo de ejecución.
#25 claro, pero es que las cosas no son tan fáciles, como es simplificación que propones. La realidad es mas compleja que eso, abarca mas casos y no existen definiciones universalmente aceptadas en la industria para la palabra interprete.
Los programas, al ejecutarse en una plataforma específica, adoptan diferentes propiedades, derivadas de la naturaleza de ese entorno. A nivel lógico pueden pasar cosas muy diferentes, con EFECTOS muy diferenciados entre si, y tales efectos tienen un impacto muy grande en la forma en la que se trabaja en una plataforma.
El primer tipo de plataforma de computación, sería el interprete, donde el programa es evaluado linea por linea, en tiempo de ejecución por otro programa, que traduce las instrucciones del programa escritas por el programador, linea a linea, en instrucciones de código máquina que se ejecutan en el sistema físico subyacente. Esto provoca que el programador pueda ejecutar una parte del programa, incluso si mas adelante, hay una instrucción invalida o incompleta. Eso hace mas difícil el proceso de desarrollo, basicamente por dos razones. Por que el feedback de que algo está mal codiificado llega mas tarde y solo en esos codepaths. Y por que el estado puede quedar inconsistente, tras ejecutar procesos de forma incompleta, que se han detenido en puntos arbitrarios del proceso, dejando estados intermedios incompletos en el peor caso.
Luego, están las plataformas de computación donde el programa codificado por el programador, es compilado o traducido en un proceso previo a la ejecución (ya sea por orden directa del usuario, o por acción automática previa a la ejecución). El programa compilado resultante es una transformación a otro sistema de codificación de programas, válido para ejecutarse en un computador.
El computador puede ser físico o virtual, eso no tiene ningún impacto lógico en la forma en la que se realiza el proceso. Es decir, la jvm o python, son basicamente computadoras simuladas dentro de otras computadores. De ahí el nombre "máquina virtual" en este contexto, como máquina virtual de java.
Entonces, decir que interprete es toda plataforma de computación donde el código en tiempo de ejecución no se esté ejecutando de forma directa en un computador físico, es una definición muy poco útil de "interprete". Para el programador, lo que realmente va a tener impacto es si ha habido una compilación y su pertinente verificación, antes de ejecutar nada.
Además, hay el problema de que interpretado es normalmente entendido como lo contrario que compilado. Y java es compilado. Compilado no significa compilado a código máquina de la máquina física. Significa traducido de un lenguaje de programación a un código máquina (de la máquina que sea).
Por eso, decimos que java es un lenguaje compilado, y no interpretado. Igual que javascript (y por eso se llama máquina virtual de javascript, y no interprete de javascript). Igual que go, o que python.
Lenguajes de scripting que no sean DSL quedan pocos, pero hay por ejemplos el bash scripting.
#34 "no existen definiciones universalmente aceptadas en la industria para la palabra interprete."
Bien, entonces no podemos tener razón ninguno de los dos, porque cada cual puede entender lo que le de la gana...
"decir que interprete es toda plataforma de computación donde el código en tiempo de ejecución no se esté ejecutando de forma directa en un computador físico, es una definición muy poco útil de "interprete""
Ya, solo que eso es lo que significa un lenguaje interpretado.
"the term "interpreted" is practically reserved for "software processed" languages (by virtual machine or emulator) on top of the native (i.e. hardware) processor. "
https://en.wikipedia.org/wiki/Interpreted_language
Todo esto me suena a justificación de fans de Java...
Asúmelo! Java es interpretado, igual que .NET!
Puedes decir lo que quieras, pero no puedes ejecutar un programa de Java en un procesador sin que otro programa intermedio lo interprete para ejecutarlo. (igual que .NET, que para eso necesitas instalar el framework)
Porque si, una maquina virtual es un programa. Y estoy seguro de que la maquina virtual de Java no esta escrita en Java, sino en C (por ejemplo), que SI que es un lenguaje compilado porque el resultado de la compilación es un binario que se ejecuta directamente en el procesador.
Y una maquina virtual es, a fin de cuentas, un emulador. Te guste o no te guste.
Las habrá mas rápidas, mas lentas, mejores y peores. Las habrá incluso que casi casi parezcan lenguaje nativo... Pero seguirá siendo interpretado.
#36
Una computadora al completo es un emulador por definición esencial de computadora.
Si un programa es interpretado cuando en el proceso de su ejecución incluye en algún punto una emulación, entonces cualquier programa para una computadora sería interpretado por definición.
Creo que tu posición sobre esta definición es insostenible y es absurda, ya que engloba a cualquier programa que se ejecute en una computadora. Y engloba cualquier programa por dos razones: la primera, por que una computadora es una máquina de simular, ergo, la simulación forma parte de cualquier programa que se ejecute en una computadora. Y la segunda por que cualquier programa esté como esté codificado, necesita de la asistencia de otros programas (sistema operativo, microcodigo del firmware de la cpu, etc) para ejecutarse, entonces todos los programas son interpretados también en cualquier medida.
Sobre el asunto de justificación de fans de java... no se de que me está usted hablando. Yo programo y he programado en multitud de lenguajes para muchas plataformas, entre las que se encuentran C, C++ y otros lenguajes compilados a instrucciones codificadas para un dispositivo electromagnético. Eso no me hace sentirme por encima de nadie, ni pensar que argumentos cutres sobre la persona, en lugar de sobre la materia, van a resultar en una respuesta lógica.
#37 Vale, el lenguaje interpretado no existe.
#38 si, si existe. Que tu definición sea absurda no hace inexistente el concepto. Solo demuestra que es imposible que esa sea la definición lógica de interpretado.
#39 claro, si.
#6 Se te ve muy puesto en el tema.
"Mi interés en escribir un sistema de gestión de contenido en Java"
"que mi verdadera pasión era trabajar en compiladores y otra infraestructura de lenguaje de programación (principalmente SBCL)"
A nadie que le interese java le apasionan los compiladores.
#1 Totalmente: es antitético.
#1 #2 Cierto, de todos es sabido que en Java se ejecutan directamente los archivos de texto
#5 java es una mierda y si te gusta odias la computación
#9 #8 #6 Java, el nuevo KDE vs Gnome. Dejadlo estar, ya no trabajo con Java pero a mi personalmente me gusta.
#11 A mi no me parece mal... en teoría. Pero en la practica es tan eficiente como un tractor en una autopista.
#14 Bueno, yo trato de ser pragmático: Es una herramienta con sus características. Hay otras herramientas, si; mejores, también; pero cada una con sus pros y sus contras.
Lo que no entiendo es porque se ataca una herramienta a veces casi fanáticamente, es como si le gritara a mi destornillador plano porque el de carraca es mejor para ciertos tornillos, me parece tronchante ..
#5 Pues CASI. Java es un interprete en maquina virtual:
https://stackoverflow.com/questions/1326071/is-java-a-compiled-or-an-interpreted-programming-language#1326084
#8 "Java implementations typically use a two-step compilation process. Java source code is compiled down to bytecode by the Java compiler. The bytecode is executed by a Java Virtual Machine (JVM). Modern JVMs use a technique called Just-in-Time (JIT) compilation to compile the bytecode to native instructions understood by hardware CPU on the fly at runtime."
#9 Sigue siendo lenguaje interpretado. Si te hubieses leido el parrafo siguiente lo sabrías...
"While this is still considered an "interpreter," It's quite different from interpreters that read and execute the high level source code"
El .NET de Microsoft hace lo mismo, pero como esta profundamente integrado con el sistema operativo, es mucho mas eficiente que la maquina virtual de Java.
#13 Lo leí pero no quise citártelo. Pero ya que lo has hecho tú te puedo resaltar la otra parte de la frase "It's quite different from interpreters that read and execute the high level source code". Eso cuando el bytecode es interpretado, no el lenguaje de alto nivel, y mucho menos cuando es ejecutado por un compilador JIT. Ahora puedes mirar la fecha de ese comentario y buscar que implementación de la JVM que se use medianamente en la actualidad no usa compilación JIT.
#20 Sigue siendo un lenguaje interpretado, pero vamos, que si a ti te gusta pensar de otra forma me parece perfecto. Al fin y al cabo estamos en el 2018 y hoy en día la "verdad" es un concepto abierto a interpretación...
#21 "Sigue siendo un lenguaje interpretado" Porque yo lo valgo.
#23 a ver, es que si lees: "IT'S STILL AN INTERPRETER" y sigues sin creerte-lo, que quieres que te diga?
#26 A ver, que si sacas una minifrase, y encima mal citada, de su contexto para poder tener razón que quieres que te diga.
"Some implementations of JVM may choose to interpret the bytecode instead of JIT compiling it to machine code, and running it directly. While this is still considered an "interpreter," It's quite different from interpreters that read and execute the high level source code (i.e. in this case, Java source code is not interpreted directly, the bytecode, output of Java compiler, is.)
#27 Pero es que si lo que le das a la JVM es bytecode y es la JVM la que tiene que convertirlo en código nativo, eso se llama compilación en tiempo de ejecución y sigue siendo un lenguaje interpretado porque el programa en bytecode necesita de un programa intermediario que LO INTERPRETE para poder funcionar.
Pero, una vez más, no dejes que los hechos estropeen tu realidad. Si para ti es compilado, es compilado y ya esta.
#2, ¿y por qué no le iban a gustar las teticas?
#15 BADUM-TSSS!!
#10 Es lo que me gustó del artículo, tuve que ver que narices era PL/M .. entre otras cosas.
#12 En los 80, recuerdo que mi padre tenia un manual de PL/M en una estantería junto con montones de otros manuales y documentación técnica. Resultó que ni el sabia lo que era, pero lo guardó por si acaso le hacia falta algún día...
)
(reparaba electrónica)
...
(nunca le hizo falta.
#16
Bueno, yo empecé con CP/M Plus y según leí ayer, estaba basado en el PL/M del carajo.
#c-18" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3029872/order/18">#18 joder, siempre me pregunté que era el CP/M... yo pase del Basic al ensamblador y luego del Pascal al C++ en PC. Ahora solo programo en C# y en HLSL
#29 Ojo, es un sistema operativo, no un lenguaje. Era parecido a lo que luego fue DOS. Yo lo tuve en un AMSTRAD PCW 8256 y fue funcional hasta mediados de los 90's (se utilizaba como procesador de textos mayormente).
http://www.seasip.info/Cpm/
#30 Como ves, no tengo ni idea de CP/M...
Cuando llegué a "Visual Studio 6" dejé de leer
#3 Yo sentí pena. Lo bueno que tiene el artículo es como describe los sistemas que se utilizaban en los 80's ..
#3 Claro, porque programar en PL/M tiene pinta de ser mucho mejor!
#3 yo el otro día me encontré un libro gordo de Visual Studio 6 al lado de un container en Barcelona. Me hizo gracia y lo cogí, y me recorrí media Barcelona con el bajo el brazo. Había gente que me miraba muy fijamente, o grupos de chavales jovenes, quizás estudiantes de informática, que me señalaban o hablaban entre ellos.
Interesante, pero Posted on 2015-09-01
#32 Si, lo he hecho otras veces. Creo que no hay problema. (En este sub).
mr_b
cc
#32 Aquí, en general, no hay problema con la antigüedad de los envíos
/cc #33