En el artículo anterior quería hablar de lenguajes de programación y terminé hablando de conectores de audio. Me voy a poner un poco técnico pero, como si estuviéramos en clase, si alguien no entiende algo que lo pregunte (para eso están los comentarios, ¿no?).

¿Cómo afecta la estandarización a la reutilización de código?

A lo largo de mi vida profesional he trabajado con muchos lenguajes de programación (BASIC, COBOL, Pascal, Fortran, Lisp, Ada, C, C++, Java, varios lenguajes de shell e incluso algún lenguaje ultra-específico, como el RPL, un lenguaje “a pila” que permitía programar las calculadoras HP). Mi conclusión después de 25 años generando código fuente es que mientras más estándar es un lenguaje, más vigencia temporal tiene el código, más reutilizable es. Por ejemplo, hoy puedo usar código Lisp o C generado hace 15 años y funciona perfectamente, aunque el Intérprete Lisp o el compilador de C que utilice sean diferentes a los que utilizaba hace 15 años. Sin embargo mis programas en RPL vagarán por el Hades de las calculadoras HP como almas en pena. Porque, al fin y al cabo, ¿qué es el alma sino software?

Ejercicio: ¿qué futuro tendrá un programa desarrollado en ASP de Microsoft? A ver… ...sólo funciona en ordenadores con un sistema operativo de Microsoft instalado… ...Bueno, son la mayoría, mientras nadie lo desbanque… Además, sólo funciona sobre servidores Web Internet Information Server… ¡¡¡Uffff!!! ¿No puedo usarlo con Apache? ¿Estamos diciendo que mis productos dependen de que Microsoft siga siendo líder en el mercado? De las diez mayores compañías de informática en los años 80 sólo quedan tres. ¿Servirá para algo un programa en ASP dentro de 10 años?

¿Qué aporta Java?

A lo largo de los 90 se hicieron con el poder los interfaces gráficos de usuario. Hoy día no se concibe una aplicación de línea de comandos excepto en programación de sistemas. En esa época los lenguajes de programación quedaron descolocados. Microsoft, Borland y algunos más se esforzaron por sacar su propia solución al problema de la generación de interfaces gráficos para Windows sobre C++ y Pascal, porque os puedo asegurar que en aquella época era casi demoníaco (en diversos sentidos del término) desarrollar un programa para Windows. Muchos programas con amplia cuota de mercado (por ejemplo WordPerfect) sucumbieron por no adaptarse de modo satisfactorio a las nuevas tendencias (hay quien dice que Microsoft se encargó de ocultar lo suficiente de su API de programación de Windows para garantizar este fracaso de los competidores de Word). A mediados de los 90 la cosa mejoró con el nacimiento de los IDEs, que permitían que los interfaces se desarrollaran “dibujando” componentes en una rejilla, a los que posteriormente se les daba funcionalidad. Pero para utilizar esos componentes había que incorporar al código del programa las librerías del fabricante del compilador. Es decir, en términos prácticos, se había perdido la estandarización. Tengo programas de esa época implementados en C++ que no pueden compilarse a menos que se haga con la versión exacta de Borland C++ con que fueron desarrollados. Es decir, código inútil al cabo de tan sólo 2 o 3 años.

Entonces apareció Java, que, entre otras virtudes (y defectos) incorporó al estándar los métodos necesarios para definir un botón, un cuadro de texto o cualquiera de esos componentes que se habían apoderado del mundo. Ahora, un programa hecho con la versión 1.1.3 de Java (hace casi 10 años) puede compilarse con la 1.5. Es un avance. Espero no tener que tirar mi código fuente hasta dentro de otros 10.

¿Cómo afecta la estandarización a la innovación?

Este es el precio a pagar: desgraciadamente la frena; cuando se definió ANSI C no existían ciertos conceptos modernos de programación como las excepciones, los hilos o los patrones de diseño, y ¡ni siquiera los interfaces gráficos! Esto se mitigó en parte con la especificación del C++, aunque el resultado fue un híbrido que horroriza a los puristas de la programación orientada a objetos. En resumen: la estandarización frena la evolución rápida porque es difícil incorporar elementos novedosos a un estándar, al menos por dos motivos: (a) el proceso de consenso, aceptación y modificación de un estándar es lento, y (b) las modificaciones deben ser compatibles con lo anterior, lo cual a veces es posible (por ejemplo en el caso de la adaptación de un minijack monoaural a un minijack estéreo), a veces genera productos híbridos, poco puros (como el caso del C++) y otras veces es sencillamente inviable, lo que nos conduce a la producción tecnologías de usar y tirar.

Tecnologías de usar y tirar

En pocos años hemos pasado de un panorama socio-técnico basado en tecnologías de larga duración (véase el CD, nacido en 1980 y todavía vigente, o el disco de vinilo, que se utilizó desde 1948 hasta mediados de los 90) a tecnologías de usar y tirar (telefonías de primera, segunda y tercera generación, sistemas operativos en las PDA, el mini-disk, las cintas de video de 8mm, etc.) Como resultado (o como origen, según se mire) tenemos un panorama de aceleración tecnológica vertiginosa y una montaña creciente de aparatos obsoletos en las casas y los vertederos. Entusiasmo para los usuarios geek, desconcierto para el resto. Como consumidor de electrónica me gusta esta aceleración porque obliga a aprender constantemente; como programador, lo siento, me quedo siempre con los estándares.

Lectura recomendada: En el principio… fue la línea de comandos de Neal Stephenson