Como vimos en el anterior post, una de las grandes obsesiones de Dijkstra fue tratar de eliminar la sentencia GO TO de los lenguajes de programación de alto nivel. Para cualquiera que no tenga conocimientos de informática, esto le sonará probablemente a chino
, así que tratemos de aclarar algunos conceptos…
Cualquier programa informático (desde un editor de texto como Microsoft Word, un sistema operativo como Windows o Linux o mismamente un videojuego) en su origen no es más que un conjunto de miles de líneas de texto detallando lo que el programa hace en cada momento. A esto lo llamamos código fuente. Pongamos un ejemplo básico y simplón para entendernos. Si quisiésemos programar el Super Mario Bros. , parte de su código fuente sería tal que así:
Comprobar que a Mario le queden vidas
Si a Mario le quedan vidas
entonces la partida continúa
Si se aprieta el botón A
entonces Mario salta
Si se aprieta el botón ABAJO encima de una tubería
entonces Mario se mete en ella
Mientras dure el efecto de la estrella, Mario es invencible
Evidentemente, ni Super Mario Bros. ni ningún otro juego están programados con un lenguaje como este
(de hecho, los juegos de consola antiguos están programados en ensamblador, un tema que dará para algún que otro interesante post más adelante…) ni es tan sencillo ni intuitivo como puede parecer, pero supongo que sirve para introducirnos en lo que es el código fuente. Sin embargo, tampoco penséis que un lenguaje de programación de alto nivel sencillo (como puede ser Pascal) es tan, tan diferente de lo que he puesto ahí
. En realidad, y adaptándolo un poco a las características propias del lenguaje y de la propia programación, podría ser bastante parecido.
Una vez el programador ha completado el código fuente del programa, utiliza un compilador sobre él. Un compilador, en su definición más general, no es más que un programa que traduce un texto de un lenguaje a otro. En este caso, traduce el código fuente ( que está escrito en un lenguaje de programación como pueden ser C++, Java, Pascal, Perl, PHP…) a código máquina, o lo que es lo mismo, únicamente ceros y unos, que es, a fin de cuentas, lo único que comprende un ordenador. De esta forma, hemos obtenido un ejecutable, también llamado binario por los de unos y ceros, que, como su propio nombre indica, ya podemos ejecutar en la máquina.
¿Qué papel juega la sentencia GO TO en todo esto? pues recurramos nuevamente al ejemplo de antes, sólo que ahora enumeremos las líneas…
0001: Comprobar que a Mario le queden vidas
0002: Si a Mario le quedan vidas
0003: La partida continúa
0353: Si se aprieta el botón A
0354: Entonces Mario salta
0455: Si se aprieta el botón ABAJO encima de una tubería
0456: Mario se mete en ella
0678: Mientras dure el efecto de la estrella
0679: Mario es invencible
Obviamente, el código fuente del Mario (de cualquier programa, vamos) sería muchísimo más grande, de ahí que numere de esa forma (se supone que entre la línea 0003 y la 0353 hay muchas otras). Si empleamos la sentencia GO TO, el código quedaría más o menos así:
0001: Comprobr que a Mario le quedan vidas
0002: Si a Mario le quedan vidas entonces GO TO 0003
0003: La partida continúa
0353: Si se aprieta el botón A entonces GO TO 0354
0354: Mario salta
0455: Si se aprieta el botón ABAJO encima de una tubería entonces GO TO 0456
0456: Mario se mete en la tubería
0658: Mientras dure el efecto de la estrella GO TO 0659
0659: Mario es invencible
GO TO, que, como sabéis, podríamos traducir como ir a, va al final de cada línea indicando a dónde se tiene que ir en caso de cumplirse la condición, o dicho de otra forma, dónde está la siguiente línea (o instrucción) que debe procesarse. De esta forma, el orden de las instrucciones pierde relevancia; la sentencia GO TO modifica el flujo del programa (en pocas palabras, qué instrucciones y en qué orden se ejecutan) a su antojo.
Vale, así contado la verdad es que la instrucción GO TO puede parecer útil y muy flexible, pero es precisamente esa flexibilidad donde radica su peligro y los motivos de su obsolescencia; pensemos que cualquier programa mínimamente complejo tendrá miles y miles de líneas de código fuente, con millones de flujos de programa posibles diferentes. Si alteramos dicho flujo con la sentencia GO TO de un modo incontrolado, el código se volverá totalmente caótico, y por tanto muy difícil de controlar, depurar, mejorar o entender, lo que nos llevará, inevitablemente, a ejecutables (programas) de escasa calidad.
Como mejor alternativa a la sentencia GO TO, que, no obstante, se sigue usando en algunos casos, surgieron las estructuras de control, sobre las que también me gustaría hablar, pero no se si me ha quedado un artículo demasiado aburrido, ininteligible o ambas cosas. Tenéis los comentarios para hacérmelo saber, y en función de eso, decido
.