Horizontes

¿Qué razones hay para migrar a .NET? A primera vista, es difícil encontrarlas. Borland, por ejemplo, justificó algunas de sus decisiones estratégicas respecto a Delphi.NET mediante un símil equivocado: comparó la transición a .NET con la que tuvo lugar hace tiempo desde DOS hacia Windows. ¿Por qué convenía al programador realizar esa transición? En mi caso, el motivo fue disponer de toda la memoria física que admitían los procesadores de 32 bits (¿quién se acuerda de la barrera de los 640KB?). Claro, por entonces trabajaba con algoritmos geómetricos que consumían mucha memoria... Para otros, el motivo fue la nueva interfaz gráfica, o la novedad de poder "dibujar" sobre la impresora, gracias al GDI, de la misma forma en que se dibujaba sobre pantalla. Especialmente con la llegada de Windows 95, el programador que daba el salto recibía como recompensa una interfaz gráfica que por entonces parecía muy difícil de programar. No es que el cliente final del programador exigiese tal interfaz: es que al usar esa interfaz, la aplicación ganaba en valor subjetivo. Y por supuesto: en determinados tipos de aplicaciones, una interfaz gráfica era lo apropiado.

¿Ocurre algo similar con la migración a .NET? Aparentemente no... pero hay varias sorpresas. Veamos primero lo de la memoria. ¿Cuál compilador de 64 bits está usted utilizando ahora mismo? En mi caso, uso Visual Studio.NET. Las alternativas son Java (y ya conoce una parte de lo que opino sobre Java), y algún otro compilador nativo, probablemente caro y bastante limitado en herramientas de soporte para el desarrollo. Es verdad que una aplicación típica de gestión no necesita el espacio de memoria que ofrecen los 64 bits, pero no todo el monte es orégano. Se avecina otro cambio importante: la aparición de Windows Vista, con Avalon sustituyendo a la obsoleta GDI. No se trata de un retoque en el estilo visual: Avalon significa gráficos acelerados por hardware, gráficos 3D sin excesivo esfuerzo, controles mucho más potentes, soporte para vídeo y audio, incluyendo reconocimiento y síntesis de voz...

Pero hay más ventajas y posibilidades en .NET, y no hay que esperar al futuro para sacarles partido. Y lo mejor de todo es que cualquier aplicación de gestión puede aprovecharlas. No obstante, se lo voy a explicar haciendo referencia a XSight Ray Tracer. La clave está en la extensibilidad. De entrada, XSight RT es fácilmente extensible. No existe una primitiva para crear pirámides en este momento. Para añadir pirámides, tanto al motor como al lenguaje, basta con declarar una clase que implemente la interfaz IShape. Pero eso lo permite cualquier lenguaje orientado a objetos, ¿no? La diferencia se nota cuando hay que "registrar" la clase para que el núcleo de la aplicación la encuentre. En .NET, el núcleo utiliza reflexión para que sólo sea necesaria una instrucción. En Windows nativo, necesitaríamos definir un mecanismo de registro partiendo de cero... e incluso si todo saliese bien a la primera, habría que tener mucho cuidado con los problemas asociados a las DLLs.

Una aplicación como XSight RT, necesita matemáticas a toneladas. Por ejemplo, la apariencia del mármol en la segunda imagen se logra combinando un patrón regular con una función de ruido espacial. Extender esta funcionalidad siempre ha sido complicado. POVRay, por ejemplo, implementa un sencillo intérprete de funciones y proporciona un conjunto básico de funciones matemáticas primitivas. ¡Pero se trata de un intérprete común y corriente, una simple máquina de pila interpretada! XSight puede hacerlo mejor: basta extender el lenguaje de escenas con funciones matemáticas, que pueden compilarse sobre la marcha a código IL... ¡y este código IL se convierte en código nativo para ser ejecutado! No hace falta que el código generado pase por el disco duro: en .NET v2.0 existe un nuevo API simplificado que permite generar código sobre la marcha para métodos, sin tener que declarar antes toda una clase.

¿Y qué hay con las aplicaciones de gestión? Classique, para Windows nativo, permite definir fórmulas para calcular los gastos de envío. En la última versión (en algún momento lo pasaré a .NET), para evitar complicaciones, la fórmula se "compilaba" a Transact SQL, para que fuese ejecutado remotamente por el servidor, a petición del cliente. ¿Y qué hay de los motores de scripts? Bien, es cierto que se podía usar el motor de JScript en Windows nativo, igual que ahora se puede usar Visual Studio for Applications, para incorporar un motor de JScript, o incluso de C#, dentro de cualquier aplicación. ¿La diferencia? En Windows nativo, el motor de scripts estaba basado en un intérprete, pero en cualquier caso, los modelos de objetos del host y del motor de scripts eran muy diferentes, y se complicaba la comunicación entre ambas partes. En .NET, en cambio, las dos partes implicadas coexisten dentro del CLR. Eso significa, en primer lugar, que el código script no se interpreta, sino que también se ejecuta como código nativo. Además, al usar el mismo modelo de objetos del anfitrión, aparecen muchas opciones de comunicación interesantes. Por ejemplo, se puede declarar en JScript.NET una clase que use como ancestro una clase declarada en C#.

Y estoy sólo arañando la superficie...