Reaprender a programar y backward compatibility

Ultimamente he optado por aprender a programar. Pero cuando digo aprender me refiero a aprender en serio, no ha estar en condiciones de entender un código, o modificar un script de bash, o realizar un desarrollo eventual para la Web o una solución a la medida. Me refiero a sentirme en relación intima con un lenguaje. A pensar en términos de ese lenguaje. A escribir poesia, si se quiere ver de ese modo.

Los candidatos, como lenguajes con los cuales intimar, eran al comienzo eran PHP y Perl. Ambos tienen atractivos, están "de moda", se ven bien en hojas de vida y se integran bien con bases de datos y la Web. Todas estas son exelentes razones prácticas. Sin embargo, si se tratara sólo de ser práctico me hubiera quedado con lo que aprendí en la universidad durante la ya casi terminada carrera y aprendería lo necesario cuando fuese necesario. Al final opté por Scheme, un lenguaje funcional. La idea es empezar con él y luego establecer un puente que permita abordar Haskell o Lisp. Es una decisión "impopular", no es que tenga algo en particular contra Perl o PHP, por el contrario ambos me agradan. La razón es otra, en últimas lo que estaba sopesando era si iniciar el (re)aprendizaje con la programación imperativa o con la programación declarativa, ahora que aprender estaba en la tranquilidad de mis manos y no en la angustiosa carrera del currículo.

Parece natural que la programación declarativa sea más fácil de aprender que la programación imperativa. Sin embargo los currículos tradicionales no brindan una exposición fuerte a la programación declarativa, salvo una leve pasada por los cursos de bases de datos y eventualmente algo de lo que se hace en programación funcional en cualquier paquete de álgebra computacional. Es más, el "golpe" de aprender a programar tiene que ver con el cambio en la forma de pensar. Cuando se colocan los primeros ejemplos, que introducen a los estudiantes a la programación, acerca de cómo resolvemos problemas cotidianamente la pregunta está viciada de por sí. Se pregunta por "cómo es la solución" sin embargo parece ser que estamos habituados a pensar en "qué es la solución". Las preguntas por el cómo, por supuesto hacen parte de nuestro acervo. Sin embargo en términos de lo procedimental parace haber poca "convergencia de soluciones". Al final cada cual mata sus pulgas como puede. Es decir los métodos de solución que dan respuesta al "cómo" obedecen a idiosincracias muy particulares, pero las definiciones que dan respuesta al "qué" parecen ser más consensuales.

Un ejemplo clásico (que no es mio, porque no soy ningún clásico a pesar de los años ;-) ) está en los algoritmos de ordenamiento: Ordenar una lista dada de objetos. En la programación imperativa se debe responder a este problema diciendo cómo se ordena. Diferentes cómos generan diferentes respuestas, por ejemplo el algoritmo de ordenamiento en burbuja, y otros más (agrégelos aquí de acuerdo al gusto). En la programación funcional se responde al problema diciendo qué es ordenar y esto genera una respuesta "convergente": Ordenar es colocar los elementos más pequeños antes (o después) de los más grandes. Una vez realizada esta definición el interprete del lenguaje se encarga de aplicarla reiterativamete y/o apelando a primitivas del lenguaje hasta que el orden se ha establecido. Cómo el intérprete del lenguaje realiza tal ordenación es trasparente al programador de modo similar a como en las base de datos las consultas son hechas por el motor de bases de datos una vez son declaradas por el administrador.

Programar es una labor artesanal que se aprende con los dedos. Al igual que el artesano el programador requiere colocar las manos sobre el material de forma constante para hacer explícitos los diseños. El hilar del artesano es el teclear del programador. Se requiere paciencia, constancia, humildad, disciplina.

Por lo pronto he empezado ha hacer una "traducción" de algunos problemas resueltos del solucionario del libro How to Desing Programs (una secuela de los mismos autores de Structure and Interpretation of Computer Programs , que me recomendaron Alejo y Nelsón) [1]. Y digo traducción entre comillas, porque con esta conexión telefónica tan "pichurrea" aún no he descargado las respuestas, así que las estoy haciendo en español y luego las compararé con las que descargue.

Voy a proponer traducir ese libro (al menos parte del solucionario) como proyecto de Calix . Habrá que esperar que opinan los demás. Rafa y Guio se han mostrado interesados en la programación funcional, pero del dicho al hecho hay mucho trecho.