20 GOTO 10: Cuando el código espagueti, las mayúsculas y los números de línea atormentaban a los programadores
Cómo ha cambiado el cuento para los programadores. El salto desde aquellas perforadas a los modernos entornos de programación utilizados en la actualidad es asombroso, y de hecho muchos programadores veteranos probablemente 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 aquellos elementos 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 con un puntito de nostalgia.
No me grites, que no te veo
Lo 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 exclusivamente con mayúsculas, y eso convirtió esto 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.
El caso de FORTRAN es también muy especial: en aquel lenguaje habí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. Aún 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.
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. Muchos de los que nos leéis seguramente hiciérais vuestros pinitos 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 el debate sobre los lenguajes sensibles a mayúsculas
Parte de la 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. Entra ahí 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.
Si había un artífice claro de este tipo de código esa 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.
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.
Jogo bonito, 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.
Imagen | The 8-bit Guy
–
La noticia
20 GOTO 10: Cuando el código espagueti, las mayúsculas y los números de línea atormentaban a los programadores
fue publicada originalmente en
Xataka
por
Javier Pastor
.