Posts Tagged Programación

¿Por qué son tan aburridos los libros de programación?

El ciclo de programación son los pasos que se ejecutan iterativamente al programar.

El ciclo de programación son los pasos que se ejecutan iterativamente al programar.

En un día cualquiera, teniendo unos minutos para leer, uno puede tomar un libro de física, de matemática, de biología, un tomo de alguna enciclopedia y hasta un libro de administración de empresas y pasar un buen rato leyendo alguno de los apartados. En general se disfruta, creo que yo sería feliz si pudiera trabajar leyendo en una biblioteca.
Pero cuando se intenta hacer lo mismo con un libro de programación el resultado es muy diferente.
No creo que mi percepción que se deba a que la programación es una de mis grandes pasiones, ni tampoco a que en general se le considera un tópico “complicado”. Lo que creo es que los libros de programación están en general muy mal hechos.
Para empezar la programación es algo eminentemente práctico y por lo tanto no se aprende leyendo teoría sino programando. Usualmente se enseña algo de teoría, pero la relación es más o menos de 20% de teoría contra 80% de práctica. Siguiendo esta fórmula muchos libros de programación parecen una mezcla de 20% de libro de matemáticas y 80% de libro de instrucciones para armar muebles “hágalo Usted mismo”.
En el diseño se visualiza la estrategia a seguir para resolver el problema, usualmente con un algoritmo.

En el diseño se visualiza la estrategia a seguir para resolver el problema, usualmente con un algoritmo.

Luego está el asunto de que siempre tiene que enseñarse un lenguaje concreto, no se puede enseñar programación “en genérico” o una forma de codificación que sirva para cualquiera. Entonces los libros sobre el tema siempre van amarrados a un lenguaje o dialecto computacional y eso los hace altamente vulnerables al paso del tiempo.
Como consecuencia cualquier libro de programación que uno tome del anaquel de una biblioteca probablemente está desactualizado en el lenguaje que utiliza aunque sus conceptos teóricos sigan vigentes la mayoría.
Tomar un libro de programación y pretender leerlo nada más significa que uno tendrá que negarse a poner en práctica inmediatamente los conceptos que están expuestos en él, lo cual no es sencillo porque los ejemplos abundan y no son como los de un libro de física, con el que basta tomar papel y lápiz para “practicar”, lo lógico con la programación es ir a la computadora y programar.
En la codificación se lleva el diseño a código en el lenguaje que se esté utilizando.

En la codificación se lleva el diseño a código en el lenguaje que se esté utilizando.

Estos libros intentan imponer un orden en la exposición de conceptos, pero en programación las herramientas se utilizan conforme se van necesitando, sin seguir necesariamente una jerarquía de complejidad, así que uno termina usando el libro para encontrar atajos y segmentos relevantes (“hacks”) que son lo que se necesita en el momento, saltándose capítulos y yendo de ejemplo en ejemplo.
Por supuesto, para eso es más útil una referencia del lenguaje, con lo cual el libro de programación pierde buena parte de su razón de ser.
Hay que repensar la forma en que se estructuran los libros y los cursos de programación. Para empezar hay que abandonar completamente la idea de que se utilice exclusivamente un lenguaje concreto como herramienta de apoyo. Algunos lenguajes son mejores que otros para mostrar técnicas como recursión, estructuras de control, manejo de errores, tipos de datos, algoritmos básicos, manejo de números, construcción de interfaces de usuario, etc.
Las pruebas implican ejecutar el programa en variedad de escenarios.

Las pruebas implican ejecutar el programa en variedad de escenarios.

Entonces lo que hay que hacer es enfocarse en la técnica y luego usar libremente el lenguaje que más convenga en cada caso, sea Java, C++, Pascal, Prolog, Basic, SQL, GPSS, Lisp, Scratch, Logo, Assembler, Python, PHP, HTML, Cobol, etc.
Para evitar el problema de que el lector quiera probar cómo funciona el ejemplo hay que cambiar el enfoque y convertirlos en retos del tipo ¿qué hace este código? ¿Qué error tiene? ¿Dónde podría mejorarse? ¿Es eficiente al aumentar la cantidad de entradas? Este tipo de razonamiento inducido es más beneficioso que simplemente copiar el texto en la computadora y ejecutarlo.
Luego hay que centrarse en las competencias básicas de un programador: recorrer el ciclo de programación, diseñar un programa antes de codificarlo, utilizar patrones, leer y entender código que no ha sido escrito por él en un lenguaje que no es el que domina, encontrar errores y depurarlos, etc.
Por supuesto el enfoque no es el mismo si se trata de libros dirigidos a estudiantes de primaria, secundaria o universitarios; si la carrera está relacionada con Ciencias de la Computación o si la programación se toma como una materia auxiliar. Pero definitivamente creo que se puede hacer algo mejor que revisar tediosamente todas las posibles estructuras y comandos de un lenguaje particular, que es lo que hacen buena parte de los libros que conozco.
Corregir cada problema o mal funcionamiento encontrado y volver a empezar el ciclo.

Corregir cada problema o mal funcionamiento encontrado y volver a empezar el ciclo.

Por último hay que terminar de separar completamente los cursos de programación en dos: la parte teórica en el aula y la parte práctica en el laboratorio – donde lo importante será precisamente ingresar código en la computadora y ejecutarlo – con textos independientes, el teórico con una vigencia mayor que el práctico.
Siempre he dicho que para cualquier ingeniero la habilidad de programar es tan básica como resolver ecuaciones o hacer un diagrama de fuerzas. La diferencia con los ingenieros de sistemas no es más que el enfoque y probablemente la intensidad. Así que tenemos una gran necesidad de buenos libros de programación, bien orientados y que puedan ser leídos con gusto aún 10 años después de haberse utilizado en un curso.
Algún día espero poder escribir un libro así.

3 Comments