Freya y Frodo

¿Tienen algo que ver Freya y Frodo? No exactamente con Frodo, pero sí un poco con Tolkien. El autor de la mitología sobre la Tierra Media era un apasionado de la Lingüística, y hay quien sostiene que la Tierra Media fue un pretexto para situar en ella personajes que hablasen las lenguas inventadas por el autor.

Entre estos idiomas imaginarios, hay dos que destacan: el Quenya, que vendría a ser una especie de Latín élfico, la lengua originaria hablada por estos, y el Sindarin, una evolución posterior de la misma. En el diseño del Quenya hay elementos sacados del castellano y del finés, o suomi (suomen kieli). Tolkien se sentía atraído por la predominancia de las vocales en estos idiomas (pronuncie en voz alta, por ejemplo, Vainamoinen o Ilmarinen, personajes del poema mítico Kalevala, y compare, por ejemplo, con el nombre propio Iluvatar, el Creador en la mitología esbozada en el Silmarillion, o con el nombre genérico Ainur, que corresponde a los primeros seres creados por Iluvatar.

Pero para la historia que ahora relato es más importante el Sindarin. El Sindarin, en el que Tolkien inyectó elementos de otro de sus idiomas preferidos, el galés, es una lengua "gastada". Quiero decir: presenta los mismos fenómenos que se encuentran en los idiomas reales y que explican por el uso de la misma a lo largo de los siglos. Este es un tema fascinante y casi inagotable, y lamento no disponer de tiempo para desarrollarlo.

Cuando empezamos a diseñar Freya, me vino a la mente esta historia sobre el Quenya y el Sindarin, y propuse que el lenguaje que surgiese sobre el papel fuese sometido a un proceso de desgaste, a ver qué salía. ¿Cómo? Escribiendo páginas y páginas de código, detectando los errores de programación y amplificándolos. La mayoría de las meteduras de pata no tendrían demasiado recorrido, pero algunas de ellas se producirían por fallos en el diseño del lenguaje, ya sea por construcciones ambiguas o por restricciones superfluas. En cuanto tuvimos un primer boceto más o menos funcional de la sintaxis de Freya, me lancé a traducir algoritmos desde C y C++.

En la primera propuesta para Freya, se conservaba la idea de unit, y cada unidad se dividía en secciones public y private. Las implementaciones de métodos debían escribirse siempre en una parte private... con lo cual estábamos mezclando dos conceptos diferentes: visibilidad e implementación (mala idea, por supuesto). La técnica del desgaste enseguida dio frutos para este problema. La primera vez que implementé el omnipresente tipo Stack estaba demasiado atento a no cometer errores con la nueva sintaxis. La segunda vez, sin embargo, se me deslizó un error al declarar los campos privados de la clase. En vez de ubicarlos en la misma declaración de la clase, los moví a la sección private:

// Sintaxis ya obsoleta.
unit Stacks;
public
  Stack = class
  { ... }
  end;

private
  Items: array of Integer;
  Count: Integer;
  { ... }
end.

Era incorrecto, claro, pero ¿por qué no permitirlo? Lo de implementar métodos siempre en una sección private era un error de diseño, pero una vez aceptada la idea, ¿no era un exceso impedir la declaración de miembros realmente privados de un tipo de datos? ¡Ah!, el problema era que, en aquel sencillo ejemplo, sólo declarábamos una clase, pero en el caso más frecuente, una unidad declararía varias clases y estructuras. ¿A cuál de ellas pertenecía Items? El uso de private no daba pistas al respecto...

La solución final fue la idea de implementar los miembros de una clase en una sección implementation marcada con el nombre de la clase. Parece una vuelta al estilo original de Delphi... pero no lo es: Delphi usa interface/implementation donde Freya pone public/private, por una parte, e implementation por la otra; además, lo que Freya ofrece es implementation for X is. A partir de este simple cambio, recibimos como recompensa unos cuantos beneficios. Para empezar, lo que motivó la idea: la posibilidad de declarar detalles de la implementación en la cláusula de implementación. Con este sistema nos ahorramos repetir el nombre de la clase que se implementa junto a cada método (como sí obligan Delphi y C++). Además, nos evitamos problemas con otros detalles de implementación como la implementación de interfaces por delegación, los constructores estáticos, la implementación explícita de métodos y propiedades de clases...

Soy consciente que es imposible formalizar una técnica de este tipo ("desgastar" un lenguaje). Además, es muy probable que hubiésemos llegado a la misma idea más tarde o más temprano... pero lo que importa es que el uso intensivo de un lenguaje desde las etapas más tempranas del diseño puede acelerar la detección de problemas, inconsistencias, construcciones incómodas, etcétera.

Como decían en la Tierra Media, elen sila lumen omentielvo...