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
Ver 20 comentarios
20 comentarios
dark_god
El código espagueti desafortunadamente seguirá existiendo toda la vida. Otro lenguaje case-insensitive es ADA. Yo soy defensor de no distinguir mayúsculas de minúsculas por dos razones, la primera como bien dice Atwood, puede inducir a error, y la segunda es que no tiene sentido poner mayúsculas o minúsculas cuando lo realmente importante es poner un nombre descriptivo. Y si, puede ser que mayúsculas se use para defines en C o constantes en java, pero es tan sencillo como empezar las constantes con "C_" o alguna historia así.
OrangeMg
Recuerdo que algunos profesores míos nos obligaban a comentar todo... hasta lo más obvio, tal como un letrero de piso mojado en el medio de una piscina.
No me tocó el código espagueti, pero por lo que tengo entendido viva por el código estructurado.
Usuario desactivado
40 años después ya no hay gotos pero sigue el código spaguetti.
Usuario desactivado
Quizás ya no haya (tantos) GoTo , pero aún hay quien usa break y return - y no pocos, que sin llegar al nivel del GoTo (podríamos llamarlo código macarroni en vez de spaghetti), sigue siendo bastante aberrante en lo que a código limpio se refiere.
Los métodos deberían tener una única salida, ubicada al final, y la condición (simple o compuesta) de permanencia/salida para un bucle debería estar en la declaración del mismo, y no dentro de él.
Y ojo, eran todas ellas instrucciones fruto de su época, imprescindibles en su momento, pero a día de hoy no deberían pasar una revisión de código mínimamente seria.
p2dzca
En principio, 'GOTO' debería ser cosa del pasado, del siglo pasado, como se indica en el artículo.
Lo cierto es que no lo es. Ahí está el infame 'goto' que permanecerá para siempre en la historia de Apple: en el año 2014 se detectó una vulnerabilidad en un programa de Apple que permitía aceptar certificados digitales que debían ser rechazados. Causa: un 'goto' mal puesto.
Mobilepadawan
BASIC fue un gran lenguaje que sobrepasó la barrera para la cual fue creado, llegando por supuesto a formar parte de Visual BASIC. Estudié los fundamentos de Python en 5 horas, y en todo momento me sentí que estaba programando en BASIC.
NDA: aprendí a programar con QBASIC en D.O.S. 6.0. Mi primera computadora fue una 286 usada con 2 MB de RAM.
Es una lástima que BASIC no supiera ocupar el lugar que ahora tiene Python, cuando C# comenzó a ganar terreno dentro del ecosistema .NET.
El código Spaghetti y código Raviol existirán por siempre y para siempre. Gran cantidad de los productos que hoy están en el mercado, y que usamos a diario, están compuestos de código Spaghetti.
No sé cómo será allá en España, pero aquí en Argentina y en USA, los programadores duran muy poco en su puesto de trabajo. Se aburren, sienten que ganan poco y se van a otra empresa. Eso hace que un módulo de software termine siendo escrito durante todo un año, por tres o cuatro desarrolladores distintos, cada uno con su estilo.
La alta rotación en estos puestos es la gran culpable hoy del famoso código Spaghetti. Aquí en Argentina hay mucho software estrella en este momento en el mercado, que está armado con este ¿paradigma?.
¿Cómo lo sé? Pues leyendo la reputación de una empresa en GlassDoor, te das cuenta que los programadores que se fueron protestan por esta filosofía. La madeja de lana que hay en el Backend y, que por lo tanto, se termina trasladando al Frontend.
Saludos desde ARG.
eligio
Completamente de acuerdo con muchos de los comentarios leídos. Cabe destacar que el GOTO nunca murió sino que evolucionó para no ser la oveja negra de la programación. En QBasic se introdujeron las etiquetas con los ":" para poder saltar elegantemente y no recurrir al indexado de lineas. Se podían seguir usando números de lineas pero era mas elegante decir "Gosub Empezar" que "Goto 120". Ademas el Gosub permitía el Return a la linea que lo llamaba. Esto junto a las subfunciones fueron la revolución para maquillar el Spaguetti. A día de hoy javascript no deja de ser esto pero retornando código de vuelta en las llamadas.
lbiohazardl
El código espagueti sigue siendo pan de cada dia ... como ingeniero en performance es toda una pesadilla seguirlo para encontrar los puntos de optimización
Gracias a dios el 90% de las veces los errores de los programadores son tan obvios que el análisis de código para su optimización solo es requerido en casos excepcionales
robertgarcia2
El código espagueti sigue y no parece que vaya a dejar de existir pronto.
Por ejemplo puedes verlo en páginas web programadas con CSS, PHP, Javascript, HTML sin orden ni concierto es una mezcla difícil de descifrar.
O incluso en lenguajes orientados a objetos, depende mucho del programador más que de las herramientas.
mantuano
yo uso iniciales mayúsculas para todas las referencias a objetos o procedimientos cuando son a base de punteros - referencia - y todo mayúsculas con objetos referidos por valor, y los exportables, siempre inicial mayúscula.
El C tiene el inconveniente de ser global a menos que se especifique lo contrario, pero es un buen lenguaje, por lo simple, y si se sabe lo que se hace, no usando saltos, resulta admirablemente util y capaz.
Personalmente prefiero un tipo algol, Pascal, Modula-2 o Modula-3, por el encapsulado directo tanto de variables como procedimientos, y la posibilidad de orientación a objetos, lo que en C++ uue es mucho más complicado resulta muy trabajoso.