Perspectiva histórica del lenguaje Vala

A propósito del reciente artículo sobre Gnome 3.0, por su relevancia para los desarrolladores de software libre, cito literalmente un interesante artículo que he tomado del Grupo Linuxero del Bajío, publicado el 18 de enero por el autor Ceyusa.

Dicho sea de paso, para aquellos que prefieren la simplicidad sintáctica de lenguajes como Python, deberían conocer que el compilador de Vala también permite compilar otro nuevo lenguaje desarrollado igualmente por el equipo de Gnome (que convendría cubrir en un próximo artículo): Genie

Para describir brevemente en qué consiste Genie, mejor cito a sus propios autores:

«Genie es un nuevo lenguaje de programación, en la misma vena que Vala, que permite un estilo de programación más moderno y facilita la creación y el uso de de gobjects nativamente.»

«La interfaz se ha diseñado para que sea limpia, clara y concisa, y se deriva de numerosos lenguajes modernos como Python, Boo, el lenguaje D y Delphi.»

«Genie es muy similar a Vala en funcionalidad, pero difiere en la sintaxis, permitiendo al programador utilizar un código más limpio y conciso para consumar la misma tarea.»

Y ahora sí les dejo con el artículo sobre Vala, que espero encuentren instructivo.

Perspectiva histórica del lenguaje Vala

Con 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.

Publicado por GUTL

Forma parte de GUTL desde el 6 diciembre, 2011.