Hoy, el segundo y último post de ComCuac. A ver si se me ocurren más de este estilo.
No, no es RapidShare. Es IBM. En los 70's
(Advertencia: esta entrada es larga como la cuaresma y sin dibujitos. Disculpen las molestias que esto ocasiona)La historia va así: El Gobernator quiere cambiar los salarios de todos los trabajadores del estado (concretamente bajarlos), en un ataque de austeridad democrática de esos que conocemos mucho aquí en México. La semana anterior, en otro hecho aparentemente inconexo, el mismo gobierno de California puso a mucho personal en pre-jubilación (o sea, ya no trabajan). Cuando se les da a los nuevos empleados la orden de aplicar los descuentos de las medidas de "responsabilidad hacendaria" a la nómina, horrorizados descubren que toda su sapiencia es inútil para atacar ese problema aparentemente sencillo. ¡Pero si son tan solo unas restas! ¡Mi contador, mi esposa, mi nieto pueden hacerlas! El problema es que nadie sabe como escribirlas: el sistema que controla todas las complejidades de los pagos a los trabajadores es una reliquia de los 70's escrita en
COBOL, un bello dialecto informático del que todos han oído, al que todos desestiman por anticuado, pero que temen cruzarse con él por miedo a quedarse engarrotados frente a sus formalismos y estructuras tan apabullantes. Todos los que podrían haber ejecutado esa orden tan sencilla están ahora disfrutando las delicias del pre-retiro. Mientras todos estos chamaquitos empiezan a bajar tutoriales como histéricos para tratar de domar a la bestia y a llorar en los rincones como, miren cómo son las cosas, novatos en Vietnam que sienten (saben) que lo que les tocó es demasiado y no los prepararon para ello, mientras el T-800 desea vengarse de esa SKYNET con olor a naftalina,
el espectro de la almirante que diseñó esta maravilla de la verbosidad sonríe en el más allá, satisfecha de que su memoria jamás será olvidada, aunque algo sorprendida de la ironía: su creación debería ser entendida por personas comunes, pero parece que los expertos se dan de topes con la pared.
Es chistoso que la mayoría de los programadores se burle (nos burlemos) de COBOL: si la gente común supiera que las entidades más críticas, aquellas sobre las que se funda nuestra sociedad (bancos, gobiernos, grandes cadenas), detrás de esa máscara de alta tecnología que nos muestran a través de páginas web y el nipper (luego hablaremos de él) siguen dependiendo de él, y que en los grandes centros de estudio ya no se imparte, esta misma gente común nos interpelaría en la calle llamándonos irresponsables, niños que juegan en la arena creyéndose grandes ingenieros. Si supiera que las computadoras donde corren estos sistemas duran años, décadas (sí, décadas) sin tomarse un sólo descanso, se preguntarían extrañados ¿dónde las venden para comprar una? Si supieran que no son mucho más poderosas que las que tienen en su escritorio, y sin embargo pueden con toda la maraña de las transacciones globales de bienes y servicios, se darían cuenta de que es ridículo que una PC se trabe con el Word, o con el Messenger. Pero eso no lo sabrán, ¿verdad? Les seguiremos vendiendo sistemas hechos en .NET, aunque sepamos la de recursos que consumen.
***
En esta historia hay tres lados que quisiera mencionar: el primero, que algo tan importante como COBOL debería ser aprendido por todos, o por lo menos, deberíamos tener esa opción, o una noción de ella. Sí, sé que las posibilidades que un programador recién egresado ponga sus manos en un sistema basado en COBOL o en algún lenguaje así es infinitesimal, pero es real. Aparte es un buen ejercicio de humildad. Sí, lo que hace un behemot escrito en un lenguaje así lo puede hacer otro cualquiera, pero tal vez no sería tan estable, o tan rápido. Los lenguajes de este tipo trabajan con menos capas de abstracción. Parecen complicados porque son tediosos de teclear, pero en realidad no lo son. ¿Qué tendría que hacer un pobre cristiano que quisiera hacer una transacción de fondos de un banco en C#? Objetos tras objetos tras objetos, cosa que no sucede en COBOL: Diseñado en la era de las tarjetas perforadas, prácticamente manipulaba la información directamente. La lección de humildad es: no necesitas tantas cosas, hombre. Esto mas eso es aquello. Y aparte, puedes esperar sentado a que tu programa en C# se abra paso a través de todas las clases necesarias para hacer una transacción.
Lo segundo (que en realidad es continuación de lo primero) es que esto de los lenguajes importantes pero olvidados por el ímpetu de seguir la última moda no ha dejado atrás a COBOL solamente: casi todas las personas que conozco no se atreverían a pensar siquiera en hacer un sistema en C o C++. Estamos hablando de lenguajes probados, famosos, respetados, indudablemente usados, pero que no queremos aprender, y mucho menos usar, por el simple hecho de no tener un IDE bonito a nuestra disposición, o por que nada más no se oye en la "vida real" que alguien lo use. Las probabilidades de encontrarse con una aplicación en C o C++ no son tan bajas; cualquiera puede bajar el código de un programa open source cualquiera. Yo cuando leí el código del programita que me permitía jugar Sudoku me fui para atrás. No podía concebir que alguien pudiera haberlo creado desde cero. Todavía no lo creo. Incluso algo más amigable como Delphi es, por lo menos en mi clase, una cosa espantosa: ¿2002? ¿Win32? Bah, lo de hoy es Linux. Sí, el Linux escrito en C, compañero. No hay que olvidar las bases.
Lo tercero es algo que he tenido en la mente desde hace unos días. A lo mejor no me expreso bien esta vez, pero pienso volver al tema, no se preocupen. El punto es que estamos confiados a que siempre tendremos lo último de lo último, que siempre estaremos avanzando. Durante los últimos 50 años ha sido así, gracias al cielo y la Ley de Moore. Podemos darnos el lujo de olvidar las complejidades de la estructura sobre la que yacen nuestros pobres e intrascendentes programas. Para hacer un reloj checador no es necesario saber cómo funciona mi equipo, que hay un linker y un compilador, qué cómo funciona en realidad un DataSet... todas esas cosas las obviamos. Seguimos programando. Y mientras sigamos con esa actitud, me temo que seremos cada vez menos los que sepan los verdaderos fundamentos de nuestro oficio, y en el caso de que llegue la guerra nuclear o el holocausto zombie y tengamos que reconstruir, ¿quién demonios va a saber cómo? Bueno, sin irme hasta el extremo: nos vamos a convertir en esclavos de nuestras herramientas. Visual Studio hace lo feo y tedioso por ti. Lo que ÉL (los fabricantes) decida que es lo feo y tedioso. Lo que no tienes derecho de ver. Sólo puedes hacer con estos LEGOS lo que viene en la foto. Esa figurita verde es para el pasto, no para los muebles. Y ni se te ocurra hacer tus propias piezas (bueno, en realidad si se pueden hacer componentes para Visual Studio.NET). Bah, ni para qué te tengo que decir eso: ni sabes cómo. Tal vez estoy exagerando y Visual Studio es una herramienta nada más, pero de verdad creo que la manera de enseñar programación en estos días es "Aquí está el diseñador. Haz un ABC (Altas - Bajas - Consultas) y estás del otro lado". Así sin más. Tal vez soy un nerd por exigir saber cómo coños funcionan las cosas, pero quiero pensar que es una queja válida. Porque si supiéramos todas las complejidades que existen detrás de una simple ventanita tal vez, sólo tal vez, se nos podría ocurrir una forma de hacer las cosas más simples, mejores... o regresar a COBOL, al fin y al cabo, todo lo que quiere la gente es sumar y restar.
