Como has cambiado desde que te conocí.
El salto desde aquellas perforadas a los modernos entornos de programación utilizados en la actualidad es asombroso, y sin dudad muchos programadores de aquel entonces, seguramente se acuerden de aquellos tiempos ¿mágicos? en los que el código espagueti, el código que nos gritaba en mayúsculas o la presencia de los números de línea como parte indivisible de un programa eran lo normal.
Muchos de todo aquello que aprendimos han desaparecido o han evolucionado para convertirse en un recuerdo de un tiempo que marcó sin duda un antes y un después en la programación y que hoy esos programadores (y los no programadores) seguramente recordarán mucha nostalgia.
No me grites
El caso de las mayúsculas era algo curioso. En lenguaje ensamblador su uso era muy común, aunque la convención era poner nombres de variable en mayúscula y usar las minúsculas para las instrucciones. Lo normal era contar con variables limitadas en longitud, lo que obligaba además a usar acrónimos que hacían aún más característica la lectura de aquel lenguaje endiablado.
Mayúsculas, números de línea, GOTOS y POKES. Qué tiempos.
Otros muchos lenguajes siguieron utilizándose casi con puras mayúsculas, y eso convirtió en seña de identidad para muchos de ellos. FLOW-MATIC, el lenguaje con el que los programadores por fin pudieron programar «en inglés», es decir, con un lenguaje que se acercaba por primera vez al lenguaje natural.
FORTRAN es un caso muy especial: con FORTRAN existía cierta libertad para usar minúsculas en algunas palabras clave, pero no era lo normal. De repente FORTRAN se rebautizó como Fortran, y su compilador se convirtió en uno mucho más liberal al que no le importaba si uno trabajaba con mayúsculas o minúsculas. Aun así las convenciones sociales de los programadores volvían a imponerse: lo normal era utilizar minúsculas para variables locales y mayúsculas para términos nativos del lenguaje, mucho más importantes y que por tanto había que «decir gritando», por supuesto.
Y qué decir de COBOL, como sucesor natural de FLOW-MATIC, también estaba dominado por los gritos: todo se escribía en mayúsculas… salvo los comentarios, algo que recomendaban las propias convenciones de los desarrolladores.
Y luego estaba, por supuesto, BASIC, como olvidarte. Quizá parte de los que leen este artículo seguramente hicieron sus pininos en BASIC, un lenguaje con muy mala reputación en muchos apartados pero que sin duda fue muy importante a la hora de atraer el interés de niños que luego se dedicarían a la informática. Aunque posteriores versiones hicieron uso indistinto de mayúsculas y minúsculas, el uso de estas fue durante varios años algo común
Las limitaciones de los 6 bits y la sensibilidad al uso de las mayúsculas
Creo que la mayor culpa de esa obsesión por las mayúsculas la tenían los códigos de caracteres de 6 bits, que solo podían codificar 64 caracteres distintos y que por tanto «se conformaban» con incluir las letras mayúsculas, los números, algunos caracteres de puntuación y en ocasiones caracteres de control. Dichos códigos se extendieron especialmente gracias a los primeros ordenadores y mainframes de IBM, que los usaron en varias de sus primeras máquinas.
Al menos no había que lidiar ya con tarjetas perforadas. El avance fue excepcional, pero a los programadores aún les esperaban algunas revoluciones más como las de la programación estructurada o la programación orientada a objetos.
Hay que mencionar también uno de esos debates polarizadores entre los desarrolladores y programadores: el de los lenguajes sensibles a mayúsculas y minúsculas (case sensitive) y aquellos que no lo son. Jeff Atwood, cocreador de Stack Overflow, ya explicaba hace años cómo esto se ha convertido en una «cuestión religiosa» y cómo los argumentos a favor y en contra son notables.
Para Atwood, eso sí, los lenguajes sensibles a mayúsculas acababan siendo enemigos de la productividad, y aquí citaba el ejemplo que ofrecía otro programador conocido, Scott Hanselman, que contaba cómo se había pasado una hora depurando un problema en código sensible a mayúsculas y se había dado cuenta tras ese rato de que el error estaba en que «SignOn» no era lo mismo que «Signon».
Los GOTO y el código espagueti
Otra de las maldiciones que imponían algunos de los primeros lenguajes de programación era la que se bautizó como código espagueti (‘spaghetti code’). La razón, su falta de reglas de programación, la complejidad de su control de flujo y esa analogía con ese montón de hilos intrincados y anudados que forman los espagueti y que quedabas perdido y enredado entre tanta goto.
La instrucción más clara de este tipo de código era la sentencia GOTO que se utilizó en un gran número de lenguajes de programación —con BASIC como uno de sus referentes— y que para muchos hacía inmanejable y difícil de mantener cualquier código que lo usase.
Todos estos lenguajes también solían hacer uso de la numeración de las líneas de código (de nuevo BASIC como promotor de esas mecánicas) que eran una obligación puesto que los sistemas operativos de antaño no tenían editores de texto interactivos, y los editores trabajaban precisamente basados en esa numeración para poder referirse a cierta línea a la hora de editarla o insertar algo entre una y otra.
Los lenguajes no estructurados como Fortran o BASIC hicieron de este tipo de mecanismo, y fueron el detonante de la necesidad de la aparición de la programación estructurada en la que se buscaba mejorar la claridad, calidad y tiempo de desarrollo de cualquier programa.
De ahí pasamos a otras filosofías como la de la programación orientada a objetos que, por cierto, vio su propia evolución del código espagueti y contaba con el llamado código ravioli: el código contaba con clases bien estructuradas y fáciles de comprender de forma aislada, pero difíciles de entender como un todo.
Código bonito
Los programadores han aprendido mucho de aquella época, y hace tiempo que los lenguajes de programación tratan de ofrecer todo tipo de ayudas para hacer que la programación lleve menos tiempo y produzca código más claro de estudiar y analizar.
No solo eso: el propio trabajo de programar se adereza con elementos que ayudan a conseguir ese objetivo y a producir código bonito o, mejor dicho, limpio.
Entre esas ayudas destaca especialmente la indentación o sangrado del código, que permite mover bloques de texto a la derecha para separarlos del margen izquierdo y distinguirlo mejor del código adyacente.
Esta técnica es parte de las técnicas llamadas de notación secundaria que están desinadas a mejorar la legibilidad del código. El resaltado de la sintaxis con colores es otra forma común de ofrecer esa mejora que, eso sí, también introduce información redundante.
El uso de comentarios en el código —que viene de lejos, y en BASIC estaba presente con aquellos célebres «REM»— es también otro elemento importante para muchos desarrolladores, y suelen ser muy útiles para poder analizar el código a posteriori aunque para muchos introducen el peligro de abusar de ellos. Sin duda, muchas ayudas que han evolucionado y cambiado la forma de trabajar de los programadores. Xataka
