Portada
mis comunidades
otras secciones
#5:
Según jcarlosn:
Si tienes un intérprete y te ejecuta un proceso por el culo un intérprete: Es fallo de segmentación
Si tienes un intérprete y te ejecuta un proceso por el culo una máquina virtual mientras está virtualizado: Sería fallo de segmentación, pero es imposible
Si tienes un intérprete y te ejecuta un proceso por el culo una máquina virtual mientras no está virtualizado: No es fallo de segmentación
Si tienes un intérprete y y te ejecuta un proceso por el culo un intérprete: Es violación de segmento esté o no virtualizado
Si tienes una máquina virtual y te ejecuta un proceso por el culo una máquina virtual: Tú tienes un desbordamiento de búfer pero no existe ningún bug
O algo así...
Si tienes un intérprete y te ejecuta un proceso por el culo un intérprete: Es fallo de segmentación
Si tienes un intérprete y te ejecuta un proceso por el culo una máquina virtual mientras está virtualizado: Sería fallo de segmentación, pero es imposible
Si tienes un intérprete y te ejecuta un proceso por el culo una máquina virtual mientras no está virtualizado: No es fallo de segmentación
Si tienes un intérprete y y te ejecuta un proceso por el culo un intérprete: Es violación de segmento esté o no virtualizado
Si tienes una máquina virtual y te ejecuta un proceso por el culo una máquina virtual: Tú tienes un desbordamiento de búfer pero no existe ningún bug
O algo así...
#25:
Me gustan las discusiones semánticas por lo absurdas que son.
Está claro que no hay una definición establecida de la diferencia entre 'intérprete' y 'máquina virtual'. Eso salta a la vista precisamente por los problemas que estais teniendo para poneros de acuerdo: cada uno dice una cosa diferente.
Por ese mismo motivo, no me vale como argumento que Perl|PHP|NosequéDeGoogle|Java se haga llamar Intérprete|MV, pues al no haber una diferencia clara y estandarizada entre ambos conceptos, es probable que más de uno haya elegido la definición que más le gustaba o con mayor caché(MV). Por otro lado si Google dijera que V8 es una manzana, no os estariais cuestionando la definición de manzana.
En mi opinión (ni meditada, ni soy en absoluto experto en el tema), el término 'intérprete' es mucho más antiguo que MV, y puede acarrear connotaciones negativas (hace unos años un intérprete era algo muuuy lento), de ahi que en la evolución de estos entornos se acuñara un término nuevo (MV) que también podría incluir nuevas funcionalidades, mientras que otros han seguido utilizando el término 'intérprete' habiendo añadido las mismas funcionalidades.
Está claro que no hay una definición establecida de la diferencia entre 'intérprete' y 'máquina virtual'. Eso salta a la vista precisamente por los problemas que estais teniendo para poneros de acuerdo: cada uno dice una cosa diferente.
Por ese mismo motivo, no me vale como argumento que Perl|PHP|NosequéDeGoogle|Java se haga llamar Intérprete|MV, pues al no haber una diferencia clara y estandarizada entre ambos conceptos, es probable que más de uno haya elegido la definición que más le gustaba o con mayor caché(MV). Por otro lado si Google dijera que V8 es una manzana, no os estariais cuestionando la definición de manzana.
En mi opinión (ni meditada, ni soy en absoluto experto en el tema), el término 'intérprete' es mucho más antiguo que MV, y puede acarrear connotaciones negativas (hace unos años un intérprete era algo muuuy lento), de ahi que en la evolución de estos entornos se acuñara un término nuevo (MV) que también podría incluir nuevas funcionalidades, mientras que otros han seguido utilizando el término 'intérprete' habiendo añadido las mismas funcionalidades.
#7:
#6 En primer lugar, yo siempre he sabido que no son la misma cosa yo también soy alguien "de la profesión".
En segundo lugar, partiendo de que no son la misma cosa, yo he pedido una diferencia técnica, tu has dado una que hace aguas, v8 de google interpreta código de alto nivel, pero es una VM, según google, aunque pueden estar equivocados.
Yo creo que tienes el java en la cabeza todo el rato, pero bueno, leete el artículo y verás que no ha sido hecho para escarnio de nadie, y si quieres, podemos debatirlo tranquilamente, lo cual sería bonito y enriquecedor, pero claro, parece que tu ya eres "alguien de la profesión" el cual lo sabe todo, y nada puede enriquecerle.
En segundo lugar, partiendo de que no son la misma cosa, yo he pedido una diferencia técnica, tu has dado una que hace aguas, v8 de google interpreta código de alto nivel, pero es una VM, según google, aunque pueden estar equivocados.
Yo creo que tienes el java en la cabeza todo el rato, pero bueno, leete el artículo y verás que no ha sido hecho para escarnio de nadie, y si quieres, podemos debatirlo tranquilamente, lo cual sería bonito y enriquecedor, pero claro, parece que tu ya eres "alguien de la profesión" el cual lo sabe todo, y nada puede enriquecerle.
#8:
He de destacar que las conclusiones presentadas en el artículo coinciden, en términos generales, con las últimas investigaciones de la UNCA al respecto¹
¹ http://uncainc.appspot.com/surveys/on-the-social-impact-of-interpreters-and-virtual-machines/
¹ http://uncainc.appspot.com/surveys/on-the-social-impact-of-interpreters-and-virtual-machines/
Comentarios
Según jcarlosn:
Si tienes un intérprete y te ejecuta un proceso por el culo un intérprete: Es fallo de segmentación
Si tienes un intérprete y te ejecuta un proceso por el culo una máquina virtual mientras está virtualizado: Sería fallo de segmentación, pero es imposible
Si tienes un intérprete y te ejecuta un proceso por el culo una máquina virtual mientras no está virtualizado: No es fallo de segmentación
Si tienes un intérprete y y te ejecuta un proceso por el culo un intérprete: Es violación de segmento esté o no virtualizado
Si tienes una máquina virtual y te ejecuta un proceso por el culo una máquina virtual: Tú tienes un desbordamiento de búfer pero no existe ningún bug
O algo así...
Me gustan las discusiones semánticas por lo absurdas que son.
Está claro que no hay una definición establecida de la diferencia entre 'intérprete' y 'máquina virtual'. Eso salta a la vista precisamente por los problemas que estais teniendo para poneros de acuerdo: cada uno dice una cosa diferente.
Por ese mismo motivo, no me vale como argumento que PerlPPHPNosequéDeGoogleJJava se haga llamar IntérpreteMV, pues al no haber una diferencia clara y estandarizada entre ambos conceptos, es probable que más de uno haya elegido la definición que más le gustaba o con mayor caché(MV). Por otro lado si Google dijera que V8 es una manzana, no os estariais cuestionando la definición de manzana.
En mi opinión (ni meditada, ni soy en absoluto experto en el tema), el término 'intérprete' es mucho más antiguo que MV, y puede acarrear connotaciones negativas (hace unos años un intérprete era algo muuuy lento), de ahi que en la evolución de estos entornos se acuñara un término nuevo (MV) que también podría incluir nuevas funcionalidades, mientras que otros han seguido utilizando el término 'intérprete' habiendo añadido las mismas funcionalidades.
He de destacar que las conclusiones presentadas en el artículo coinciden, en términos generales, con las últimas investigaciones de la UNCA al respecto¹
¹ http://uncainc.appspot.com/surveys/on-the-social-impact-of-interpreters-and-virtual-machines/
#6 En primer lugar, yo siempre he sabido que no son la misma cosa yo también soy alguien "de la profesión".
En segundo lugar, partiendo de que no son la misma cosa, yo he pedido una diferencia técnica, tu has dado una que hace aguas, v8 de google interpreta código de alto nivel, pero es una VM, según google, aunque pueden estar equivocados.
Yo creo que tienes el java en la cabeza todo el rato, pero bueno, leete el artículo y verás que no ha sido hecho para escarnio de nadie, y si quieres, podemos debatirlo tranquilamente, lo cual sería bonito y enriquecedor, pero claro, parece que tu ya eres "alguien de la profesión" el cual lo sabe todo, y nada puede enriquecerle.
TL;DR
pd: no, es coña, buen artículo
#1 leete el artículo por favor, por que además hay un enlace a tu user en meneame, y una explicación de por que, tu teoría es errónea. Una pista: v8 de google.
Yo he pensado que tanto era que a compilación jit de .NET y java generaba código nativo, mientras que python lo que genera es un fichero binario con estructuras internas similar al bytecode, pero no más allá.
Vésae http://docs.python.org/library/dis.html
Aunque para python también está psyco http://psyco.sourceforge.net/introduction.html
Además, en documentación de python usan la expresión máquina virtual para el subcojunto del interprete que se encarga de ejecutar el bytecode.
En general usamos la expresión interprete para cuando hablamos de lenguajes dinámicos, pero eso también está cambiando, en el caso de parrot los desarrolladores hablan de máquina virtual también http://en.wikipedia.org/wiki/Parrot_virtual_machine
Para decir que sinceramente no los sé estoy escribiendo demasiado.
#12 eso es una diferencia real, y cierta, pero es mas bien filosofica, al final, esto lo vemos en interpretes, y luego vemos VM que prácticamente no lo implementan.
Quizá lo que sucede, es que la linea entra VM e interprete, la decide un poco la implementación, y existen VM's con pocas features, e interpretes con cosas que mas bien serían de VM.
Además los de google no califican al V8 de VM, sino de "motor" diciendo claramente en la documentación que no interpreta código ni bytecode "V8 compiles JavaScript source code directly into machine code when it is first executed. There are no intermediate byte codes, no interpreter.".
Entonces no se puede poner de ejemplo como "interprete que lo demoninan vm"...
Por cierto, muy buena pinta al V8 de google, un diseño elegante para mejorar el tiempo de ejecución de javascript.
Pues yo no veo donde está el lío.
¿Por qué?
Muy fácil, un interprete no produce un programa como resultado de la traducción del código fuente sino que va ejecutANDO las operaciones. En el caso de las máquinas virtuales sin embargo, primero se COMPILA el código fuente a un programa destino, sólo que este en lugar de ser código nativo de la máquina, lo es para una máquina virtual.
En la práctica se también bastante fácil. Un script en PHP con un error por ejemplo puede funcionar siempre y cuando no se llegue a ejecutar esa parte mientras que un programa en Java con ese mismo error fallará en compilación.
En todo caso podría aceptar que una máquina virtual tiene un interprete del bytecode eso es cierto y ahí puede estar la confusión pero es que ha sido necesario un compilador para obtener ese bytecode con las fases que eso supone mientras que para los lenguajes interpretados la única pieza es el interprete.
Yo creo que la diferencia es de marketing. Ya lo dice el artículo cuando expone que todo el que piensa en una VM lo asocia a Java.
Estoy completamente de acuerdo con #21. La diferencia es de marketing. Hace tiempo, los intérpretes tenían mala fama debido a que con el hardware que había se hacían lentos. De hecho, el Clipper, que precompilaba código, se decía que era un pseudo-intérprete.
Con la mejora del hardware aumentó el rendimiento de un software interpretado, pero había que quitar esa mala fama de los intérpretes, así que se le puso el nombre de Máquinas Virtuales.
#9 python hace exactamente eso...yo también lo pensé, de hecho, parece una diferencia, pero hoy en día no lo es, ya que los interpretes están muy avanzados.
Magnífico el artículo. Lo primero realmente bueno que leo hoy por aquí. Muchas gracias.
En mi opinión (y no solo la mía supongo) una VM define una arquitectura virtual, con su juego de instrucciones y todo (que pueden ser de mas o menos alto nivel, eso no tiene mucho que ver). Esta arquitectura debe ser consistente en todas las implementaciones que se hagan de la VM independientemente de la arquitectura real sobre la que funcione. Un interprete no hace eso solo interpreta el código que le llega (de alto nivel o bajo nivel, que más da) y hace lo que tenga que hacer para ejecutarlo. Algunos interpretes harán una compilación "on the fly" a bytecode y lo guardara para no tener que hacerlo más veces, pero eso no lo convierte en una VM, puesto que para empezar ese bytecode es de esa implementación del intérprete y puede variar entre versiones, arquitecturas... no esta definido, lo definido es el lenguaje a interpretar no como interpretarlo.
Por cierto es tarde y no he leido todos los comentarios, solo el artículo y poco más, pero a bote pronto #37 va por esta línea
Intérprete ----digievoluciona----> Máquina virtual
Desde mi profunda ignorancia creo que técnicamente la VM es una evolución lógica de todo interprete que es mejorado hasta tal punto de redefinir su diseño conceptual previo.
Ahí queda eso.
Creo que el artículo de Wikipedia pone las diferencias. Existen 2 tipos de máquinas virtuales:
- 1) System virtual machines
- 2) Process virtual machines
Un interprete es una máquina virtual de proceso (2).
De tal manera que todo interprete es una máquina virtual, pero no toda máquina virtual es un interprete. Dependiendo si consideras que para ser máquina virtual ha de interpretar bytecodes (que en el artículo se supone que no).
genial enfoque #25
De hecho, mucha gente piensa que primero nacieron los interpretes, y luego fueron evolucionado, se les agregó un recolector de basura, compilación a código medio, entre otras cosas, y con esas features, ya era algo mas, y pasó a llamarse MV a algo que antes era interprete.
Podríamos entonces decir, como bien dice #20 que una VM es un interprete con una capa de middleware.
De hecho, creo que eso encaja bastante con #21 y #28, es decir, los interpretes evolucionan, pero tienen mal nombre, pues se acuña un nuevo nombre, aprovechando que han evolucionado, y se puede argumentar que ya no son lo mismo.
#20 Sí, es cierto que se puede tener cierta seguridad descansando sobre la abstracción que ya ofrece el SO, sin embargo pueden aparecer situaciones más complicadas que a simple vista no podríamos imaginar. A este respecto recomiendo, por ejemplo, este artículo http://www.cs.virginia.edu/~nrp3d/papers/computers_and_security-net-java.pdf. Dejando de lado la comparativa que hace, con la que se puede estar o no de acuerdo, muestra algunas de las posibles vulnerabilidades inherentes a la VM misma que podrían dar privilegios no otorgados a código malicioso en ejecución.
La verdad es que actualmente, si has diseñado un lenguaje de programación y quieres que sea competitivo, en lugar de hacer un simple intérprete, ya haces algo más, que sería la VM, con la cual puedes (o podrías en un futuro) ofrecer una capa middleware sobre la que pudieran descansar otras tecnologías. Es decir, la VM sería como un intérprete visto con mayor amplitud de miras y con ánimo de implantarlo como capa y no como aplicación. Como consecuencia, los requerimientos de diseño pueden variar, aunque lo que veamos los usuarios (programadores o usuarios finales) sea prácticamente lo mismo.
Opino que la diferencia principal es que la VM está diseñada con la intención de ofrecer permanentemente una capa middleware para la ejecución de código, ya sea intermedio o no, mientras que el intérprete no implica esto necesariamente.
Un intérprete interpreta código, punto. No implica nada más. Puede diseñarse sin tomar en consideración los requerimientos que supondría mantener una capa de abstracción permanente, como puede ser la seguridad, etc.
Me ha picado la curiosidad, y he visitado esa fuente de sabiduria que el la wikipedia
http://en.wikipedia.org/wiki/Interpreter_(computing)
Donde denominan a la JVM un interprete de tercer nivel, es decir
Interpeter type 3.- explicitly executes stored precompiled code[1] made by a compiler which is part of the interpreter system
Para mi - quizás sea fruto de como he aprendido informatica que de una diferencia técnica real - veo el interprete como algo más simple que la VM de proceso: esta última utiliza codigo precompilado, multihilo ( mejor con threads nativos y no 'green threads'), compilador JIT, etc...
Un interprete intenta ejecutar un codigo dentro de un SO; una VM intenta abarcar un SO para ejecutar un codigo
Me ha gustado mucho las respuestas #9 , #37 y #35
[tambien en Desvaríos informáticos]
#13 Hombre, puede ser filosófica si se hace algo de andar por casa. Pero si me encargasen un proyecto consistente en hacer una VM, seguramente tendría en cuenta más requisitos que los que tendría con un intérprete. Sobre todo por el hecho de que ese proceso debe ofrecer garantías para la ejecución de código permanentemente y eso conlleva pensar en situaciones que pueden surgir a lo largo de la vida del proceso.
En cambio, si tuviese que hacer simplemente un intérprete, podría obviar completamente eso y centrarme en hacer que interprete el código.
Desde la humildad, creo que la MV reúne todas las características que mencionas en la entrada, mientras que los intérpretes sólo reúnen algunas
Pues yo me kedo como estaba...
#35 y dichos optimizadores le dan las caracteristicas de una maquina virtual a un lenguaje interpretado
Si tienes un perro verde y lo pintas de amarillo, pues tienes un perro amarillo... no? El caso es que aunque PHP es interpretado, el "combi" con el optimizador lo convierte en una maquina virtual, pero la diferencia es la que ya he expuesto.
Esto es como discutir si un triciclo es una bicicleta o un quad. Simplemente ya no hay ejemplos claros y puros de que es cada cosa, hay muchos matizes.
yo estoy con #31. En el caso de .NET, el código MSIL es compilado por el JIT conforme se va necesitando, pero solo una vez, es decir, si llamamos 400 veces a un metodo el metodo se compilar una sola vez y se mantiene en memoria para las demas veces que se quiera usar.
En el caso del interprete, va leyendo instruciones y ejecutandolas.
Igual me equivoco, pero asi me lo aprendi yo
Una diferencia, es que una máquina virtual tiende a tener todos sus componentes estandarizados. Por ejemplo la máquina virtual de Java tiende a que su estándar gráfico sea Swing. Python, sin embargo, no tiene una biblioteca gráfica estandarizada, se puede elegir entre varias posibilidades...
Vaya flame, me acabo de acordar de los tiempos de la asignatura de "Programación avanzada", esto era pregunta de exámen (aún me acuerdo dibujando el stack de la JVM)
Por cierto flipo con la cantidad de VM que existen:
http://en.wikipedia.org/wiki/Comparison_of_application_virtual_machines
C&P uno de los comentarios me parece bastante acertado:
A ver, así a ojo de buen cubero, corrijanme si me equivoco.
La máquina virtual crea un espacio de direcciones interno con en el que puede albergar varios procesos sobre el y abstrae totalmente a los procesos de la máquina que hay por debajo resolviendo ella misma por ejemplo problemas de acceso a recursos.
El interprete es un solo proceso, si queremos lanzar X programas interpretados se lanzan X procesos interprete y en este caso los programas luchan individualmente por los recursos de la máquina.
#13 No, no me referia a ese tipo de errores en #9 (ups editaste mientras yo posteaba)
En #9 dije que se creaban una estructura interna. No pueden crearse esta estructura si la sintaxis no llega a ser correcta (me refiero a dejarse un bracket o poner algo mal, como has hecho).
Me referia al tipo de errores más "a bajo nivel". Por ejemplo, ejecutar una función que no existe, o hacer una llamada a un método o propiedad que tampoco existen.
En PHP se ejecutaría todo el código anterior al error y, cuando llegara al error, petaría. En python supongo que pasaría lo mismo (pero no lo sé).
Si en python pasase lo mismo, creo que entonces se dejaría pasar a pyc, por lo que ya tendriamos una diferencia.
PD: supongo que v8 en tiempo de compilación no checkea a ver si los métodos o las funciones existen, ya que javascript es bastante más flexible en este sentido. No me puedo imaginar ninguna manera de petar javascript sin errores de sintaxis.
#40 En mi opinión (y no solo la mía supongo) una VM define una arquitectura virtual, con su juego de instrucciones y todo (que pueden ser de mas o menos alto nivel, eso no tiene mucho que ver).
En realidad, independientemente de lo que haga java (por favor, no pensemos solo en java), una VM no tiene que modificar (y normalmente no lo hace) la inerrupt descriptor table (IDT) por lo cual, por juego de instrucciones (que no interrupciones) a que te refieres?
Yo podría decir que python tiene un juego de instrucciones homogeneo, documentado y estandar, que cumplirá cualquier interprete de python.
No veo la diferencia, este razonamiento está muy condicionado por pensar solo en java.
Aviso: hay muchas posibilidades de que me equivoque. Y quizás diga MUCHAS burradas.
Creo que la diferencia es sobre cómo ejecutan el código. Me explico:
La máquina virtual primero compila el código y se hace un bytecode "propio". Si encuentra un error, no compila. Después lo ejecuta.
En cambio el intérprete como mucho se crea una estructura inicial (por eso es capaz de comprobar errores de sintaxis antes de ejecutar nada) y después va ejecutando línea a línea. Al encontrar un error, acaba.
Lo dicho: pido disculpas si he dicho alguna burrada
#10 como ya te he comentado por chat (y para que lo vea alguien y que pueda hacer alguna prueba),
He tocado poco python, y me baso en experiencias en otros lenguajes: estaría bien hacer un código en python que intentase añadir un elemento a una variable que no sea un array.
Esto, en PHP y perl, peta en tiempo de ejecución. Se ejecuta todo el código hasta que falla. En python supongo que pasará lo mismo.
Si interpretamos el código en python supongo que petará en tiempo de ejecución. Ahora habría que mirar si se deja pasar a pyc ("compilar") y si falla en tiempo de compilación o en tiempo de ejecución.
Creo que esa es la diferencia.
PD: para el que no lo haya visto, la VM de google precompila antes de ejecutar: http://code.google.com/intl/es/apis/v8/intro.html
#19 yo creo lo contrarío: es inposible hacer un interprete sin todo esto, es decir, por como es un interprete, ya tienes al proceso en un sandbox, vaya, el sandbox, al igual que en la VM de proceso, te lo proporciona la protección de memoria del sistema operativo.
Normalmente, las VM de proceso, ejecutan una VM por proceso, exactamente igual que los interpretes, por eso, esa protección existe de forma implicita en ambas soluciones, siempre claro, dependiente del sistema operativo.
Adicionalmente, por poner un ejemplo, en un lenguaje de scripting, pongamos PHP, no puedes manipular punteros, por lo tanto, no puedes direccionarte hacía una memoría que tu quieras, para alterar otro hilo del interprete, suponiendo que no existiese protección de memoria.
Entiendo lo que quieres decir, pero no lo veo claro a la hora de pasarlo a la realidad, creo que las consideraciones de seguridad entre un interprete y una VM son muy similares, al menos en la actualidad y con los sistemas actuales.
#14 A que tipo de consideraciones te refieres exactamente?
#35 La diferencia entre máquina virtual e interprete a mí me sigue pareciendo evidente (ver #31), otra cosa es que hoy en día haya interpretes con funcionalidades de máquina virtual.
Es muy recomendable el enlace de #32
Hasta donde yo se una máquina virtual ofrece un entorno homogeneo sea cual sea la máquina sobre la que corre, mientras que el intérprete adapta el código a cada máquina. Es decir, la máquina virtual adapta la máquina al código y el intérprete adapta el código a la máquina.
#17 Pues en primer lugar, a bote pronto, la seguridad del proceso. Pondría especial atención en que no pudiese verse afectado de forma malintencionada por otros procesos que pudieran ejecutarse a lo largo de su vida. En cambio con un intérprete que se limite a ejecutar un programa y luego termine pues quizás podría relajar un poco el tema.
Por otra parte, también pondría especial atención en el uso de recursos físicos del computador y su gestión a los distintos programas interpretados que pudieran ejecutarse a la vez. Trataría de que fuese mucho más eficiente, protegido (de manera que fuese una sand-box para cada uno de ellos), etc.
Y bueno, si tuviese que hacerlo realmente me pondría a estudiar a conciencia otras posibles situaciones fruto de ese requisito; seguro que sacaría otras cosas.
Un intérprete podría tener todo esto, sin embargo no tendría por qué estar presente como requisito en la fase de diseño.
Yo creo que una MV puede alojar varios procesos y un intérprete solo uno.
1 MV --> Varios procesos
1 Intérprete --> un proceso
Pero realmente soy un ignorante en python y quién sabe en cuántos lenguajes interpretados más.
En el fondo creo que una MV es una evolución de un intérprete.
La respuesta está ahí, pero cuesta dinero
http://www.experts-exchange.com/OS/Miscellaneous/Q_22645211.html
#include
int main(){
int i;
for(i=0;i
#34 PHP es un lenguaje interpretado y sin embargo existen 'optimizadores' (APC, x-cache, Zend) que mira tu por donde lo principal que hacen es guardar el código compilado en memoria para las demás veces que se quiera usar, igualito que el JIT
Y existen más 'cosas raras', como Groovy que es un lenguaje de tipo script y sin embargo se ejecuta dentro de la máquina virtual de Java (y hace compilación JIT también).
Me da que hoy en día la diferencia entre "máquina virtual" e "interprete" es similar a la diferencia entre la aleta de un delfín y la de un tiburón: distinta evolución, mismo resultado (o casi).
Una VM no tiene porque interpretar todo el código. Puede dejar que lo ejecute directamente el hardware e interceptar solamente algunas instrucciones para mantener el control.
#41 No he pensado en java, no lo he mencionado, y no entiendo porque mencionas mi comentario para decir que lo que digo solo es aplicable a java, a menos que seas tu el que solo piensa en ello.
Por arquitectura virtual no me refiero a instrucciones del lenguaje de alto nivel sino algo a más bajo nivel, a una arquitectura hardware con sus instrucciones, sus modos de direccionamiento, etc. Python NO define eso, solo define un lenguaje de alto nivel.
Eres tu el que por máquina virtual solo piensa en java, asi que ya que te pones: parece que solo piensas en el lenguaje java no en la máquina virtual con su arquitectura, su big endian, y sus demás cosas que lo hacen muy distinto de un interprete. De hecho no solo el lenguaje java corre en máquinas virtuales java, sino otros muchos como el python que mencionas (Vease Jhyton).
Igual te interpreto mal y si que piensas en todo esto, pero desde luego no das a los demás la oportunidad de opinar, al creer que solo pensamos en "Java, un lenguaje para atraerlos a todos y atarlos en las tinieblas".
Igual si no ves la diferencia es porque estas muy condicionado por pensar solo en java
#3 Hay que ser verdaderamente memo para decir burradas como que V8 es una máquina virtual, que MSIL es interpretado, o no distinguir Phyton interpretado de Phyton precompilado.
Sobre todo eso, es aún más memo presumir de que se sabe. Especialmente cuando hablas con alguien que deja tu experiencia profesional en pañales, mientras asumes tontamente que tratas con un estudiante de primero que únicamente conoce Java, sólo porque tú eres un estudiante de segundo que acaba de salir de esa definición.
No menos memo es pedir argumentos técnicos sólo para hacer el sabihondo escupiendo una y otra vez que los argumentos técnicos aportados por los demás son filosóficos, sin pararse a pensar siquiera un segundo que te están respondiendo a una pregunta técnica sobre conceptos. Especialmente memo cuando, contra las pruebas objetivas, el único que afirma tener la verdad de dios no aporta ni un solo argumento.
Pero lo más memo de todo es que cuando pierdes la razón en una discusión (porque no la tienes), tu única acción coherente sea crear una entrada en un "blog" y publicarla con el único fin de hacer escarnio del que te ha quitado la razón con argumentos objetivos. Después de eso, llamar a tus amiguetes (#0) para que vengan detrás y te la meneen (literalmente) ya es más comprensible.
Hacer uso del karma para desautorizar, en lugar de usar argumentos, no significa que tengas ni puta idea de los conceptos que manejas. Significa únicamente que retozas como un gorrino en entornos donde la gente tiene tan poca idea como tú. Deja en paz a los que no necesitan hacer preguntas idiotas y no molestes.
Un intérprete precompila lenguaje de alto nivel y lo ejecuta.
Una máquina virtual ejecuta directamente código de bajo nivel.
Para más información:
http://es.wikipedia.org/wiki/Intérprete_(informática)
http://es.wikipedia.org/wiki/Maquina_virtual
La "paradoja" aquí sólo puede verla alguien que no tenga ni flores, creo yo.
#3 ¿Y por qué dices en el texto que te he tachado de ignorante, cuando ha sido precisamente al revés, tío hipócrita?
Tú te has encabezonado en que son la misma cosa, y cuando alguien de la profesión te da la explicación evidente (que no lo son), creas una entrada de "blog" y la enlazas para hacer escarnio de su usuario en Menéame.
Precioso. Pero que te den.