Marcos Merino
EditorCuando hablamos de lenguajes de programación "difíciles" y/o "odiados", es relativamente habitual que surjan nombres como C++, Java, PHP o incluso JavaScript. Sin embargo, para muchos programadores veteranos, hay un lenguaje que se lleva la palma como el peor de todos: GW-BASIC.
A pesar de haber sido el punto de partida en la programación para miles de personas en los años 80, este lenguaje representaba una auténtica pesadilla en términos de usabilidad, estructura y mantenimiento del código.
El escritor y desarrollador Huw Collingbourne ha explicado en su canal de YouTube todas las razones legítimas para tenerle cierta "inquina" a este lenguaje.
Los orígenes de GW-BASIC
A principios de la década de 1980, la informática personal comenzaba a despegar. Los primeros PC con MS-DOS solían incluir, de forma gratuita, un lenguaje de programación básico: GW-BASIC. El nombre nunca tuvo un origen oficial claro; algunos lo atribuían a 'Gee Whiz' ("¡Caramba!", en inglés), como una expresión de sorpresa ante la programación de software.
La gratuidad y disponibilidad de GW-BASIC lo convirtieron en el primer lenguaje de muchos programadores autodidactas, pero también en la fuente de frustraciones que marcaron sus inicios.
Obstáculos que hoy resultan impensables
Y es que, comparado con cualquier lenguaje moderno, GW-BASIC parecía más un campo minado que un entorno de programación. Lo que para nosotros hoy es lo mínimo esperable en un lenguaje o en un editor, simplemente no existía en aquellos años.
I) La tiranía de los números de línea
El rasgo más característico (y temido) de GW-BASIC era la necesidad de numerar cada línea de código. Así, un programa típico podía comenzar con algo como:
10 LET X = 1
20 X = X + 1
30 IF X > 10 THEN GOTO 100
40 PRINT X
50 GOTO 20
100 END
¿Por qué se dejaban saltos de diez en diez? Fácil: para poder insertar nuevas instrucciones después. El problema surgía cuando el espacio intermedio no era suficiente: si querías añadir veinte líneas entre el 10 y el 20, te encontrabas con un callejón sin salida.
La única solución era mandar el flujo de ejecución a otra parte del código, a veces en la línea 5000 o 10000, generando lo que más tarde se conoció como 'código spaghetti': un enredo de saltos ininteligibles y difíciles de mantener.
II) GOTO: la receta para el caos
En lugar de estructuras modernas como funciones o procedimientos con nombres claros, GW-BASIC dependía de comandos GOTO y GOSUB. Estos trasladaban la ejecución a otra línea del programa, sin ofrecer contexto ni modularidad. El resultado era un laberinto de saltos donde seguir la lógica del programa era casi imposible.
Los programadores que venían de lenguajes más estructurados, o que luego pasaron a Pascal o C, recuerdan con horror la dificultad de depurar errores en medio de ese enredo de instrucciones.
III) La ausencia total de herramientas de depuración
Hoy en día damos por sentado que podemos detener la ejecución de un programa, inspeccionar variables, establecer puntos de ruptura e incluso visualizar la pila de llamadas. En GW-BASIC, nada de eso era posible. La única manera de entender qué estaba fallando era llenar el código con instrucciones PRINT estratégicamente colocadas:
100 PRINT "X vale "; X
110 PRINT "Entrando en el bucle"
Esto no solo ensuciaba el programa, sino que generaba aún más caos al obligar al programador a borrar, mover o añadir estas líneas de depuración improvisada.
IV) La imposibilidad de estructurar el código
GW-BASIC carecía de funciones y procedimientos con nombres significativos. Toda la lógica debía organizarse en una secuencia lineal, con saltos mediante GOTO o GOSUB. Esto significaba que no existía la reutilización real de código: cualquier comportamiento que se repitiera debía escribirse varias veces o resolverse con un salto a otra línea numerada.
El resultado era un monstruo difícil de leer, mantener o ampliar. En contraste, incluso los lenguajes contemporáneos como Pascal ya ofrecían módulos bien definidos, lo que marcaba la diferencia entre un programa caótico y uno comprensible.
V) Tipado implícito y frágil
GW-BASIC tenía un enfoque 'liberal' en lo que a las variables respecta: no hacía falta declararlas. Bastaba con usarlas y el intérprete asignaba un tipo según el contexto. Esto, que hoy asociamos a lenguajes dinámicos modernos como Python o Ruby, en GW-BASIC era una trampa sin red de seguridad.
Un error de tipeo en el nombre de la variable (total frente a totla) podía crear una nueva variable sin avisar. Operaciones tan simples como sumar un número a una cadena podían provocar fallos catastróficos.
VI) Un editor rudimentario
El propio entorno de GW-BASIC era otra limitación: no había resaltado de sintaxis, ni autocompletado, ni ayuda contextual. El programador escribía a ciegas, sin soporte visual que le ayudara a detectar errores.
Para modificar un programa largo había que recordar el número exacto de la línea a editar. Insertar o eliminar fragmentos enteros se convertía en una tarea titánica, y más de un proyecto acababa abandonado porque reorganizarlo resultaba más complejo que volver a escribirlo desde cero.
VII) Sin archivos fuente legibles
Aunque GW-BASIC permitía guardar los programas, estos se almacenaban en un formato propio y no siempre fácil de compartir o versionar. La idea de un control de versiones —algo básico hoy en día con Git— era completamente impensable en aquel contexto. Cada copia del programa era, literalmente, la última y única versión válida, lo que hacía perder trabajo con frecuencia.
El contraste: Turbo Pascal y la programación estructurada
La salvación para muchos llegó con Turbo Pascal, lanzado a mediados de los 80. Este lenguaje introducía conceptos revolucionarios en comparación con GW-BASIC:
- Declaración explícita de variables.
- Procedimientos y funciones con nombres significativos.
- Tipado estricto y control de errores en tiempo de compilación.
- Herramientas de depuración básicas pero muy superiores.
Pasar de GW-BASIC a Turbo Pascal fue, para toda una generación, como pasar de un laberinto oscuro a una autopista bien iluminada. No solo facilitó escribir programas más fiables, sino que enseñó prácticas sólidas de programación que aún hoy siguen vigentes.
Al final, GW-BASIC puede considerarse un lenguaje de transición: incómodo, limitado y mal diseñado, pero que empujó a muchos hacia opciones mejores. Su legado más importante quizás no sea técnico, sino pedagógico: enseñó, a base de errores y frustración, cómo NO se debe programar.
Imagen | Marcos Merino mediante IA
