Repetición cíclica y aprendizaje

Una de las implicaciones de lo dicho en la nota El progreso de un aprendiz sería la idea de la repetición cíclica y su potencial relación con una idea general de aprendizaje.

¿De qué tipo de repetición cíclica estamos hablando aquí? Claro, no una que sea mecánica e irreflexiva, sino una que implique retroalimentación y la consecuente adaptación para el ciclo sucesivo.

Si por aprender también entendemos cambiar o mejorar en algo, entonces en cada ciclo uno podría identificarse algún delta de cambio o mejora en ese algo, por mínimo que fuese y cualquiera que fuese su signo (pues no toda repetición implica avance). En mi caso, una frecuente dificultad está en identificar ese delta pues suelo permanecer ciego de mi propio desempeño, o tiendo a ver sólo lo que me causa autocomplacencia, o estoy tan cerca de la situación que no alcanzo a ver el panorama y las deficiencias que se hacen aparentes sólo a distancia. Por eso, con la misma frecuencia, necesito la retroalimentación de otros.

Hay muchas corrientes y escuelas de pensamiento para la programación de computadoras, y, por fortuna, hay muchas donde la cooperación tiene un lugar predominante. Es decir, donde el diseño detallado (también conocido como «código fuente») es visto y revisado con frecuencia por más de un solo par de ojos. Por lo tanto, si alguno aquí busca ser practicante –como sigo intentando ser– de alguna de esas corrientes o escuelas cooperativas de programación, entonces podría, si gusta, compartir algún diseño detallado del que quiera retroalimentación. Así, los interesados podremos aprender juntos algo.

¿Alguien se anima?

Estudiar código de otros

La sola idea de aprender a programar no deja de interesarme. Quizá es por lo que solía decir Kristen Nygaard: «To program is to understand.»

Recién recordé años imberbes, y en perspectiva, reconozco la influencia que entonces tuvo tener en mis manos el clásico: Algorithms + Data Structures = Programs, de Niklaus Wirth (la edición Prentice-Hall de pasta dura de febrero del 76). Mirar el código en esas páginas, y sentir la urgencia de intentar esos programas en alguna computadora con el fin de entender lo que ocurría, fue emocionante.

Los básicos de la programación en ese libro siguen, para mí, igual de vigentes. Además, hay otros excelsos libros de introducción a la programación. Por fortuna puede uno acudir a maestros como Bjarne Stroustrup o Bertrand Meyer que, como Niklaus Wirth, son autores generosos. Por fortuna, podemos sopesar sus palabras que dirigen con lucidez a quienes buscamos aprender a programar; un par de ejemplos son las siguientes referencias. Además, reproduzco un párrafo del prefacio del maestro Meyer que al repasarlo me hizo recordar cuán importante es estudiar el código de otros.

Programming — Principles and Practice Using C++, por Bjarne Stroustrup.

TOUCH OF CLASS — Learning to Program Well with Objects and Contracts, por Bertrand Meyer.

«Because from day one of the course you will have the whole power of EiffelStudio at your fingertips, you will be able to skip many of the “baby” exercises that have traditionally been used to learn programming. The approach of this book is based on the observation that to learn a technique or a trade it is best to start by looking at the example of excellent work produced by professionals, and taking advantage of it by (in order) using that work, understanding its internal construction, extending it, improving it — and starting to build your own. This is the time-honored method of apprenticeship, which places newcomers under the guidance of experts.» —Bertrand Meyer

¿Por qué reflexionaría un programador de computadoras?

Jugar con una computadora ha sido para mí una constante fuente de gozo y diversión desde mi etapa adolescente. La idea de controlarla para que aparezca algo en la pantalla o para que haga diferentes cosas al pulsar diferentes teclas ha sido para mí puro pasatiempo. Aún recuerdo mi sorpresa al escuchar que jugar de esa manera podría ser un trabajo remunerado. Estaría dispuesto a pagar por la oportunidad de pasar mi tiempo divirtiéndome al explorar una computadora, cuán interesante ha sido que no he tenido que pagar sino que me pagan por jugar y divertirme al controlar computadoras para que hagan con exactitud lo que yo les dicto (algunas veces lo hacen). Cuánto más afortunado ha sido que hay mucho por leer y aprender sobre cómo controlarlas cada vez mejor. Ejercer control sobre un objeto complejo como una computadora es algo muy divertido para mí. El juego se llama: administrar la complejidad para lograr la ilusión de control y de simplicidad, entre más control y más simplicidad, más diversión.

Un aspecto de especial placer estético para mí ha sido el teclado. Me parece como una especie de clavicordio, el teclado me parece un extraordinario mecanismo sobre el cual puedo poner mis manos para intentar lograr algo artístico. Una computadora de hoy es una muy notable maquinaria.

Programar para mí no es un “trabajo” que me veo en la necesidad de hacer para obtener dinero. Para mí, programar computadoras es un juego y, por tanto, tiene que ser divertido y adecuado para muchas horas de ocio; de otra manera no tendría sentido para mí hacerlo. El “trabajo”, aquello obligado e indeseable, no ofrece espacio para reflexiones ociosas pues el trabajo es lo contrario al tiempo libre de una persona. Programar una computadora para mí es siempre una opción para mi tiempo libre, para mi ocio. Es ahí, en la recreación, donde se busca más gozo y más diversión, ahí cobran sentido las preguntas y la indagación por el conocimiento que ayude a avivar ese deleite. Pues el conocimiento intensifica el goce.

Por otro lado, otra condición para la reflexión es la tragedia. La desdicha puede impelernos preguntas que en otras condiciones no haríamos. Pasar muchas horas diarias haciendo algo de manera obligada e indeseable suena como un infortunio, como una tragedia. Ahí, al padecer el “trabajo”, también tienen sentido las preguntas y la indagación que ayuden a disminuir el tormento.

Regresar a los básicos implica formular preguntas muy básicas. Por ejemplo, ¿a qué nos referimos cuando decimos “programar una computadora electrónico-digital”? ¿En qué consiste hacer eso, aun si sólo queremos lograr algo “práctico”?

Reflexionaré más sobre esa pregunta más adelante. Aquí sólo citaré lo que el autor de The Art of Computer Programming ha escrito en varias publicaciones:

«Science is what we understand well enough to explain to a computer. Art is everything else we do.» —Donald E. Knuth