Hace unos días, y desoyendo la voz de especialistas, la Legislatura de Córdoba aprobó una ley que ordena el uso de voto electrónico en las elecciones provinciales. Amén de implementar un sistema más que cuestionado, la norma pone en manos del CPCIPC la fiscalización (limitando la posibilidad de ser fiscal informático partidario a quienes estén matriculados) y seguramente sea también el CPCIPC quien asuma el rol principal en la realización de las auditorías del sistema informático a utilizar.

Lo que sigue es un ejemplo más del lamentable nivel de los informáticos nucleados en el CPCIPC.

El sitio web del CPCIPC

El programador Federico Heinz (que hace unos días publicó una excelente nota sobre el tema) hizo notar en Twitter que el sitio del CPCIPC tenía un ridículo sistema de autenticación para el acceso de los matriculados:

En https://t.co/i4jSOkpZqH el login requiere dos datos: # matrícula y DNI. Adiviná que hay en https://t.co/eeyuWAuVp6? #NoDanMasDeInútiles

— Fede Heinz (@fheinz) 9 de enero de 2017

No pasó mucho tiempo hasta que algunos tuiteros comenzaron a ingresar al sistema usando los números de matrícula de las autoridades del CPCIPC (publicados en el mismo sitio) y su DNI (dato fácilmente obtenible si se tiene el nombre completo de la persona).

@fheinz @mis2centavos Ya estoy logueado como el presidente. Me estoy tentando de hacer alguna maldad, muejejeje pic.twitter.com/WdqhBvVqdt

— Elvira de Musicardi (@pitersoap) 10 de enero de 2017

@pitersoap @mis2centavos POR FAVOR NO ENTREN. La seguridad es patética, pero no es razón para violarla.

— Fede Heinz (@fheinz) 10 de enero 2017

De nada sirvió el pedido de Federico Heinz, para algunos la tentación fue muy grande:

@mis2centavos jajajaja quien fue!? :P pic.twitter.com/HaZDAe4vVv

— Maxi Biscardi (@MaxiBiscardi) 10 de enero de 2017

Alguien más encontró un error todavía más grosero: en el sitio del CPCIPC había un script que permitía descargar cualquier archivo del sistema que fuese accesible por el servidor web:

@fheinz https://t.co/TlTh0J7ben y acá te dejan descargarte lo que quieras.

— Gonza Cabrera (@_gonzacabrera) 10 de enero de 2017

Este es el código del script «downloader.php» que se encontraba en el servidor:

(Clic para ampliar)

¿Cómo es que los sesudos profesionales del CPCIPC cometieron este error digno de un principiante? Fácil: copiando y pegando código de la documentación de PHP:

Pero evidentemente, los errores en el sitio del CPCIPC no se agotaban. Unos minutos después, ya alguien había modificado el contenido (reemplazando las fotos de las autoridades por la del dueño de la empresa MSA Sergio Angelini, vendedora de voto electrónico):

@mis2centavos Bue, se fueron al carajo.

Este es el actual estado de https://t.co/hHjsear4L9 pic.twitter.com/G7OCSFN4FZ

— Luciano Bello (@microluciano) 10 de enero de 2017

Más tarde, el sitio del CPCIPC ya estaba completamente «defaceado«:

Hoy por la mañana, parece que ya estaban solucionando los problemas (o al menos algunos de ellos):

Lo instalamos entre todos? pic.twitter.com/CZXHyB9UUy

— mdl (@MadlySeason) 10 de enero de 2017

Solución de los guardianes monopólicos de la seguridad informática: eliminar la posibilidad de que los usuarios/colegiados se logueen pic.twitter.com/5bjVKSH850

— Delia Ferreira (@DeliaFerreira) 10 de enero de 2017

¿Algo más? Sí. Como era de esperar, y para completar la vergüenza, el servidor del CPCIPC ya había sido crackeado con anterioridad, por alguien que lo infectó con software que lo convierte en parte de un red de máquinas esclavas (botnet):

@cpcipc buenas muchachos, se les metió una porquería en el webserver vaya uno a saber hace cuanto https://t.co/JSPG4br5LY

/lib/libudev.so

— mega (@iglosiggio) 10 de enero de 2017

@cpcipc de paso miren el crontab

— mega (@iglosiggio) 10 de enero de 2017

(Si, el servidor del CPCIPC podría ser usado por terceros para realizar ataques distribuidos de denegación de servicio. En definitiva, quienes lo descubrieron les hicieron un favor).

Conclusión

Esta es la gente que amenaza con denunciarme por «ejercicio ilegal de la informática» por presentarme en el Congreso de la Nación como programador y especialista en informática:

Es la gente que «tutela el ejercicio de la profesión» y realiza inspecciones en la Provincia de Córdoba para determinar quién puede trabajar en informática y quién no:

También es la gente que se dedica a promocionar el sistema de voto electrónico de la empresa MSA y se ofrece a auditarlo en las elecciones:

Y es la gente que, gracias a la nueva ley provincial, tendrá el monopolio de la fiscalización electrónica en las votaciones por venir.

Gente que no puede implementar razonablemente un sistema de usuario y contraseña para autenticar a sus matriculados. Gente que no puede escribir una aplicación siguiendo los lineamientos básicos de seguridad. Gente que no puede ni siquiera mantener un servidor web sin transformarse en el hazmerreír de los programadores del resto del país. Ese es el Consejo Profesional de Ciencias (o «Carencias«) Informáticas de la Provincia de Córdoba.

Spolsky alerta sobre la creciente tendencia de muchas universidades a sobre-simplificar la currícula de las carreras de Ciencias de la Computación (con Java como «lenguaje insignia»), con el único objetivo de producir mayor cantidad de egresados y en menos tiempo. La consecuencia es directa: cada vez más abundan programadores que poco entienden de conceptos de programación (corrección, recursión, complejidad, paralelismo, entre tantos otros) y para los cuales los mecanismos «internos» de los sistemas informáticos (gestión de memoria, interacción con el sistema operativo, comunicación entre procesos, etc.) son completamente esotéricos.

El principal impulsor de este embrutecimiento es cierto sector de la llamada «Industria del Software» que requiere de mano de obra barata y de pobre formación, y empuja a las instituciones educativas a proveerles «recursos» tan rápido y en tanta cantidad como sea posible (ni qué decir de las instituciones educativas que ceden a esta presión).

Nadie está en contra de hacer la tarea del programador más simple, ni mucho menos de la evolución de los lenguajes y las metodologías de desarrollo de software. Lo que se reprocha aquí es la negación de la realidad como forma de evasión. Esto es: la necesidad de dotar a los programadores de ciertos conceptos, aún cuando esto provoque la deserción de quienes no puedan llegar a dominarlos (y mal que le pese al referido sector de la «Industria»).

Los Riesgos de las Universidades-Java

por Joel Spolsky
Jueves 29 de diciembre de 2005

Chicos perezosos.

¿Qué pasó con el trabajo duro?

Un seguro indicio de mi decadencia hacia la senilidad son mis continuas quejas y lamentos sobre «los chicos de hoy», y cómo ya no quieren o no pueden hacer cosas difíciles.

Cuando yo era un muchacho, aprendí a programar con tarjetas perforadas. En esos tiempos si cometías un error, no tenías ninguna de esas modernas funciones como la tecla «backspace» para corregirlo. Tenias que tirar la tarjeta y empezar todo de nuevo.

Cuando empecé a entrevistar programadores en 1991, les dejaba usar generalmente cualquier lenguaje que quisieran para resolver los problemas de programación que les planteaba. El 99% de las veces, ellos elegían C.

Ahora ellos tienden a elegir Java.

No me malinterpreten: no hay nada malo con Java como lenguaje de implementación.

Un momento, quiero rectificar eso último. No digo, en este artículo en particular, que haya algo de malo con Java como lenguaje de implementación. Hay un montón de cosas mal con Java, pero tendrán que esperar hasta otro artículo.

En cambio, lo que quiero decir es que Java no es, generalmente, un lenguaje de programación lo suficientemente difícil para que pueda ser usado para distinguir entre excelentes programadores y programadores mediocres. Puede ser un buen lenguaje para trabajar, pero ese no es el tema de hoy. Puedo ir incluso mas allá y decir que el hecho de que Java no sea lo suficientemente difícil es una característica, no un bug, pero que tiene ese problema.

Si puedo ser atrevido, diría que en mi humilde experiencia han sido dos las cosas tradicionalmente enseñadas en las universidades como parte de la carrera de Ciencias de la Computación (CS) las que mucha gente nunca llega realmente a comprender: punteros y recursión.

En aquellos tiempos lo normal era empezar la universidad con un curso de estructuras de datos, con listas enlazadas, tablas hash y, por qué no, con un uso intensivo de punteros. Esos cursos eran frecuentemente usados como filtros: eran tan difíciles que cualquiera que no pudiera soportar el desafío mental de un grado en CS se daría por vencido, lo que era bueno, porque si piensas que los punteros son difíciles, espera hasta intentar probar cosas en teoría de punto fijo.

Todos esos chicos que lo habían hecho muy bien en la secundaria escribiendo juegos de «pong» en BASIC para su Apple II, iban a la universidad, tomaban el curso CompSci 101, sobre estructuras de datos, y cuando llegaban al asunto de los punteros, sus cerebros estallaban completamente; y lo próximo de lo que tenías noticias es que estaban especializándose en Ciencias Políticas, porque la escuela de leyes parecía ser una mejor idea. He visto todo tipo de de índices de deserción en CS y usualmente están entre el 40% y el 70%. Las universidades tienden a ver esto como un derroche; yo creo que es sólo la poda necesaria de gente que no va a ser feliz o exitosa en una carrera de programación.

El otro curso difícil para muchos jóvenes estudiantes de CS era el curso donde aprendías programación funcional, incluyendo programación recursiva. MIT puso una barrera muy alta en esos cursos, creando un curso obligatorio (6.001) y un libro de texto (Estructura e Interpretación de Programas de Computadora de Abelson y Sussman, el cual era usado en docenas o quizás cientos de carreras de CS prestigiosas como el estándar de facto para la introducción a las Ciencias de la Computación. (Puedes, y deberías echarle una ojeada a la antigua versión de las clases en línea).

La dificultad de esos cursos es asombrosa. En la primera clase has aprendido casi todo Scheme, y ya has sido introducido a la función de punto fijo que toma otra función como parámetro. Cuando me esforzaba en pasar un curso similar, CSE121 en Penn, observaba cómo muchos sino la mayoría de los estudiantes simplemente no lo lograba. La materia era muy difícil. Inclusive escribí un largo email de lloriqueando a mi profesor diciendo que “simplemente no era justo”. Alguien en Penn debe haberme escuchado (o a alguno de los otros llorones), porque ese curso se dicta ahora con Java.

Desearía que no hubiesen escuchado.

Aquí radica el quid del debate. Años de lloriqueo de estudiantes perezosos como yo, combinados con quejas de la industria acerca de cuan pocos graduados en CS salen de las universidades americanas, han pagado su precio, y en la ultima década un gran numero de otrora perfectamente buenas universidades se han vuelto 100% Java. Esta de moda, a los reclutadores que usan “grep» parece gustarles, y, lo mejor de todo, no hay nada lo suficientemente difícil en Java como para filtrar aquellos programadores sin la parte del cerebro que entiende punteros y recursión. Así es que la deserción es menor, y los departamentos de ciencias de la computación tienen mas alumnos y mayores presupuestos y todo está bien.

Los afortunados chicos de esas Universidades-Java nunca van a toparse con raros fallos de segmentación tratando de implementar tablas hash basadas en punteros. Nunca se van a volver locos tratando de empaquetar cosas en bits. Nunca tendrán que ocupar sus cabezas en cómo en un lenguaje puramente funcional, el valor de una variable nunca cambia, y aun así, ¡cambia todo el tiempo! ¡Una paradoja!

Ellos no necesitan esa parte del cerebro para obtener un 4 en la materia.

¿Soy sólo uno de esos viejos cascarrabias anticuados, vanagloriándose acerca de cuán duro era sobrevivir a todas esas dificultades?

Rayos, en 1900, el Latín y el Griego eran asignaturas requeridas en la universidad, no porque sirvieran de algún propósito, sino porque de alguna manera eran considerados un requisito obvio de la gente educada. De cierta manera mi argumento no es diferente del argumento expuesto por la gente pro-Latín: “[El Latín] entrena tu mente. Entrena tu memoria. Desembrollar una sentencia en Latín es un excelente ejercicio del pensamiento, un verdadero acertijo intelectual y una buena introducción al pensamiento lógico”, escribe Scout Barrer. Pero ya no puedo encontrar una sola universidad que requiera Latín. ¿Son los punteros y la recursión el Latín y el Griego de las ciencias de la computación?

Ahora, admito que programar con punteros no es necesario en el 90% del código escrito en la actualidad, y de hecho es totalmente peligroso en el código de producción. OK. Está bien. Y que la programación funcional no es muy empleada en la práctica. De acuerdo.

Pero todavía sigue siendo importante para algunos de las tareas más excitantes en programación. Sin punteros, por ejemplo, nunca serías capaz de trabajar en el Kernel de Linux. No puedes entender una sola línea del código de Linux, o de hecho, de cualquier sistema operativo, sin realmente entender punteros.

Sin entender programación funcional, no podrás inventar MapReduce, el algoritmo que hace Google tan masivamente escalable. Los términos Map y Reduce vienen de Lisp y la programación funcional. MapReduce es, en retrospectiva, obvio para cualquiera que recuerde de su clase equivalente a 6.001 que los programas puramente funcionales no tienen efectos colaterales y por ende son trivialmente paralelizables. El simple hecho que Google inventara MapReduce, y no Microsoft, dice algo del por qué Microsoft está aun jugando a lograr que funcionen algunas características básicas de búsqueda, mientras Google se ha movido ya al siguiente problema: construir Skynet^H^H^H^H^H^H, la mayor supercomputadora masivamente paralela del mundo. Simplemente no creo que Microsoft entienda completamente cuan retrasados están en ese campo.

Pero mas allá de la importancia a simple vista de los punteros y la recursión, su valor real radica en que construir grandes sistemas requiere del tipo de flexibilidad mental que adquieres aprendiéndolos, y de la actitud mental que necesitas para no huir de los cursos en donde son enseñados. Punteros y recursión requieren cierta habilidad para razonar, para pensar en abstracciones, y más importante, para ver un problema en diversos niveles de abstracción simultáneamente. Por lo tanto, la habilidad para entender punteros y recursión esta directamente correlacionada con la habilidad de ser un gran programador.

No hay nada en grado académico 100% Java que realmente descarte a los estudiantes que carecen de la agilidad mental para tratar con esos conceptos. Como empleador, he visto que las Universidades 100% Java han empezado a producir en serie una buena cantidad de graduados quienes simplemente no son lo suficientemente listos para trabajar como programadores en nada mas sofisticado que «Sólo Otra Aplicación Contable en Java», aunque se las han arreglado para colarse a través de la (ahora simplificada) carrera. Esos estudiantes nunca sobrevivirían al 6.001 del MIT o al CS 323 en Yale y, francamente, esa es una razón por la cual, como empleador, un título en CS del MIT o Yale tiene más peso que uno de Duke, que recientemente se hizo 100%-Java, o de Penn, donde remplazaron Scheme y ML por Java tratando de enseñar la materia que casi nos mata a mis compañeros y a mi, CSE121. No es que no quiera contratar chicos listos de Duke o Penn, lo hago, es sólo que es mucho más difícil para mí darme cuenta de cuáles son. Yo estaba acostumbrado a decir que los chicos listos eran aquellos que podían desmenuzar un algoritmo recursivo en segundos, o implementar funciones de manipulación de listas enlazadas usando punteros tan rápido como podían escribir en la pizarra. Pero con graduado sde Universidades-Java, no puedo saber si padecen esos problemas a causa de haber sido mal educados o si los padecen porque realmente carecen de esa parte del cerebro que van a necesitar para ser buenos programadores en el trabajo. Paul Graham los llama «Blub Programmers«.

Ya es bastante malo que las Universidades-Java fallen en filtrar los chicos que nunca van a ser buenos programadores, algo que las universidades podrían justificablemente decir que no es su problema. Después de todo es la industria, o al menos los reclutadores-que-usan-grep, quien está pidiendo a gritos que se enseñe Java.

Pero las Universidades-Java fallan también en entrenar las mente de los chicos para ser hábiles, ágiles y lo suficientemente flexibles para lograr buen diseño de software (y no me refiero al “diseño” OO, donde gastas incontables horas acomodando tu jerarquía de objetos, o preocupándote de «problemas» superfluos como “tiene-un” vs. “es-un”). Necesitas entrenamiento para pensar en las cosas a varios niveles de abstracción simultáneamente, y ese tipo de pensamiento es exactamente lo que necesitas para diseñar excelentes arquitecturas de software.

Puedes estar preguntándote si la enseñanza de programación orientada a objetos (OOP) es un buen sustituto de los punteros y la recursión para el filtrado. La respuesta rápida: no. Sin debatir acerca de los meritos de la OOP, simplemente no es lo suficientemente difícil para filtrar a los programadores mediocres. OOP en las universidades consiste básicamente en memorizar un puñado de términos de vocabulario como “encapsulacion” y “herencia” y tomar exámenes del tipo «multiple-choice» acerca de las diferencias entre polimorfismo y sobrecarga. No más difícil que memorizar fechas destacadas y nombres en una clase de historia, la OOP tiene desafíos mentales inadecuados para espantar a los estudiantes de primer año. Cuando te enfrentas con un problema de OOP, tu programa aun funciona, sólo que es algo difícil de mantener. Supuestamente. Pero cuando te enfrentas a un problema con punteros, tu programa produce línea Fallo de segmentación y no tienes ni la menor idea de lo que está pasando, hasta que te paras, tomas una fuerte bocanada de aire y tratas de forzar tu mente a trabajar en dos diferentes niveles de abstracción simultáneamente.

Los reclutadores-que-usan-grep, de hecho, son ridiculizados aquí, y por un buen motivo. Nunca he conocido alguien que pueda usar Scheme, Haskell y punteros en C, que no pueda entender Java en dos días, y crear mejor código en Java que gente con cinco años de experiencia en Java. Pero trata de explicar eso al zombie de Recursos Humanos.

¿Pero que hay de la misión del compromiso con las CS de las facultades de CS? ¡Ellas no son escuelas vocacionales! No debería ser su trabajo entrenar gente para trabajar en la industria. Eso queda para los terciarios y los programas de capacitación del gobierno para trabajadores desplazados, dirán. Ellas se suponen que están para dar a los estudiantes las herramientas fundamentales para vivir sus vidas, no para prepararlos para sus primeras semanas de trabajo. ¿No es cierto?

Aun así, las CS son demostraciones (recursión), algoritmos (recursión), lenguajes (cálculo lambda), sistemas operativos (punteros), compiladores (cálculo lambda), y entonces la conclusión es que la Universidad-Java que no enseña C y no enseña Scheme, tampoco está enseñando realmente ciencias de la computación. Tan inútil como el concepto de currificación de funciones puede serle al mundo real, es un obvio prerrequisito para un graduado en CS. No puedo entender por qué los profesores en las comisiones curriculares de las facultades de CS han permitido que sus programas sean embrutecidos a tal punto que no sólo no pueden producir programadores operativos, sino que ya ni siquiera pueden producir graduados en CS que puedan obtener PhDs y puedan competir por sus puestos de trabajo. Oh, esperen. No importa. Quizás entienda.

Si volvemos en el tiempo y analizamos las discusiones que tomaron lugar en el mundo académico durante el “Gran Levantamiento Java”, encontraremos que la mayor preocupación fue que Java no era lo suficientemente simple para ser usado como un lenguaje de enseñanza.

Mi Dios, pensé, ¡están tratando de embrutecer la curricula aun mas! ¿Por que mejor no le llevamos la comida a la boca a los estudiantes? Dejemos que los ayudantes de cátedra den los exámenes por ellos también, entonces nadie se cambiara a Estudios Americanos. ¿Cómo se supone que alguien aprenderá algo si la curricula ha sido cuidadosamente diseñada para hacer todo más fácil de lo que ya es? Parece haber una comisión de trabajo (PDF) intentando idear un subconjunto simple de Java que pueda ser enseñado a estudiantes, produciendo documentación simplificada que esconde cuidadosamente toda esa basura EJB/J2EE de sus tiernas mentes, de manera tal que no tengan que preocupar sus cabecitas con otras clases que no necesiten para resolver sus aun más fáciles problemas de CS.

La interpretación mas compasiva de por qué las facultades CS son tan entusiastas en embrutecer sus clases es porque ello les dará más tiempo para enseñar verdaderos conceptos de CS, así no necesitaran dos clases enteras para esclarecer a los alumnos las diferencias entre, digamos, un int y un Integer en Java. Bueno pero si ese fuera el caso, 6.001 tiene la respuesta perfecta: Scheme, un lenguaje de enseñanza tan simple que el lenguaje entero puede enseñarse a estudiantes brillantes en unos 10 minutos; entonces puedes gastar el resto del semestre enseñando puntos fijos.

Fiu…

Voy a regresar a los unos y ceros.

(¿Te tocaron unos? ¡Bastardo suertudo! A nosotros nos tocaron todos ceros.)

Esta traducción está basada en la versión disponible en el Wiki de Joel Spolsky, corregida y adaptada por mí.

Dijkstra es reconocido como uno de los pioneros de las Ciencias de la Computación por sus abundantes aportes, tanto en el área teórica como en la práctica. Resulta ser que, además de un notable científico, también fue un gran visionario. Una muestra de ello es el artículo aquí reproducido, publicado originalmente en el año 1975.

Realmente es penoso ver que, aún 35 años después, muchos siguen sin caer en la cuenta de cuestiones que ya en aquella época resultaban evidentes.

¿Cómo decimos verdades que pueden lastimar?

A veces descubrimos verdades desagradables. Cada vez que lo hacemos, estamos en dificultades: suprimirlas es científicamente deshonesto, por lo que tenemos que decirlas; pero diciéndolas, sin embargo, se volverán en nuestra contra. Si las verdades son lo suficientemente desagradables, nuestro público será psíquicamente incapaz de aceptarlas y seremos tachados de irrealistas, idealistas sin remedio, peligrosamente revolucionarios, tontamente crédulos o lo que sea. (Además de eso, decir tales verdades es una forma segura de volverse impopular en muchos círculos, y como tal, es un hecho que en general no está exento de riesgos personales. Recordemos a Galileo Galilei…)

Las Ciencias de la Computación parecen sufrir gravemente este conflicto. En general, se mantienen silenciosas y tratan de escapar del mismo desviando la atención. (Por ejemplo: con respecto a COBOL se puede hacer sólo una de dos cosas: luchar contra la enfermedad o pretender que no existe. La mayoría de los departamentos de Ciencias de la Computación han optado por la última como una salida más fácil). Pero, hermanos, os pregunto: ¿es honesto? ¿No está nuestro prolongado silencio corrompiendo la integridad intelectual de las Ciencias de la Computación? ¿Es decente premanecer en silencio? Si no, ¿cómo podemos hablar?

Para que se haga una idea de la magnitud del problema, he enumerado una serie de tales verdades. (Casi todos los científicos de computación que conozco bien estarán de acuerdo sin dudarlo con casi todas ellas. Sin embargo, permitimos que el mundo se comporte como si no las conociéramos…)

• La programación es una de las ramas más difíciles de las matemáticas aplicadas, los pobres matemáticos mejor hubieran seguido siendo matemáticos puros.
• Las aplicaciones de computadora más fáciles son los cálculos técnicos/científicos.
• Las herramientas que usamos tienen una profunda (¡y retorcida!) influencia en nuestros hábitos de pensamiento y, por lo tanto, en nuestra habilidad de pensar.
• FORTRAN -«la enfermedad infantil»-, actualmente con casi 20 años de edad, es completamente inadecuado para cualquier aplicación informática que tenga en mente hoy: es demasiado torpe, demasiado arriesgado y demasiado costoso.
• PL / I -«la enfermedad fatal»- pertenece más al conjunto de los problemas que al de las soluciones.
• Es prácticamente imposible enseñar buena programación a estudiantes que han tenido exposición previa al BASIC: como programadores potenciales están mentalmente mutilados sin esperanza de regeneración.
• El uso de COBOL incapacita la mente, y su enseñanza debe, por tanto, ser considerada como un delito penal.
• APL es un error, llevado a cabo a la perfección. Es el lenguaje del futuro para técnicas de programación del pasado: crea una nueva generación de inútiles de la programación.
• Los problemas de administración de empresas en general y de gestión de bases de datos, en particular, resultan mucho más complicados para las personas que piensan en IBMés, compuesto con un Inglés desalineado.
• Sobre el uso del lenguaje: es imposible para afilar un lápiz con una cuchilla desafilada. Es igualmente inútil tratar de hacerlo con diez cuchillas desafiladas.
• Además de una inclinación matemática, un dominio excepcional de la lengua nativa es el activo más vital de un programador competente.
• Muchas compañías que se han vuelto dependientes de equipamiento IBM (y al hacerlo, han vendido su alma al diablo) se derrumbará bajo el peso de la complejidad incontrolada de sus sistemas de procesamiento de datos.
• No podemos encontrar ninguna disciplina científica, ni una profesión robusta, basada en los errores técnicos del Departamento de Defensa y, principalmente, un fabricante de computadoras.
• El uso de la terminología antropomórfica cuando se trabaja con sistemas de computación es un síntoma de inmadurez profesional.
• Afirmando que pueden contribuir a la ingeniería de software, los científicos blandos se vuelven aún más ridículos. (No menos peligrosos, ¡ay!). A pesar de su nombre, la ingeniería de software requiere (cruelmente) el soporte de la ciencia dura.
• En los buenos viejos tiempos los físicos repetían los experimentos de los demás, simplemente para estar seguros. Hoy se apegan a FORTRAN, de modo que puedan compartir los programas de cada uno, errores incluidos.
• Los proyectos que promueven la progamación en «lenguaje natural» están intrínsecamente condenados al fracaso.

¿No es esta lista suficiente para hacernos sentir incómodos? ¿Qué vamos a hacer? Volver a la orden del día, presumiblemente…

18 de junio 1975
Plataanstraat 5
Nuenen – 4565
Holanda

Prof. Dr. Edsger W. Dijkstra
Burroughs Research Fellow

PD: Si la conjetura «Usted hubiera preferido que no lo molestara enviándole esto» es correcta, puede añadirla a la lista de verdades incómodas.

Esta visión, lentamente, está cambiando. Por un lado, las historias de aquellos que hicieron una fortuna (o establecieron una posición económica) mediante la venta de licencias de un programa son, a la vez, cada vez más lejanas y menos frecuentes. Pero, si empezamos a vernos a nosotros mismos también como consumidores de software, el razonamiento cambia radicalmente.

Comparemos

Tomemos como ejemplo el desarrollo de un programa que le demande 5 años de trabajo a un programador altamente calificado y que requiera de las siguientes herramientas:

• Sistema Operativo.
• Compilador.
• Entorno de desarrollo: Depurador, editor de textos, etc.
• Herramientas de modelado: Herramientas para hacer diagramas de diseño, documentación, etc.
• Motor de base de datos.

El lapso de 5 años no es arbitrario: es una buena cota superior del tiempo pasado el cual un desarrollador debe renovar las herramientas que utiliza, si es que desea mantenerse actualizado. (Si lo prefiere, puede suponer la suma de varios desarrollos de menor envergadura, hasta llegar a cubrir dicho tiempo).

Comparemos entonces la cantidad de líneas de código «producidas» respecto de las «consumidas». El cociente será seguramente bastante cercano a cero. Desde este punto de vista, aún cuando un programador sigue produciendo software, su rol de consumidor es, por mucho, más relevante.

Alguien dirá que al vender muchas licencias del programa producido, su valor se multiplicará. Esto no es así, teniendo en cuenta que, para poder ejecutarse el programa requerirá, nuevamente, de un sistema operativo y del motor de base de datos. No es poco común ver a un programador cobrar determinada suma de dinero por un desarrollo y a su cliente desembolsar bastante más por licencias del software requerido para que funcione.

Un mal negocio

Entre los programadores independientes (o pequeñas empresas de desarrollo) es práctica común usar software sin pagar por sus licencias, con lo cual parte del análisis anterior no los afecta demasiado. Pero sus clientes (y cada vez más) no tienen opción.

Por ejemplo, un sistema que requiera de un servidor con el sistema operativo Windows 2008 y el motor de bases de datos Microsoft SQL Server 2008 para su utilización en 25 puestos de trabajo, requerirá el pago de más de u$s 10.000 en concepto de licencia de uso de dichos productos (en la Argentina, marzo de 2010). ¿Cuánto deberá trabajar el programador para cobrar una suma de dinero similar?

Claramente, esta forma de ver el negocio no tiene mucho sentido (a no ser para aquellas empresas de desarrollo que además son agente de ventas de quienes proveen el software de base y se llevan una jugosa comisión).

Quizá sea por este motivo que las empresas proveedoras de herramientas de desarrollo y software de base invierten tanto dinero para que los programadores se pongan «su camiseta», recurriendo para esto a discursos motivadores, aportes a instituciones educativas, descuentos, tazas de café, etc.

Asumir que esta es una situación natural es resignarse a ser, ya no un productor, sino un mero promotor de la venta de productos de otro (con un esfuerzo y un riesgo bastante altos).

Una buena alternativa

Debemos reconocernos a nosotros mismos, antes que como productores, como consumidores de software. De esta manera, la salida es clara: debemos reducir los costos de la «materia prima». Debemos, en la medida de lo posible, utilizar software que no requiera el pago de licencias de uso. De esta manera disminuyen sensiblemente los costos para el desarrollador, como así también los costos extra del cliente. (Y cliente que gasta menos en licencias, tiene más dinero para pagarle al programador).

Si el sistema del ejemplo anterior pudiera correr en un servidor con GNU/Linux y el motor de bases de datos PostgreSQL tendría más de u$s 10.000 de «ventaja» en condiciones similares.

Otro punto importante es el ahorro en hardware, al utilizar productos que reduzcan los requerimientos en este aspecto (característica que distingue a muchos programas libres, respecto de sus contrapartes privativas), aunque dicho análisis escapa al objetivo del presente artículo.

¿Por qué no?

Existe una marcada reticencia en ciertos programadores a analizar seriamente esta alternativa. Dejaremos de lado, por supuesto, el caso de aquellos que actúan, además, como agentes de venta de los proveedores de software de base (su caso es más que claro: ellos se benefician por ambos lados). Analizaremos algunas de las objeciones más comunes:

El sistema operativo libre «X» es difícil de usar. No lo entiendo

En casi todos los casos, «X» se refiere al sistema operativo GNU/Linux (el sistema operativo libre más difundido). Quizás el programador en cuestión haya tenido una mala experiencia tratando de usar alguna versión mal configurada u obsoleta. Seguramente tampoco haya dedicado demasiado tiempo ni esfuerzo a aprender los conceptos básicos (que no son, precisamente, como usar los botones del mouse), y se alejó cual la zorra de Esopo murmurando «están verdes».

De esto no se desprende que GNU/Linux sea tán fácil, cómodo o agradable de usar que Windows 7 (o más), pero tratándose de un profesional y habiendo tanto dinero de por medio, bien merece algún pequeño sacrificio.

En la empresa en donde se implanta mi sistema usan Windows

Aquí hay una amplia variedad de casos. ¿Usan Windows en los equipos de escritorio? Asumiendo que ya han pagado las licencias (por el tiempo que reste hasta la actualización de los equipos), de todas maneras podría significar un ahorro importante a nivel de los servidores. ¿Usan Windows en los servidores? Proveer una aplicación que no lo requiera, puede significar un valor agregado interesante.

En la mayoría de los casos en que la empresa «usa Windows» es porque las aplicaciones existentes lo requieren. No es, por lo tanto, una excusa para no proveer una alternativa que posibilite un ahorro importante (si no en lo inmediato, en el mediano plazo).

Estoy acostumbrado a desarrollar en (y para) Windows

Todos sabemos que los programadores disponemos de poco tiempo para mantenernos actualizados y lo costoso que resulta abordar el aprendizaje de una nueva tecnología. Cada quién sabrá si realmente se justifica el esfuerzo, poniendo en la balanza costos y beneficios (o, según el planteo de este artículo, costos y ahorros).

No hay un equivalente libre de la herramienta «Y»

Es cierto que en algunos casos (no tantos como se alegan) no hay equivalentes libres a ciertas herramientas privativas. ¿Y aquí termina el análisis? ¿No merece la pena indagar sobre alguna alternativa? ¿Tan útil es la herramienta «Y» que se hace imprescindible e indiscutible?

Si alguien depende exclusivamente de una determinada herramienta para desarrollar software, entonces se encuentra ante un problema bastante más grave que el gastar dinero en licencias de uso. (Preguntar a desarrolladores en Delphi, Visual Fox, Clarion, entre otros. Pero este tema también excede el alcance del presente artículo.).

No hay un equivalente libre del motor de bases de datos «Z»

Aquí «Z» suele tomar la forma de MS SQL Server, Oracle o DB/2. La afirmación suele hacerse seguida de alguna frase que parece extraída de una publicidad del proveedor correspondiente. La realidad es que existen numerosos motores de bases de datos libres, como por ejemplo MySQL para pequeños volúmenes de información, o PostgreSQL que no tiene ninguna característica importante que envidiarle a ningún otro producto.

En el caso de programas libres, nadie me ofrece el soporte que me da la empresa «W»

¿Enserio? Prácticamente todos los programas libres importantes, cuentan con ofertas de soporte incluso mejores que las que puedan conseguirse respecto de programas privativos. Por un lado, el soporte ofrecido es de mejor nivel, ya que se ofrece a nivel de reparación de errores en el código fuente y, por otro, muchas veces existen múltiples proveedores de soporte, que compiten entre si (en el mundo del software privativo el soporte es un monopolio del fabricante).

Porque no

Es cierto que hay algunos casos en donde no hay alternativa (la utilización de determinada tecnología puede ser impuesta como un requerimiento), pero en la mayoría de los casos la situación es que el programador se encuentra «atado» a sus herramientas.

En algunos casos, porque las han utilizado durante mucho tiempo (y tienen una gran cantidad de código desarrollado ligado a ellas) y en otros porque han «comprado» el discurso de su productor, muchos programadores se resisten a realizar cualquier análisis que tenga que ver con cambiar sus herramientas. El caso más grave (y lamentablemente no poco común) es cuando el programador simplemente no puede usar otra tecnología más que la que domina: es la única que conoce.

De más está decir, las inversiones en marketing dan resultado. Hoy nos encontramos a muchos programadores que han sido formados en un ambiente académico muy similar a un «monocultivo» (que, a pesar de ellos, ni siquiera ofrece los amplios márgenes de ganancia de la soja) o que se han entregado más tarde a determinada combinación de herramientas/tecnología y la han abrazado como dispuestos a envejecer (y quedar obsoletos) junto con ella.

Y así es que el negocio seguirá funcionando muy bien para los «grandes productores de software», en tanto que los pequeños no reconozcan su rol de consumidores. Afortunadamente, la situación ya está cambiando: abundan los ejemplos de quienes, siendo conscientes de esto, están haciendo una diferencia económica significativa.

Adenda

Nótese que en este artículo no se hace alusión a la licencia bajo la cual el programador entrega su programa al cliente final. El término «libre» sólo se aplica a las herramientas utilizadas para el desarrollo y a las requeridas para su posterior ejecución.

El uso de herramientas de desarrollo libre no impone ninguna condición sobre la licencia que acompañará al programa resultante. (Distinta situación puede darse si se incorpora código de un programa libre en uno de producción propia).

The situation

I have a table «mytable» (1,000,000 rows) with a column named «mycolumn» of type «datetime» and an index created on it named «idx_mycolumn«. When I issue the following query:

SELECT * FROM mytable ORDER BY mycolumn

it tooks more than 1 minute to give the results (the 1,000,000 rows ordered by mycolumn.)

Using the command «EXPLAIN» I can see that the MySQL optimizer don’t use the index at all: it generates a filesort (on disk) in order to sort the resultset. The only way to solve this issue (as far as I know) is providing a «hint» to the optimizer, telling what indexes to use:

SELECT * FROM mytable USE INDEX(idx_mycolumn) ORDER BY mycolumn

But the optimizer still chooses to do a full table scan instead of using the «idx_mycolumn» index (and still generates a filesort, taking more than 1 minute.)

There is a way to force the optimizer to use the index:

SELECT * FROM mytable FORCE INDEX(idx_mycolumn) ORDER BY mycolumn

This time, the optimizer uses the index, and the query takes about 3 seconds. (Is the MySQL query optimizer that bad?)

A bigger problem

Then, I came into the real problem for me: Obviously I’ll never need to get all the rows from that table, but is a common task to «paginate» the rows (previously ordered by some column) taking, let’s say, 25 rows at a time and using an offset. The query looks as follows:

SELECT * FROM mytable ORDER BY mycolumn LIMIT 100000,25

It sorts the resultset using the values of «mycolumn» and then returns 25 rows skipping the first 100,000. Surprisingly, this time the query tooks less than 1 second to execute (and «EXPLAIN» says that is using the «idx_mycolumn» index. What a joy!).

But the problem is still there: If the limit reaches (or surpases) the last row, then the optimizer throws away the index and generates a filesort (taking more than 1 minute, making the query totally useless…)

The solution (again) is to force the optimizer to use the index «idx_mycolumn«, getting a response in about 3 seconds.

My conclusion

Far from being a MySQL expert, the only conclusion I can reach is that the optimizer is really screwed up. How can it be possible that changing only the limit of the results, confuses the optimizer in such a way that leads to a simple query (that can’t take more than a few seconds) to take an unacceptable amount of time (not to mention the disk space)?

As I can’t (and don’t want) force indexes in every query involving large tables in my system, the only real solution for me is replacing MySQL with a more robust (and decent) DBMS (I’ve tried PostgreSQL with the same database and the results are far more reasonable.)

Some things to consider

• The problem is the same being the engine used MyISAM or InnoDB.
• The problem doesn’t get solved after doing a «ANALYZE TABLE«.
• I’ve trying with other datatypes for the sorting column, with the same results.
• I’ve tested this issue with versions 5.0.35 and 5.0.51a, with identical results.

Update (2008/12/30)

The observed behavior must be related with the bug 28404 (patched in version 5.1). From the patch description:

When there are many indexes in table, optimizer wrongly does not even consider the one on column used in ORDER BY, when LIMIT N clause is also present.

I’ve oversimplified the example, but in my real scenario I had multiple single-column indexes on the table. I still can’t believe that the optimizer get confused by having multiple indexes to choose from (but only in presence of the LIMIT clause). Can you guess how is the optimizer coded? (That’s why I use the word «toy» in the title.)

A posible solution seems to be moving to the new version, but anyway, MySQL 5.1 also has several issues (and the distribution installation script for GNU/Linux is totally broken), so I’m moving to PostgreSQL.

(Thanks to Abel Chiola for the links.)

Ruby: «Orientación a Objetos» y algo más…

• Presentación en formato PDF
• Presentación en formato ODP (OpenOffice.org)

Bueno, ¡no podía faltar una foto! ;)

Aunque se trata de material un tanto obsoleto, ya que está basado en las primeras versiones de Rails (en las cuales ni siquiera existían, por ejemplo, las «migrations»), decidí publicarlo de todas formas.

Primeros pasos en Rails

• Presentación en formato PDF
• Presentación en formato ODP (OpenOffice.org)

Un pequeño comentario: Todavía recuerdo el gran esfuerzo de la gente del Grupo de usuarios de GNU/Linux de Rosario (LUGRO) y de los integrantes de la Asociación Argentina de Nuevas Tecnologías (ANT) que lograron una organización impecable y, como siempre ocurre en estos eventos, un excelente clima de camaradería.

En la foto aparecemos (de izquierda a derecha) Diego Gomez (gran amigo y colega) , yo, Beatriz Busaniche (excelente periodista, integrante de la Fundación Vía Libre y gran activista en favor del Software Libre), Federico Heinz (amigazo, también integrante de Vía Libre y hacker de aquellos…) y Sebastián Criado (incansable, movedizo y persistente luchador por el software libre, entre otras causas).

Aunque en algún momento estará disponible en el sitio del evento (junto con el video de la charla), no resití la tentación de publicar la presentación que utilicé.

Experiencias en la implementación de un ISP con software libre

• Presentación en formato PDF
• Presentación en formato ODP (OpenOffice.org)

Los fiscales informáticos tuvimos acceso a la interfaz de consulta del proceso de escrutinio y a un volcado de la base de datos, que se realizaba cada 5 minutos. Lamentablemente, no tuvimos acceso al código fuente de la aplicación (aunque espero poder acceder al informe de los peritos contratados por la Junta Electoral).

Una vez finalizado el escrutinio provisorio, surgieron diferencias en los totales de votantes de los dos cargos electivos. A raíz de esto, decidí inspeccionar la base de datos con el objetivo de generar el listado de las mesas en las cuales se originaba dicha diferencia. De dicho análisis resultó el siguiente artículo, en el que me permito realizar algunas críticas.

El diagrama de Entidad-Relación (DER)

El siguiente es el DER que nos envió la gente de MSA:

Como puede verse se trata de una base de datos realmente simple (apenas 11 tablas). Lo que me llamó la atención a primera vista fue la utilización de palabras en castellano (muchos programadores opinamos que los programas deberían estar documentados en inglés). Siguiendo con los nombres, por más que me esforcé no pude imaginar la diferencia entre «ubicaciones» y «lugares«. No encontré palabras como «mesa«, «escuela«, «circuito«. A mi entender, la elección de la nomenclatura no ha sido la mejor.

Las claves primarias

En 9 tablas de la base de datos, las claves primarias son del tipo «varchar«. Si bien esto no es del todo incorrecto, no es muy recomendable. Las claves primarias deberían ser del tipo «integer«, y además auto-incrementadas (PostgreSQL, el RDBMS utilizado, lo soporta). Esto no solamente simplifica la asignación de valores a las claves (no hay que verificar la unicidad), sino que tiene un gran impacto en el desempeño de la base de datos.

Al utilizar el tipo «varchar«, cuya longitud es variable, el tamaño de los índices es mayor que usando «integer«. Esto, al aumentar la cantidad de filas de las tablas, se torna cada vez más importante (es deseable que los índices quepan en la caché del RDBMS). (En Río Cuarto había solamente 352 mesas y menos de 110.000 votantes, por lo cual no debe haberse notado la diferencia, pero en una elección más amplia seguramente lo haría.)

Un factor que agrava la situación es que la comparación de claves, al tratarse de cadenas, debe hacerse caracter a caracter (a diferencia de la comparación de valores enteros, que se realiza mediante una simple resta). Como veremos más adelante, en algunas tablas los valores del atributo clave en varias filas tienen un prefijo en común. Esto ralentiza aún más la comparación, y la situación es empeorada por la utlización de la codificación de caracteres UTF-8, debido a la implementación interna de PostgreSQL.

En mi opinión pudiendo usar valores enteros como clave, debieron haberlo hecho.

¿Relación inexistente?

Primero, una breve explicación del problema: La ciudad se divide en 3 circuitos electorales, en los cuales se encuentran las distintas escuelas, en donde a su vez están las mesas de votación. Como el sistema permite analizar circuitos, escuelas y mesas por separado, el primer diseño que cualquier programador pensaría es disponer de tres tablas: «circuitos», «escuelas» y «mesas» (en el caso de una elección provincial o nacional se agregarían algunas más). Entre esas tablas habría relaciones 1:N, es decir «1 circuito tiene N escuelas, 1 escuela pertenece a un circuito», «1 escuela tiene N mesas, 1 mesa pertenece a 1 escuela».

Aprovechando el hecho de que tanto las escuelas como las mesas tienen los mismos atributos, decidieron usar una única tabla, denominada «ubicaciones», según muestra el DER:

Es común utilizar este tipo de representación para estructuras de «árbol». Esto se logra agregando como atributo una clave foránea que referencia a la clave primaria de la misma tabla. En las filas «padre» dicho atributo tiene el valor «NULL«, en tanto que en las filas «hijas», dicho atributo contiene el valor de la clave primaria del padre.

Sin embargo, el código SQL de la estructura de la tabla «ubicaciones» es el siguiente:

CREATE TABLE ubicaciones (
    id_ubicacion character varying(12) NOT NULL,
    clase character varying(30) NOT NULL,
    descripcion character varying(100),
    sexo character(1),
    CONSTRAINT ubicaciones_sexo_check CHECK 
          (((sexo = 'F'::bpchar) OR (sexo = 'M'::bpchar)))
);

No existe ningún atributo que oficie de clave foránea para representar la relación en cuestión. ¿Cómo es esto posible?

Para comprender cómo está representada esta relación, fue necesario analizar los datos de la tabla (algo que, después de discutirlo con varios amigos, no pudimos llegar a la conclusión de qué principios de la teoría de bases de datos violenta, quizás algún lector pueda echar algo de luz al respecto). Encontre lo siguiente:

El «truco» consiste en utilizar parte de la clave primaria de una fila, para referenciar a la fila «padre». Por ejemplo, las claves de todas las mesas pertenecientes a la escuela «Adolfo Alsina» (cuya clave es «RC0101«) comienzan con el prefijo «RC0101«. De la misma manera, las claves de todas las escuelas del circuito «165» (cuya clave es «RC01«) comienzan con el prefijo «RC01«.

Ingenioso, pero totalmente innecesario y contrario a la teoría de bases de datos relacionales. De hecho, la relación está presente en el DER, pero no se ve reflejada en la base de datos. (Este tipo de representación de relaciones basadas en códigos era una práctica común de los programadores Cobol de otras épocas.)

Tipos de datos

Siguiendo con la tabla «ubicaciones«, podemos apreciar la siguiente restricción de integridad:

CONSTRAINT ubicaciones_sexo_check CHECK 
         (((sexo = 'F'::bpchar) OR (sexo = 'M'::bpchar)))

El objetivo de esta restricción es verificar que el valor del atributo «sexo» (de tipo «character(1)» sea «F» o «M«. Una forma más simple y eficiente, es definir un tipo de datos enumerado:

CREATE TYPE sexos AS ENUM ('F', 'M')

Esta misma situación se produce en otras tablas, incluyendo la reiteración de casos como el que sigue:

CONSTRAINT usuarios_carga_check CHECK 
          (carga = 'SI'::bpchar OR carga = 'NO'::bpchar)

Aquí, evidentemente, hubiera bastado definir al atributo «carga» de tipo «boolean«. (Esta restricción se encuentra en la tabla «usuarios«, en donde es reiterada tres veces.)

La tabla «estados» contiene los distintos estados en que puede encontrarse una planilla a lo largo del proceso:

CREATE TABLE estados (
    id_estado character varying(16) NOT NULL,
    descripcion character varying(50),
    bg_color1 character varying(7),
    bg_color2 character varying(7),
    prioridad integer,
    orden integer,
    accion character varying(20),
    CONSTRAINT estados_id_estado_check CHECK
         ((((((id_estado)::text = 'Espera'::text) 
          OR ((id_estado)::text = 'En Proceso'::text)) 
          OR ((id_estado)::text = 'Intranet'::text))
          OR ((id_estado)::text = 'Internet'::text)))
);

Aquí la restricción de integridad tiene como objetivo que restringir los valores de la clave «id_estado«, pero esto deja sólo cuatro posibilidades (de hecho, ¡los cuatro estados posibles de una planilla!). Codificar en el esquema de la base de datos los valores (fijos) de las claves de las cuatro entradas que luego tendrá la tabla no parece una buena idea. (Nuevamente, de juzgarse necesario, debería haberse utilizado un tipo enumerado.)

Otro punto cuestionable es la elección de los valores para codificar cada estado: varias palabras, uso de mayúsculas y minúsculas.

Otros errores

En el DER puede verse lo siguiente:

Esto parece indicar que no puede haber más de 2 planillas en el mismo estado, algo que es falso (de hecho, inicialmente todas las planillas están en el estado «Espera» y al finalizar están en el estado «Internet».

El DER también muestra la siguiente entidad:

La tabla que se corresponde con dicha entidad se llama «configuracion» (en singular).

Estos errores pueden parecer simples detalles (de hecho, en un sistema con solamente 11 tablas posiblemente lo sean), pero en un sistema más complejo pueden dificultar sensiblemente la programación, propendiendo a la comisión de errores.

Conclusión

Sin ser un experto en bases de datos relacionales (las utilizo desde hace más de 10 años como parte de mi trabajo, pero no me considero un especialista en la materia), los errores detectados me dan la pauta de que no se ha puesto el suficiente cuidado en el diseño de la base de datos, fundamentalmente de cara a la escalabilidad del sistema para soportar volumenes de carga mayores a los generados por proceso electoral como el de Río Cuarto (2 cargos electivos, 6 listas y 352 mesas).

De más está decirlo, dejo abierto este espacio a críticas y sugerencias respecto de este tema.

Este mecanismo se denomina «clausura» («closure«, en inglés), y aunque no es exclusivo de Ruby (es un viejo conocido en Smalltalk y Lisp, encontrándose aún en Perl y Python), la simplicidad de su uso lo transforma en una herramienta muy poderosa y flexible.

Quienes hemos programado en lenguajes funcionales (como ML y Haskell), siempre hemos extrañado en los lenguajes imperativos la posibilidad de pasar funciones como parámetros de forma «natural» (no a la manera en que puede hacerse en Java o Pascal, sino incluyendo las ligaduras al scope actual).

Un ejemplo simple

Supongamos que deseamos escribir una función que tome como parámetro un arreglo de valores enteros y retorne otro arreglo, producto de multiplicar por 2 cada uno de los elementos del parámetro.

En Java podríamos escribir algo así:

public static ArrayList double(ArrayList x)
{
  ArrayList y = new ArrayList();
  for (Iterator i = x.iterator(); i.hasNext(); )
    y.add(i.next() * 2);
  return y;
}

(Obviamente, olvidándonos de algunos casts para simplificar la lectura.)

O, en PHP:

function double($x) {
  $y = array();
  foreach ($x as $e)
    array_push($y, $e*2);
  return $y;
}

En tanto que en un lenguaje funcional, como Haskell podríamos escribir lo siguiente:

double x = map (*2) x

O, simplemente:

double = map (*2)

«map» toma como parámetro una función (en este caso, la función parcial «*2«) y un arreglo, devolviendo el resultado de aplicar dicha función a cada elemento del arreglo.

Veamos un ejemplo de la evaluación de double:

double [1, 2, 3]
[1*2, 2*2, 3*2]
[2, 4, 6]

Como podemos ver, la principal ventaja de los lenguajes funcionales es su expresividad, en el sentido de que el código del programa expresa de forma mucho más clara qué es lo que este hace (multiplicar por 2 cada elemento del arreglo).

En Ruby, aunque no es un lenguaje funcional, la posibilidad de pasar funciones (o, en general, bloques de código) como parámetro se presenta de forma igualmente sencilla:

def double(a)
  a.map {|e| e*2}
end

«map» es un método de la clase «Array» que toma un bloque de código y lo ejecuta para cada elemento del arreglo, devolviendo la colección de los resultados producidos. El fragmento «|e|» establece la ligadura entre el identificador «e» y el elemento actual.

Explotando la potencia de las clausuras

Supongamos ahora que tenemos una clase «Person«, cuyo método «age» calcula la edad de la persona. Si tenemos una colección de personas en el arreglo «people» y deseamos obtener sólo aquellas que son mayores de 18 años, en Ruby podríamos escribir lo siguiente:

people.select{|p| p.age > 18}

(El método «select» aplica una función lógica (booleana) a cada elemento y devuelve sólo aquellos para los cuales resultó verdadera.)

En tanto que si, además, quisiéramos mostrar el nombre de cada una de ellas, podríamos escribir:

people.select{|p| p.age > 18}.each{|p| puts p.name}

(El método «each» aplica el bloque a cada elemento del arreglo.)

O bien, de forma más compacta (sin generar un segundo arreglo):

people.each{|p| puts p.name if p.age > 18}

Comparación con otros lenguajes

Problema 1

Convertir las cadenas de un arreglo a mayúsculas.

En PHP:

for ($i = 0; $i < count($a); $i++)
  $a[$i] = strtoupper($a[$i]);

En Ruby:

a.map!{|e| e.upcase}

(El método «map!«, a diferencia de «map«, modifica el arreglo, en vez de retornar uno nuevo.)

Problema 2

Dado un arreglo de la forma [["nombre", "apellido"]], obtener un arreglo de la forma ["apellido, nombre"]. Por ejemplo, dado:

[["Javier","Smaldone"],["Santiago","Lobos"],["Bon","Scott"]]

obtener:

["Smaldone, Javier", "Lobos, Santiago", "Scott, Bon"]

En PHP:

$b = array();
foreach ($a as $e)
  array_push($b, $e[1] . ', ' . $e[0]);

En Ruby:

b = a.map{|e| e.reverse.join(', ')}

Problema 3

Calcular la edad promedio de las personas mayores de edad (según el ejemplo planteado anteriormente).

En PHP:

$sum = 0;
$count = 0;
foreach ($people as $p) {
  if ($p->age > 18) {
    $sum += $p->age;
    $count++;
  }
}
if ($count) print $sum/$count;

Una solución posible en Ruby sería:

adults = people.select{|p| p.age > 18}
sum = 0
adults.each {|p| sum += p.age }
puts sum.to_f/adults.size if adults.size > 0

Pero usando todo el poder de las clausuras y las funciones «map» e «inject«, podríamos escribir:

adults = people.select{|p| p.age > 18}
sum = adults.map{|p| p.age}.inject{|ac,e| ac+e}
puts sum.to_f/adults.size if sum

( «inject» ejecuta el bloque, asignando la segunda variable a cada elemento del arreglo y asignando el resultado de la ejecución a la primera, manteniendo su valor a través de cada iteración.)

Problema 4

Dado un arreglo de cadenas, obtener la de mayor longitud.

En PHP:

$max = '';
foreach ($a as $e)
  if (strlen($e) > strlen($max))
    $max = $e;

En Ruby:

max = a.inject {|m, e| e.length > m.length ? e : m }

(Adicionalmente, hemos usado el operador de asignación condicional «cond ? val1 : val2«, que retorna «val1» si «cond» es verdadero y «val2» en caso contrario.)

Conclusión

La posibilidad de utilizar clausuras nos acerca a la simplicidad y la expresividad de la programación funcional. Este es uno de los puntos fuertes del lenguaje Ruby (y la envidia de otros lenguajes, como Java, cuya comunidad está debatiendo sobre la posibilidad de incorporarlo en la versión 7).

(Y sí, se lo que pensará mi amigo Ricardo cuando lea este artículo. Es cierto, los lenguajes tienden a Lisp.)

Algunas referencias:

• Clausuras en Wikipedia (en inglés).
• Más sobre clausuras en Ruby.
• Clausuras en Python.
• Clausuras en Perl.
• Historia de las clausuras.