El preprocesador

cuchillo Por muchos años programé en lenguajes que contaban con un preprocesador, recuerdo especialmente a tres: clipper, C y C++. Pero cuando me inicié con java dos cosas me llamaron poderosamente la atención, la primera fue la ausencia del declarados de tipos (typedef) y la segunda, y más dolorosa, fue la ausencia de un preprocesador. La explicación de esto era que estas dos características hacían al código propenso errores ya que lo volvían sumamente ilegible y muchos desarrolladores hacían un pésimo uso ellas. Y es cierto, aunque en ese momento no le entendí puesto que por aquel entonces yo las utilizaba correctamente gracias a haber aprendido estudiando excelentes piezas de código, como el del sistema operativo Minix.

Cuando me introduje en .Net, y conocí CSharp, lo primero que observé fueron los signos #, era evidente que estaba frente a directivas de preprocesador al mejor estilo C, y aunque me dejó con ganas entendí que en el contexto de .Net no tenían sentido más directivas como así también que las nuevas directivas #region eran una verdadera estupidez. Tenía sentido ya que uno de los usos más importante del preprocesador era el de hacer el código portable pero ahora ya no era necesario preocuparse de estas cosas.

Creo que hemos perdido un gran amigo dado que hoy en muchos casos debemos recurrir a técnicas algo avanzadas para lograr lo que antes se podía hacer con una pequeña ayuda del preprocesador. Por ejemplo, vemos el caso de los DSLs. El más grande dsl que conocí fue clipper y si no me crees observa cómo quedaba el código clipper luego ser preprocesado:

 

Clipper

Clipper similar a c

 

En realidad no encontré un ejemplo más significativo pero recuerdo casos en los que una palabra se convertía en un importante bloque de código luego su preprocesado. Entonces, ¿podría el preprocesador ayudarnos en la creación de un dsl sencillo?. Mi respuesta: por supuesto que sí.

No hace falta ir tan lejos, con sólo observar LINQ y las expresiones lambda podemos darnos cuenta que no era necesario modificar el lenguaje para introducir estas características sino que bien podrían haberse resuelto con simple macros de sustitución.

Ahora bien, que se trata de un arma de doble filo no hay dudas pero también debemos reconocer que la posibilidad de modificar el código fuente instantes antes de compilarlo es una poderosísima posibilidad. Pero claro, hasta ahora hemos hablado de preprocesadores clásicos como los de C y C++ pero imaginemos algo más potente, imaginemos un preprocesador capaz de modificar el código de una manera más versátil, quizás con directivas ocultas en comentarios o alguna otra manera sencilla. Tal vez no con simples directivas sino con un lenguaje que sea interpretado y que ejecute acciones sobre código fuente.

Algunas cosa que se me vienen en este momento a la mente son la programación orientada aspecto, la inyección de dependencias, la generación de código basado en el código, etc. Por ejemplo, en C es muy común ver cosas como estas:

 

define

 

También podríamos hacer que, embebiendo un simple comentario en un método privado, el preprocesador se encargará de la creación de un método público para accederlo con el fin de poderlo testear.

 

sin accessor

con accessor

 

Ya sé que hoy tenemos solucionadas todas estas cosas y que parezco un tanto nostálgico pero la verdad muchas veces terminamos recurriendo a reflexión y a la carga dinámica de assemblies para resolver problemas muy sencillos que bien podrían solucionarse a la antigua y no por ello ser un antiguo. Déjeme que les cuente una experiencia de cuando programaba video juegos para celulares utilizando java ME. En Gameloft a partir de un mismo código fuente deben poderse crear binarios del juego para una enorme variedad de dispositivos. El building system (como lo llaman) debe poderse configurar para construir el juego dependiendo del carrier, manufacturer, modelo (de los cuales dependen las apis, el ancho, el alto, las teclas, si vibra o no, las luces laterales), idioma, cantidad de niveles, publicidad activada o desactivada y muchísimas cosas más que en este momento no recuerdo. El tema es que la máquina virtual java no asegura la portabilidad ni mucho menos por lo que el uso del preprocesador en estas aplicaciones era sumamente extensivo y aún lo es.

 

Lucas Ontivero

Sin categoría

6 thoughts on “El preprocesador

  1. Je je, otro que añora los viejos tiempos. Ya somos dos. Yo siempre he dicho que el hecho de que una característica no sea recomendable no quiere decir que el lenguaje en cuestión no deba tenerla.

    Es cosa del programador el sólo usarla en los momentos convenientes y de forma adecuada, pero parece que estamos en la época de los tontos: no le pongas muchas opciones que lo mismo se lían. 😛

  2. Mi querido Clipper, mi Visual Foxpro, que tiempos aquellos, todavia tengo aplicaciones funcionando en estos entornos, que rápido iba… a veces tengo la sensación que vamos hacia atras, en fin, nos estaremos haciendo viejos…

  3. Un artículo muy interesante. Probablemente yo soy uno de los que ha ganado con el lenguaje java y su falta de preprocesador, pero he de decir que se hecha en falta para muchas cosas.

    No estoy muy puesto en esto del “Building System” pero estoy tratando de hacer una aplicación accesible a diferentes usuarios con diferentes discapacidades y me sería de gran ayuda alguna referencia sobre donde encontrar y como utilizar algún sistema preprocesador para java.

    Muchas gracias.

  4. No me refería explícitamente a un preprocesador, me refería a algún sistema como Java+ o Antenna que si hacen un preprocesado del código fuente e incluso Antenna tiene un plugin para usarse en Eclipse con Ant como si de un preprocesador C++ fuera. Al final pude encontrar algo de información, aunque sólo conozco esos dos y por lo que he podido ver Java+ sólo hace preprocesado de cadenas para uso mayoritariamente web. Antenna ya es más completo, con directivas, evaluación de expresiones, etc. Al final creo que me he contestado yo mismo. ¿Conoceis algún sistema similar a Antenna (que no sea POLISH ya que se basa en ello)?

    Por cierto, sobre los comentarios de este artículo, yo no veo el problema en hacer tecnologías para tontos, cuanto más podamos simplificar el tema menos errores se cometerán en desarrollo, eso sí, que no se dejen de lado otras tecnologías mucho más avanzadas (o anticuadas) que permitan a un buen desarrollador hacer las cosas de forma más eficiente. ¿Quién se queja de los electrodomésticos de ahora, que le das al botón y ya saben lo que tiene que hacer? Siendo además mucho más eficientes energéticamente, menos ruido, etc. ¡Lavar a mano siempre funcionó, e ivas directo a las manchas! Ya se que el simil es un poco rebuscado.

    Muchas gracias por su atención.

  5. Snif!! Snif!!!… como he llorado la ausencia del procesador en la tecnologia NET. Muchos pollitos de ahora no tienen ni idea de esta bondad y comodidad. Como dijo Juan Irigoyen …”Nos estamos haciendo viejos” y en cierto modo incomprensibles. Espero que en el futuro haya de retro a eleccion en la tecnologia NET.

    Saludos con telarañas a todos
    jejeje.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *