Alternativas de Implementación

Después de muchas horas de ardua investigación y análisis se nos presentaron varias alternativas de implementación del lenguaje: Si bien tendríamos que haber definido el lenguaje en sí antes de empezar a pensar la implementación, el avance de la materia nos pide que ya planeemos todo, así que nos tenemos que comer y/o paralelizar algunas etapas que deberían ir en serie. Pensar en la implementación es una de ellas. Las alternativas (pensando en la portabilidad del entorno y el lenguaje) que se nos ocurrieron son las siguientes:

1. Lenguaje interpretado:
   Esta es la solución más directa, por decirlo de alguna forma.
   1. Todo en Java
      Facilita la creación del IDE multiplataforma, mejora la sobrecarga en cuanto el GC nos despreocupa el manejo de memoria y muchas cosas ya están implementadas cualquiera sea el sistema donde corra. Como contraparte, para la implementación del intérprete necesitamos una gestionar la memoria de las estructuras nosotros mismos, cosa que Java no nos deja.
      
   2. Todo en C/C++
      Podemos gestionar la memoria, pero la creación del IDE demandaría más tiempo del que disponemos para finalizar el proyecto.
      
   3. IDE en Java, Intérprete en C/C++
      Tomamos las ventajas de las dos implementaciones anteriores, pero se suma la conexión de ambos sistemas, que puede ser por sockets.
   A todos se añade la complejidad del intérprete y resolver dinamicamente las direcciones e invocaciones. Un aspecto negativo respecto a ser interpretado se basa en que pueden haber vínculos que no se pueden resolver, causando la terminación de los programas y problemas que no se adaptan al objetivo.
   
2. Lenguaje compilado a máquina virtual:
   Esta solución es la que más nos gusta. Las funciones de depuración se incluyen en la misma máquina virtual.
   
   1. Todo en Java
      Lo mismo que el anterior. La gestión de memoria no la vamos a poder hacer.
   2. Todo en C/C++
      Igual que antes, los tiempos de desarrollo se multiplican.
   3. IDE y Compilador en Java, Máquina Virtual en C/C++
      Facilita la creación del IDE y la conexión con el compilador. La creación de la máquina virtual es mucho más simple, dado que no es una máquina virtual corriendo sobre una máquina virtual.
      
   4. IDE en Java, Compilador y Máquina Virtual en C/C++
      Facilita la creación del IDE y la creación del compilador.
      
   5. IDE y Compilador en Java, Máquina Virtual: JVM
      Quita la necesidad de crear una máquina virtual, reemplazándola por una que ya se sabe que anda. Como contraparte, las aplicaciones tienen que adaptarse a la estructura de la máquina virtual, que nativamente ejecuta objetos.
      
   Se suma la complejidad de crear la máquina virtual junto con su repertorio de instrucciones, registros y todo lo que hace a la máquina.
   
3. Lenguaje compilado a máquina real:
   Esta solución ata mucho a la plataforma para la que se genera el binario y tendríamos que crear bibliotecas según la plataforma donde estemos parados.
   
   1. IDE y Compilador en Java, Depurador en C/C++
      Esta solución unifica el desarrollo, aunque habría que crear un compilador para cada plataforma. Dado que Java es independiente de la plataforma el depurador no se puede construir en ese lenguaje. El depurador depende de cada plataforma.
      
   2. IDE en Java, Compilador y Depurador en C/C++
      Se tiene que crear un compilador y un depurador para cada plataforma.
   3. IDE en Java, Compilador: gcc, Depurador: gdb
      Se puede integrar el lenguaje a los lenguajes que compila el gcc y depura el gdb. Aporta el hecho de tener años de desarrollo. Requiere muchas tareas de análisis de la documentación y adaptación del lenguaje.
      
   En todos los casos se dificulta la depuración.
   

Seguro hay otras formas de hacerlo, pero de estas que enumeramos, las dos ideas que más nos convencieron son las 2.3 y 2.4. En estos días vamos a tener que decidirnos por alguna de todas esta gama de posibilidades que se desplegó frente a nosotros.
Hasta la próxima.