Perspectiva histórica del lenguaje Vala
Víctor Manuel Jáquez LealCon fines didácticos me gusta contextualizar cronológicamente las definiciones de conceptos:
Cuando Federico Mena y Miguel de Icaza, en agosto de 1997, dieron la patada inicial al proyecto Gnome, intentaban poner un escritorio decente sobre GNU/Linux. El proyecto fue evolucionando a lo largo de diez años, al punto de tener, no sólo un escritorio que compitiera con cualquiera disponible en el mercado, sino también un conjunto de bibliotecas, más o menos organizadas, que proveían de toda la infraestructura necesaria para sostener el proyecto.
El fundamento de Gnome que marcaba la diferencia con el proyecto KDE, que tiene el mismo objetivo, fue el uso de la biblioteca gráfica GTK+, el cual estaba escrito en C utilizando un ingenioso mecanismo para la implementación objetos, el cual después se convirtió en la biblioteca GObject.
Tres o cuatro años después, cuando Gnome estaba en su versión 1.4, ya se le veía como un proyecto de software serio y con reputación. Sin embargo, además de estar casi exclusivamente escrito en C, estaba construido sobre una apuesta tecnológica a CORBA, que es un mecanismo estandarizado para construir componentes de software que pueden ser utilizados desde diferentes lenguajes de programación, máquinas virtuales o diferentes computadoras en red. Sin embargo, la adopción de CORBA y/o el uso de C como lenguaje, implicaba una carga extra e innecesaria a los programadores de aplicaciones verticales que sólo desean utilizar las facilidades de Gnome.
Para intentar solventar tanto el problema de CORBA, que aunque prometía independencia de lenguaje, los alcances reales eran escasos, así como de la limitación del lenguaje nativo, se comenzaron a escribir “bindings” o ligaduras entre los símbolos de un lenguaje con los de otro, así se podía utilizar las facilidades de Gnome en Scheme, Python, Ruby, etc. sin ninguna complejidad extra. El problema con los bindings es el tiempo que tardan en llegar al desarrollador de a pie, ya que una vez que la API estuviera estable y liberada, tardaba otro tiempo semejante para que el mantenedor del binding lo actualizara a la nueva versión, por no mencionar del esfuerzo humano extra necesario para mantener esos bindings.
Miguel de Icaza, consciente de este círculo vicioso en el que se encontraba el proyecto, y abierto admirador de las tecnologías utilizadas por Microsoft (la adopción de CORBA estuvo inspirado en el uso de COM), pensó que la manera de zanjar el problema era, de nuevo, adoptar las más nueva y flamante de las tecnologías de la empresa de Redmond Seattle: .Net.
La justificación para portar tanto la máquina virtual de .Net como el compilador de C# fue, precisamente, aumentar la productividad del programador de a pie, de aplicaciones verticales, quien no se quiere ensuciar los pies en los lodazales internos del proyecto Gnome. Así nació el proyecto Mono.
El proyecto fue polémico desde su concepción. Hubo voces de alerta y otras voces de entusiasmo. La misma comunidad del proyecto Gnome estaba divida. En su clásico estilo provocador, Miguel declaró que Gnome 3.0 sería reescrito en su totalidad en Mono. Gnome 3.0 saldrá este año y definitivamente la predicción de Miguel no se cumplirá en lo absoluto. En cambio Mono ha prosperado como un proyecto independiente a Gnome, sin que la simbiosis persistiera.
No obstante el problema sí permanecía: ¿cómo atraer el desarrollo de aplicaciones verticales al proyecto? O dicho de una manera más mercadológica, ¿cómo incrementar la productividad del programador?
Uno de los principales problemas de Mono para llevar una relación simbiótica con Gnome, era la de reescribir el conjunto de bibliotecas base de Gnome, a código manejable por la máquina virtual de Mono. Se podía, al igual que otros lenguajes, hacer bindings de C a Mono, sin embargo, esto restaba la potencia provista por la máquina virtual, y pocos estaban dispuestos a tirar a la basura el trabajo de tantos años con la mano en la cintura.
El fundamento de las bibliotecas y aplicaciones en Gnome es el mecanismo de GObject. GObject es una biblioteca en C que provee un sistema de objetos fácilmente transportable a otros lenguajes. Provee mecanismos para crear clases e interfaces como en cualquier otro lenguaje de programación diseñado explícitamente para el manejo de POO (encapsulación, modularidad, polimorfismo y herencia), además que simplifica la tarea de crear bindings a otros lenguajes, ya que un objeto derivado de GObject, puede ser parametrizado de manera anónima, es decir, uno puede ejecutar métodos de actualización o acceso a objetos cuya clase no conozcamos explícitamente, entre otros métodos comunes. Sin embargo, la verdadera introspección aún sigue siendo el santo grial del GObject.
Uno de los principales problemas de programar en C con GObject es lo molesto y fastioso que resulta escribir una cantidad de código brutal, con tal de sólo definir la clase y su implementación, cosa que en los lenguajes de programación modernos se logra tan sólo escribiendo la palabra reservada “class”.
Dadas estas críticas y con la apuesta de Mono sobre la mesa, en ese mismo año del 2000, el matemático checo Jiří Lebl, publicó GOB, un preprocesador, que a partir de una descripción de la clase y código en C embebido, generaba todo el código necesario de GObject. Recibió duras críticas pero varios proyectos lo adoptaron para automatizar la tarea de escribir código repetitivo, aunque nunca tuvo una aceptación considerable. El uso del preprocesador implicaba tener un código híbrido: parte C, parte GOB, lo que resultaba para muchos bastante sucio de leer, además de imponer restricciones arbitrarias que frustraban a los desarrolladores.
5 años después de la aparición de GOB y casi 10 años de la de Gnome, Jürg Billeter, mostró a la comunidad su modesta pero ambiciosa apuesta para intentar solventar el dilema del proyecto Gnome: El lenguaje Vala.
Vala, como lo dice su página, es un nuevo lenguaje de programación que intenta traer las características de los lenguajes de programación modernos a los desarrolladores de GNOME sin imponer ningún requerimiento en tiempo de ejecución adicional y sin usar una ABI diferente a las aplicaciones y bibliotecas escritas en C. Y, cómo establece más adelante en la misma página, la sintaxis de Vala es similar a la de C#, modificándola para ajustarse mejor a la infraestructura de GObject.
Vala es un lenguaje de programación por derecho propio, que retoma mucho de los elementos de C#, sin ser propiamente un clon del mismo, ni tampoco un preprocesador de C. Por otro lado, el compilador de Vala, como muchos otros lenguajes, primero convierte el programa en un código intermedio, sólo que este código intermedio resulta ser el lenguaje C. Luego, el compilador de Vala, manda ejecutar el compilador de C disponible para generar el código máquina objetivo.
Dicho de otra manera, Vala utiliza el lenguaje C y la infraestructura de GObject para generar programas binarios a partir de un lenguaje de última generación, parecido a Java o C#.
Este lenguaje ofrece algunas características interesantes, comunes en los lenguajes modernos, tales como:
- Interfaces
- Propiedades
- Señales
- La instrucción foreach
- Funciones anónimas del tipo lambda
- Inferencia del tipo para variables locales
- Programación generica
- Manejo de tipos no-nulos
- Administración de memoria “asistida” (no es automática)
- Gestión de excepciones
- Mecanismos para la carga dinámica de módulos o plugins.
Dicho lo anterior, podemos observar que Vala intenta resolver el problema de la “productividad” para los programadores de a pie al momento de escribir programas para Gnome, ofreciendo las facilidades de un lenguaje moderno y común para muchos programadores de aplicaciones verticales, pero que a su vez genera código nativo, muy rápido y sin la sobrecarga de recursos de una máquina virtual.
Sin embargo queda la cuestión de los bindings. Pero Vala intenta tomar cartas en el asunto también. Vala está diseñado para permitir el acceso a bibliotecas existentes en C, en especial a las basadas en GObject, utilizando archivos conocidos como Vala API o, simplemente VAPI. Estos archivos se especifican en tiempo de compilación, y hacen la relación entre los símbolos de la biblioteca en C y los símbolos en Vala. Pero hay que hacer una mención especial, Jürg desarrolló un mecanismo para la generación de estos archivos VAPI de manera automática, parseando los archivos de cabecera de las bibliotecas en cuestión. Esta innovación aceleró el desarrollo de los mecanismos de introspección para GObject.
Este mecanismo de introspección ha facilitado el esfuerzo de integrar JavaScript y otros lenguajes script a Gnome, que llevan el fin de simplificar la automatización de tareas usando los componentes de software que Gnome ofrece, y no sólo eso, sino la composición de nuevas y más dinámicas aplicaciones base para el escritorio, como GnomeShell.
El número de bindings para Vala crece día a día, dada la facilidad para crearlos y actualizarlos, así como también el número de aplicaciones que se escriben en Vala.
Concluyendo, todo parece indicar que Vala llena un sentido hueco del ecosistema de Gnome y del software libre en general y que llegó para quedarse.