Mito I - Portabilidad

Mito I - Portabilidad

"Java es mejor que C++ porque es mas portable."

Java utiliza el concepto de maquina virtual. El código que se genera no es especifico a una plataforma en particular. Un programa nativo: la maquina virtual (VM) se encarga de traducir este código para que la maquina pueda ejecutarlo. De esta manera un código generado en Java puede correr en cualquier plataforma, en donde se haya portado la VM. Una VM es una buena idea ya que permite ahorrar el paso de compilación y linkeo, por el cual por ejemplo un código en C++ se convierte en código nativo. Otros beneficios adicionales tienen que ver con controles adicionales que se pueden implementar dentro del VM pero que no hacen a la portabilidad por lo tanto los trataremos en otro momento.

Como dije, es una buena idea. Pero no es la única forma de encarar un problema e incluye también compromisos que programador tiene que estar dispuesto a aceptar. Es por esto que el esquema de maquinas virtuales es solo un jugador mas en el mundo de la programación, y no es el futuro. El futuro parece favorecer a un esquema en donde se trata de favorecer a la diversidad. Ya han pasado los días en donde las innovaciones eran controladas por los grandes monopolios.

Que es lo que se gana con una VM en cuanto a portabilidad?
El esfuerzo de portar a una nueva plataforma se hace un poco mas simple ya que solo hay que portar la VM. De todas formas en la actualidad los compiladores de C++ (por ejemplo gcc) han sido portados a mas plataformas que Java.

Analicemos el peor de los problemas que tienen estos esquemas. Podemos hacer una analogía con un proceso de traducción. Supongamos que el código del lenguaje es español, y el código maquina es ingles. Una maquina entonces no entiende español y necesita que algo lo traduzca para poder ejecutarlo. Al traductor se le paga en tiempo de maquina, que finalmente implica dinero.

La metodología que utiliza C++ es la siguiente:
Contrata un traductor (el compilador) y le paga una sola vez para que le entregue una copia traducida de su código. Desde ese momento se olvida del problema y le da a la maquina la versión traducida. Este proceso se puede comparar con la traducción de un libro o una película.

La elección de Java:
Contrata un traductor de por vida (el VM), pagándole cada vez que necesita utilizar el código. El traductor traduce en vivo el código una y otra vez. Esto implica que el código se va a ejecutar mas lento.

Porque ha triunfado el esquema de VM ha un nivel tal de creer que cualquier otra forma de encarar el problema es anticuada. En mi opinión hay tres razones fundamentales:

1. Publicidad agresiva por parte de las empresas detrás de estos lenguajes y desinformación de los usuarios.
2. Estas empresas realizaron inversiones considerables en crear frameworks y librerías sobre el lenguaje básico para atacar cada uno de los problemas que enfrentan los programadores. Los esfuerzos por realizar la misma clase de infraestructura en C++ han sido dispersos, sin embargo esto esta cambiando y muy rápido.
3. Desconocimiento de la forma adecuada en la que hay que utilizar un lenguaje como C++. Muchos programadores han reportado que al pasar su código a Java o C# han logrado aumentar la performance. Esto se debe a que estos nuevos lenguajes son mas fáciles de utilizar y por lo tanto al programador no le es permitido cometer tantos errores. Sin embargo el precio que hay que pagar por esta facilidad de uso es muy alto. La facilidad en Java y C# se logro eliminando aquellas estructuras de C++ que no eran sencillas de utilizar como herencia múltiple y templates. Se han hecho muchos avances en el entendimiento de estas herramientas y actualmente son la base del C++ moderno. Mientras tanto Java y C# han tenido que reincorporar algunas de estas estructuras, en especial los templates. Sin embargo para poder ser introducidos el poder de los mismos ha sido nuevamente mermado (Ver por ejemplo, diferencias con C#. Un amigo me ha comentado que este ultimo párrafo es ofensivo. Yo pienso que los generics de C# son buenas estructuras, son mucho mas fácil de utilizar que los templates, eso es seguro. La idea no es desacreditar a los demás lenguajes, todos tienen lo suyo. Hay diferencias entre estos y no es malo conocerlas)
   

Como conclusión, repito mi postura: el esquema de VM es una buena idea pero no es la única y al encarar un problema hay que hacer una elección teniendo en cuenta los compromisos de cada uno de los lenguajes que tenemos a nuestra disposición. El futuro se basa en la diversidad y en protocolos estándar que comuniquen a los diferentes jugadores. Los monopolios han caído, es hora de aprender cuales son nuestras opciones y ejercer nuestro derecho a elegir.