[C&P]:"Me llama la atención la tendencia existente en la industria del desarrollo software en pro de plataformas que, en lugar de generar directamente código nativo, generan algún tipo de bytecode que será ejecutado por una máquina virtual. Tal es el caso Java y .NET. Sin embargo, cuando dedico un rato a reflexionar sobre esta tendencia, pronto concluyo que esta aproximación tan extendida hoy en día no tiene ninguna ventaja y sí numerosos inconvenientes"
Comentarios
Para algunas aplicaciones es imprescindible disponer de código independiente del hardware. El software para móviles, ejemplo estrella. Y sólo por esto ya se justifica que siga habiendo java... Sobre .Net no hablo, que no sé.
#2 Es decir, una maquina virtual ( acabas de dar una de sus descripciones: lenguaje bien especificado para el que no existen compiladores dependientes del sistema operativo ni de la arquitectura hardware).
Sin embargo, voy a hacer un matiz, para mi la maquina virtual de Java la veo tremendamente util, sin embargo la de .Net no, ya que vas necesitar usar algun SSOO de Microsoft. (Si, existe Mono, pero para usar Mono tal y como esta a dia de hoy, casi mejor usar Wine).
Por tanto con .net estamos hablando unica y exclusivamente de PCs x86 o PocketPC que usen windows, para esto SI que es una cagada usar una maquina virtual.
Puede que a lo que te refieras es a algo similar a lo que hace Apple con Java. Java en MacOSX esta integrado por completo en el propio SSOO, el Java de MacOSX lo da la propia Apple.
En mi opinion el autor esta usando el termino "maquina virtual" cuando se refiere en realidad a "interprete de lenguaje de programacion". Personalmente, donde este un buen compilador que se quiten los interpretes por buenos que sean.
El rendimiento de un programa interpretado siempre sera inferior al de un programa compilado, porque tienen que ejecutarse las intrucciones del programa interprete al tiempo que las del programa en ejecucion. Ademas las optimizaciones de codigo no se pueden hacer ni de lejos con la efectividad que en los compiladores.
La seguridad y portabilidad de un lenguaje interpretado, no te la da el hecho de ser un lenguaje interpretado sino el programa interprete que puede ser bueno o malo, eficiente o menos, seguro o lleno de bugs. La portabilidad depende de que el fabricante desarrolle versiones de su interprete para cada sistema. A dia de hoy es mas portable el C standar que el java, ya que funcionaria en maquinas para las que Sun jamas pensaria en diseñar un interprete de java.
La solucion ideal seria un lenguaje que disponga de interprete para el desarrollo rapido y depuracion en la maquina del desarrollador, a la vez que compilador (o bateria de compiladores) para generar un codigo eficiente, y optimizado a la maquina donde se usara. Conoci alguna version de BASIC que tenia esa posibilidad. Pero con la complejidad de los sistemas actuales no creo que ninguna empresa afronte el costo de desarrollo de este tipo de soluciones.
Al final, es solo un tema del que podemos dialogar a nivel teorico. La realidad nos fuerza a escoger entre los sistemas de desarrollo comerciales, el que mejor se ajuste a nuestras necesidades, y no el que deseariamos usar (que tal vez no exista). Aunque tecnologicamente sea una mierda, o deje mucho que desear, lo usaremos porque economicamente resulta rentable.
No he tenido prácticamente oportunidad de programar en Java, pero sí en .Net, y realmente llega a ser desesperante encontrarte que de repente algo está fallando, miras el código una y otra vez, no ves nada raro, consultas por internet, y resulta que el fallo está en la máquina virtual cuando intentas ejecutar una acción concreta porque ha accedido a una zona de memoria prohibida... Para eso prefiero programar en C++, manejando yo mismo los punteros y direcciones de memoria y sabiendo lo que hago, que sí, que será más complicado, pero no has de depender de los bugs de otros.
Java y .net no son mas que flipes mentales de cuatro que han sabido vender muy bien los de marketing...
Ni tienen rendimiento, ni son simples, ni tiene sentido el concepto de caja de arena... Enhorabuena por el post.
Si no, leed:
Michael Schumacher llega a casa después de un duro día de entrenamiento en el circuito.
Su mujer le recibe con un beso y le pregunta:
- "¿Cómo ha ido hoy el día, cariño?"
- "Bueno, cuando he llegado al circuito, he ido a boxes y el F1 no estaba en su sitio. En su lugar había un burro."
- "¿Cómo?", se sorprende la mujer.
- "Si, así es. Le he preguntado al jefe de equipo y me ha confirmado que habían cambiado el monoplaza por el burro."
- "¿Y tu que le has contestado?"
- "Pues yo le he dicho que quizás no seria tan rápido como el F1. Él ha dicho que ciertamente es así, pero que ahora tenemos una ventaja y es que podremos correr en todo tipo de circuitos: F1, rally, motocross, trail sin... Y bueno, al menos hoy he podido venir montado en él hasta casa, cosa que no podía hacer con el F1."
- "Ya. Pero si tu sólo corres en F1, ¿para que quieres poder correr en otros circuitos?"
- "Pues no lo se, la verdad. Además, después de montarme en el burro le he dicho al jefe de equipo que no era ni la mitad de cómodo que el monoplaza."
- "¿Qué ha respondido el?"
- "Simplemente ha dicho que eso no importa porque ahora podemos correr en todo tipo de circuito."
- "¡Ay Señor!, ¿Y no corres más riesgo de hacerte daño si te caes?"
- "En realidad no, porque le han puesto al burro las mismas protecciones que tiene la cabina del F1. A pesar de que hace que todavía vaya un poco mas lento. Según el jefe eso ya no tiene tanta importancia, porque ahora podemos correr en todo tipo de circuito."
- "Esta bien, enséñame el burro."
Tras salir al jardín y quedarse estupefacta con la imagen de un burro pintado de rojo, con el escudo de Ferrari pegado en la frente y una protección de F1 encima de la silla de montar, la mujer le pregunta a Michael:
- "¿Y como se llama el animal?"
- Se llama ....
- Se llama ....
- Se llama ....
- Se llama ....
- Se llama ....
- Se llama ....
JAVA !!!!!!!!
Muchos otros lenguajes que no usan maquina virtual funcionan de manera muy similar a los que tienen maquina virtual. Así que el problema no radica ahí.
Estoy de acuerdo en casi todo lo que dice el artículo. La ventaja que veo a las máquinas virtuales es que ahorras tener que instalar programas muy grandes que pertenezcan a la misma M.V. cada vez, sino que la mayoría de las bibiliotecas, están en la máquina virtual, si, ya sé que existen las DLLs, pero también conozco el infierno que representan.
El problema sería que si hay demasiadas máquinas virtuales, el remedio es peor que la enfermedad, debería aceptarse una biblioteca virtual estándar, abierta y libre, e ir adaptándose a ésta.
Existen proyectos en un estado muy avanzado de desarrollo para que cualquier programa que funcione en la máquina virtual de Java, lo haga en la de .Net y en la de Mono: http://dev.mainsoft.com/, y también proyectos en el otro sentido para que todo programa que corra en Mono y .Net lo haga en la J.V.M https://net2java.dev.java.net/.
Ahora que Sun y Microsoft están firmando acuerdos de colaboración, puede que el sueño de un estándar que nos haga la vida más fácil, es posible.
http://www.diarioti.com/gate/n.php?id=6864
http://www.vnunet.es/Actualidad/Noticias/Inform%C3%A1tica_profesional/Acuerdos/20050517001
http://www.idg.es/computerworld/articulo.asp?id=166905
#4 Bfff ese chiste es tan viejo como Java. Si bien tiene algo de razón, lo cierto es que con la evolución de las máquinas físicas se ha mejorado mucho el rendimiento de las virtuales, aparte de que cada vez se optimizan mucho más. Alguna ventaja tiene que tener java para que msoft las haya copiado en .net, digo yo, aunque la más importante, que es el hecho de ser multiplataforma, se la hayan cargado.
De todas formas no se porqué hay esa cultura contra java por parte de los desarrolladores, tienes cientos de lenguajes a escojer, multiplataforma o monoplataforma para desarrollar en el sistema operativo que tu elijas. Los hay mejores y peores, mas y menos intuitivos. Elige el que más te guste y no utilices los que veas innecesarios. Yo por ejemplo, elegí .net para desarrollar bajo Windows una aplicación para mi empresa, y luego me arrepentí de no haber elegido java porque mi jefe se empeñó en comprarse un mac, así que Paralels al canto y otra licencia de windows para el jefe!
El código independiente del hardware no requiere de ninguna máquina virtual (basta por ejemplo con un lenguaje bien especificado para el que existan compiladores para varios sistemas operativos o arquitecturas hardware).
Creo que las máquinas virtuales vienen impulsadas por la industria por un interés económico, es decir, tienen que vendernos la moto de nuevo impulsando una "nueva" tecnología que data de hace ya décadas.
Un contra-ejemplo es Linux, el código se compila en cualquier plataforma, por eso Java no tiene tanto avance en el escritorio Linux.
Personalmente he compilado aplicaciones Linux en diferentes plataformas, tan fácil como hacer "make" y esperar. ¿ Para qué necesito entonces un bytecode o código intermedio ?