Javier Romera repasa su experiencia en programación. Desde la época en la que programaba en ensamblador usando un «human and pen assembler», hasta el momento actual en el que ve cómo algunos programadores usan herramientas como MIT APP INVENTOR para programar jugando a rompecabezas. Parece que no aprendemos esta máxima: pensar primero y programar después.
Una historia personal.
Mucho tiempo ha pasado desde que se comenzó el concepto de programación. Y mucho tiempo ha pasado desde que, en mi época de estudiante, programaba mi UC 1003 EMR (traído oculto ilegalmente desde Francia, ya que había que declararlo en la frontera) en lenguaje ensamblador empleando el “human and pen assembler” (término que uso para describir que no tenía ningún medio para emplear un ensamblador real).
De ahí al BASIC que se empleaba en alguna asignatura de la carrera. Sobre un PDP 11 con terminales electromecánicos a 110 bauds había un salto enorme… hacia atrás.
Al comenzar a trabajar dispuse de acceso a un INTEL MDS-80, que incluía un ensamblador y ¡oh maravilla! un compilador de un lenguaje de alto nivel: PL/M.
Y el mundo se lanzó a una carrera. Ordenadores personales que empezaron a ser asequibles; aparecieron compiladores a precio “razonable” que antes solamente eran asequibles para grandes corporaciones; bajaron los precios de los ordenadores mientras aumentaban sus capacidades; y aparecieron los ensambladores y compiladores libres y otros gratuitos…
Llegamos a hoy, en el que veo cómo algunos “programadores” (permítaseme el uso de comillas) son usuarios asiduos de MIT APP INVENTOR y programan jugando a los rompecabezas.
Libros para pensar.
Todo esto viene a colación del hecho de que, a pesar de haber empleado a lo largo de mi carrera una amplia gama de lenguajes en mayor o menor medida, hay una cosa que no parece haber cambiado mucho: independientemente del lenguaje ensamblador utilizado, entorno de trabajo que se emplee, es necesario pensar primero y programar después.
Hay numerosos libros dedicados a la “filosofía de la programación” y se han elaborado numerosos estudios dedicados a cómo programar mejor. El libro The Mythical Man-Month supuso una revolución en un mundo en el que el tamaño de los programas y la cantidad de memoria crecían de forma rápida. Mientras, la complejidad de los programas lo hacía de forma exponencial hasta hacerlos inviables por falta de organización.
Pero hoy hablaré de uno que supuso para mí un avance, o más bien una reafirmación, en mi forma de tratar de la programación. No es ese que comienza con la frase “cualquier idiota puede escribir código”. Ese lo dejo para otro momento.
El libro se refiere a un lenguaje de programación ya en declive: el lenguaje FORTH. El libro en cuestión se titula “Thinking FORTH: A Language and Philosophy for Solving Problems” y puede descargarse desde este enlace.
Pensar primero.
Solicita a un arquitecto que haga una casa. Es poco probable que lo primero que haga sea ir a por una excavadora y presentarse en el terreno. Dile a un programador que haga un programa y muy probablemente se abalanzará sobre el teclado para comenzar a escribir código.
La misión de un programador no es “escribir un programa” sino “resolver un problema” (que puede resolverse mediante programación). Para resolver un problema, el primer paso es comprender el problema. “Lee atentamente el problema y compréndelo antes de intentar resolverlo”, me decía mi profesor de matemáticas.
Y eso no se hace comenzando a escribir código.
Analizar lo global y pensar en el detalle.
Atacar un problema complejo de forma global es una tarea inabarcable. Pero perder la visión global nos hacer perder la esencia del problema que se ataca. Dividir el problema en partes ayuda a ver más en detalle cada parte. Pero ¡cuidado! Cada parte debe analizarse pensando en su relación con las otras partes.
Esta aproximación doble debe realizarse una y otra vez hasta tener el todo y las partes claramente organizadas en la mente, en un esquema sobre un papel… A partir de este momento se puede comenzar a codificar. Al comenzar a codificar con la visión global, se es más consciente de lo que se hace y las implicaciones que tiene para el resto del trabajo. Y es posible que surjan cambios de visión.
Comprobar el resultado y aprender.
Un programa es una obra compleja. Pero, a diferencia de otras obras, un programa tiene que funcionar. No solo más o menos, sino lo más cerca que sea posible de la perfección.
Desgraciadamente, no es fácil ver los fallos de nuestra propia obra. Se necesita un espíritu crítico para reconocer los propios fallos. Pero es necesario para mejorar. Cada fallo debe ser una fuente de razonamiento para mejorar. Lo que nos hace mejores programadores es la mejora de la visión global del trabajo (recordemos: “resolver problemas”) y no una lista de posibles errores de estilo que pueda corregir un “lint”.
Conclusión.
Cada persona, en base en la experiencia acaba creando un estilo propio. Al igual que podemos reconocer la mano de un pintor en un cuadro o la de un arquitecto en un edificio, también es posible reconocer a un programador en su código.
Escribir buen código no es solo seguir unas normas (que pueden ayudar) sino pensar en escribirlo correctamente de principio a fin, es decir, desde el concepto hasta la validación. Para no cometer errores, usa MIT APP INVENTOR (lástima que no sirva para el 99% de mis trabajos. Por cierto, tampoco JAVA).
A pesar de lo que he dicho antes sobre el declive, aprender un lenguaje ensamblador diferente es aprender una forma diferente de pensar. En este sentido, el lenguaje FORTH aporta mucho ya que se trata de un lenguaje con una estructura que obliga a pensar de forma diferente. Dale una oportunidad.
Yo le estoy dando una a Kotlin y sus herramientas asociadas como entorno de trabajo para el desarrollo de aplicaciones Android. Y creo que me aporta aspectos nuevos en mi forma de ver este oficio. Un largo viaje desde el ensamblador mental hasta aquí.