Hoy he desempolvado un manual de programación de Basic del año 1984 y me ha dado por releerlo para rememorar aquellos tiempos. Realmente es curioso leer ciertos puntos en hoy en día no se nos podría ni ocurrir tener que explicar o que en la actualidad está totalmente deprecated.
En este post voy a citar algunos párrafos de este manual que me parecen interesantes comentar para analizar como hemos evolucionado o por el contrario que puntos seguimos arrastrando en lenguajes más modernos. Así que hoy nos pondremos un poco retro y nostálgicos.
Predicciones
Uno de los textos que me ha llamado la atención es la predicción acertada de la importancia de la informática cuando en aquella época prácticamente nadie tenía ordenador:
El curso se crea pensando que todo el mundo debe aprender como funciona un ordenador, y todo el mundo puede aprender a programarlo y está estructurado de forma que es asequible incluso a los niños. Esperamos lograr nuestros objetivos y que el mundo del futuro, un mundo con ordenadores, no les pille desprevenidos...
Este párrafo comenta que todo el mundo deberá interactuar con ordenadores, algo que cada vez más se va determinando. Quizá no fue tan acertado el hecho de la facilidad de programar que incluso un niño podría hacerlo ya que en la actualidad se ha establecido la distinción entre el perfil de usuario y programador siendo estos perfiles diferentes. Hay que comprender que antes, para usar un ordenador, era necesario aprender algunos comandos por lo que estaba más cercano a la programación. De ahí la estimación del autor.
¿Como se maneja un ordenador?
Otro párrafo que en la actualidad sería impensable explicar en un manual de programación es el siguiente:
¿Como se maneja un ordenador? La forma más normal de trabajar con un ordenador es por medio de un teclado y una pantalla (que será una televisión doméstica o un ordenador especial). El teclado sirve para introducir las órdenes y los datos que se le dan al ordenador. Lo que se escribe sobre el teclado se visualizará simultáneamente en la pantalla, aunque ésta también sirve para que el ordenador presente resultados, informes, mensajes, etc…
Es curioso la inmadurez en aquella época del uso de ordenadores que era necesario explicar que se hay que pulsar las teclas y que la información se visualizaba por la pantalla. En la actualidad explicaciones semejantes, y más en manuales de programación, serían impensables. No lo descarto para manuales de usuario aunque tiene poca probabilidad de que se explique esto.
Líneas numeradas
Una característica del antiguo Basic que siempre vi como algo normal y que me sorprendió gratamente cuando conocí C es la necesidad de numerar las líneas. De hecho, existía una técnica recomendada para ello:
Los números de línea son simplemente ‘etiquetas’ que sirven para marcar cada línea con el objeto de identificarlas de modo único. Son números válidos cualquier entero entre 0 y 62000. Suelen numerarse las líneas de 10 en 10 para poder insertar nuevas sentencias entre dos ya escritas si fuera necesario.
Es decir que en el código fuente una vez escrito el programa, solo se podía añadir 9 líneas más entre línea y línea. Sin embargo, si nos quedabamos sin líneas para escribir disponíamos de la instrucción RENUM que volvía a renumerar de 10 en 10 estas líneas sincronizando todas las referencias realizadas en los GOTOs y GOSUBs. Es la actualidad, se ha madurado enormemente este tema y gracias a ello podemos hacer programas mucho más fáciles de mantener.
Listar el código fuente
Otro punto curioso es el modo de ver un programa:
LIST: Presenta en pantalla el programa que esté en memoria RAM con las líneas ordenadas de menor a mayor. Se habla de listar el programa.
Otro punto bastante tedioso era repasar el código mediante el comando LIST. El código se visualizaba como si fuese un log y se podía parar y continuar pulsando Esc pero nunca retroceder. Como consecuencia, como no lo parases a tiempo era necesario volver a escribir LIST y volver a empezar desde el principio. Un truco era listarlo en mode 2 para que los caracteres fuesen más pequeños y se viese más código (En mode 0 era horrible).
IF … THEN ...
Otra mejora sustancial es la evolución el IF … THEN ....:
Comentarios: Muchas veces se debe realizar una acción si se cumple una condición, y no realizarse si esta no se cumple. Esto se realiza fácilmente mediante la sentencia IF-THEN. Si la expresión lógica es cierta, se realizan las instrucciones que siguen a THEN. Si es falsa, el programa continua su ejecución en la línea siguiente
Lo más fácil de entender lo perjudicial de esta instrucción es ver un ejemplo. Al estar todo escrito por líneas, si se desea poner cinco instrucciones al cumplir una condición la forma era: “IF condicion THEN instrucción1: instrucción2: instrucción3: instrucción4: instrucción5”. Todo en la misma línea. Desde el punto de vista práctico cuando eran muchas líneas se solía hacer “IF condicion THEN GOSUB linea_subrutina” y en esta subrutina se escribían todas las instrucciones. Esto provocaba un código algo disperso y dificil de entender. En la actualidad disponemos de final de IF que nos permite escribir un bloque de código con saltos de línea.
Subrutinas
Sin embargo, también hay parecidos que, aunque el nombre ha cambiado, la idea o la finalidad es la misma:
GOSUB ... RETURN: ir a subrutina … retornar. Una subrutina (también llamada rutina o subprograma) es una línea o conjunto de líneas que se utiliza para realizar una tarea determinada varias veces en un mismo programa, pero que solo se escribe una vez. La subrutina puede ser llamada cuando se quiera desde el programa para ser ejecutada. Finalmente su ejecución se devuelve el control a la instrucción o línea siguiente a la de llamada. La subrutina evita que se repitan líneas de instrucciones iguales en un programa, solo se escribirán una vez aunque se ejecutarán varias veces.
En la actualidad, las antiguas subrutinas han ido evolucionando con otros nombres procedimientos, funciones, métodos, etc algunos con ciertas particularidades. Sin embargo, el objetivo es el mismo: definir una vez y ejecutar cuantas veces quieras.
READ, DATA
Las instrucciones READ, DATA han desaparecido tal y como era, evolucionando a la posibilidad de crear y rellenar vectores con valores a la vez. Esto es lo que hacían:
Mediante la pareja de instrucciones READ...DATA pueden leerse datos no desde el exterior (como ocurre con la sentencia INPUT), sino permanentes incorporados en el mismo programa
La idea de DATA era centralizar los datos en una zona del programa siendo de la siguiente manera DATA “Lunes”, “Martes”, “Miercoles”, “Jueves”, “Viernes”, “Sabado”, “Domingo”. Esta instrucción podía estar en cualquier parte del programa y no era una instrucción ejecutable en si misma. Para leer los datos se realizaba con la instrucción READ que obtenían uno de los datos de manera secuencial.
La confusión de la existencia de una zona de DATA que podía leerse (sin que se ejecutase) y la no posibilidad de poder establecer diferentes zonas de datos, según su propósito, hizo de esta instrucción una tarea poco práctica para aplicaciones más grandes como hay en la actualidad.
No existencia de WHILE – UNTIL
Un último punto que me gustaría comentar sobre este manual es la no existencia de instrucciones WHILE o UNTIL. Estas instrucciones eran simuladas mediante IF y GOTO. Sin embargo, cuando se dio el paso a programación estructurada, se declaró la instrucción GOTO como poco legible o poco “elegante” para desarrollar.
Conclusión
Existe alguna curiosidad más que me gustaría comentar (como el SYMBOL), que me dejo en el tintero, pero este estaba incluido en manuales más avanzados. Repasando el resto del manual comentar que, en mi opinión, siento que tampoco se ha evolucionado tanto en la programación ya que muchas funciones siguen vigentes.
En la actualidad, disponemos de multitud de APIs, Frameworks y librerías etc. Pero lo que se ha hecho es mejorar y crear muchas más funcionalidades de cara al usuario. Siento que de cara al programador no se ha evolucionado como se debería haber evolucionado porque la esencia de la programación sigue siendo la misma (mismo perro con otro collar) y muchos problemas que teníamos antes los seguimos teniendo ahora. Solo destacaría la mejora de los IDEs en el que realmente afectan a la productividad, pero esto no corresponde al lenguaje en sí. Esta solo es una percepción personal y, por supuesto, debatible.
