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.
Comentarios
La programación si que ha evolucionado, tan sólo hay que mirar a la cantidad de lenguajes (y tipos de lenguajes) que se han creado desde entonces ...
A parte de la evolución en los compiladores e intérpretes.
-- editado por última vez a las 17:33
Interesante, también programé en basic cuando niño y fue muy divertido. Pero no creo que ese lenguaje se pueda usar como medida de la evolución de la programación. C es de 1972 y en ese entonces ya tenia muchas de las cosas que le faltaban a Basic.
"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."
La verdad es que esto no entiendo qué quiere decir.
Y, comparado con C o BASIC, la programación actual ha cambiado muchísimo
Yo recuerdo con añoranza aquellos tiempos,aquell basic que todos empezábamos a enumerar de 1 en 1 y que cuando nos equivocábamos teníamos que reescribir toda "el programa", de todas maneras con 8 bits se conseguían cosas increibles....,ahora hay muchos más recursos, pero seguro que menos imaginación, te leo sobre sentenciasy me acuerdo de escribirlas una y mil veces en mi zxspectrum.
Pdría estar hablando horas del basic y aquella máquina demoniaca,pero lo que mas recuerdo son: los programas distribuidos en cintas de cassette, escribir el código en ram, que al apagar la máquina se perdía todo el trabajo y aquella montaña de ilusión quen os embargaba....
Yo tuve uno de esos, un Amstrad CPC 464, con monitor verde, hice mis primeros programillas aprendiendo con ese manual. Despues lo vendimos para comprar un PC. Creo que habia una instrucción llamada "RENUM" que te renumeraba las lineas otra vez de 10 en 10 (si habias puesto alguna de por medio), pero no estoy seguro.
Tienes razón. Desconocía la existencia de RENUM. Ya lo he dejado indicado en el post. Gracias y saludos, Jorge
eso dependía del tipo de basic que utilizaras, el zxspectrum aparte tenía su basic aparte ;)) corrían bajo el sistema operativo 3dos algo increíble
Jo, que buenos recuerdos, yo soy del 86 pero tenia un Amstrad CPC 464 (que empezaría a usar en el 94 más o menos).
Recuerdo aprender un poco de basic y era muy divertido.
10 ? "Hola, Mundo"
20 goto 10
Era mi programa favorito :P
Recuerdo usar "auto" para que pusiera los numeros de linea automaticamente (de 10 en 10, o auto 100 para 100 en 100).
Recuerdo que decia... qué raro, pongo coche (auto) y salen las lineas...
-- editado por última vez a las 01:44
Para los más nostálgicos, en OpenLibra hay secciones con manuales en descarga directa de BASIC y derivados como, por ejemplo, aquellos que refieren a las ya viejas máquinas de 8 bits.
Quizá, el más interesante desde un punto de vista histórico, sea el primer manual de BASIC, que data de 1964:
OpenLibra | A Manual for BASIC
Son también casi imprescindibles los libros relacionados con el mítico Spectrum, su código máquina y técnicas de programación: OpenLibra | Spectrum
Y sobre microinformática (Amstrad, MSX, Amiga...) OpenLibra | Historia de la Microinformática
La verdad es que todos ellos son muy interesantes y ejemplifican una época que cualquier informático debería conocer.
Saludos!
Yo tengo en casa un libro de ensamblador para el ZX Spectrum y el modelo anterior, creo que se llamaba ZX80A, de solo 16KB. No es ninguno de los de la web y debe ser del 1982, si no recuerdo mal.
Tambien tube un ensamblador/desensamblador en un cassete pirata que compre en el 'mercat de sant antoni' para el spectrum, y que use para crackear un juego con 'turbo-load', el commando. Entre otras cosas.
Igual alguien sabe de que estoy hablando con lo del turbo-load de los juegos: piiiiirrrp-piiiirrrpiipipipi...
-- editado por última vez a las 15:38
Estoy impresionado con tu web! Enhorabuena! Voy a descargarme unos cuantos!
Yo en aquella época y conociendo algunos peeks y pokes, dejé un input "loading moby dick" en un spectrum del mostrador del corte inglés, y me quité rápidamente de allí.
Al rato había un montón de curiosos, alrededor del spectrum.
Tengo ese manual en mis manos las tres instrucciones mas potentes del Basic de la empresa Locomotive para el Amstrad que comentas eran :
AFTER, EVERY y REMAIN
con ellas podias hacer 'MULTITAREA' cosa que no he visto en ningun BASIC de empresas como Microsoft (GwBasic) o Borland (TurboBasic). Para que os deis cuenta de la calidad de este Basic. El Basic de Amstrad trabajaba con un procesador Z80 de 8bits frenta a los de Microsoft y Borland con un procesador de 16 bits.
-- editado por última vez a las 16:22
"El Basic de Amstrad trabajaba con un procesador Z80 de 8bits frenta a los de Microsoft y Borland con un procesador de 16 bits."
hombre, el primer intérprete de BASIC de Microsoft fue para el PDP-10 y trabajaba sobre un 8080 de 8 bit ocupando 4kb. Entre otras adpataciones , tuvo una a Z80.
Estoy comparando el Basic de Locomotive que tenia instrucciones multitarea en un Z80 de 8 bits frente al GWbasic de Microsoft y Turbo Basic de Borland que no tenia esas instrucciones aun trabajando en un procesador de 16 bits de Intel.
Hombre, el gw basic tenía interrupciones para capturar eventos del puerto com, de teclado entre otras además de creación de timers.
Tambien tengo el manual del GW-Basic de Microsoft version 4 para 16bits. ¿Cuando dices interrupciones para capturar eventos del puerto com te refieres a "instrucciones" ? Lo unico que veo son las instruciones call, poke y peek que tenian todos los basics. ¿ Que instrucciones de creacion de timers o acceso a puerto com te refieres ? No he visto ningun basic con estas instrucciones tan potentes como tenian los Amstrad y sin necesidad de meter codigo maquina.
http://www.antonis.de/qbebooks/gwbasman/
ON COM(n), ON KEY(n), ON PEN, ON PLAY(n), ON STRIG(n), and ON TIMER(n) Statements
Yo empecé con el Spectrum 16k de un amigo, me pasé al 128k +2A y en clases de informática trasteaba con CPC64 como el de la foto. Con 11 años estaba hasta las trancas de picar BASIC.
Quince años después me encontré trabajando en un proyecto de energía solar, con concentradores fotovoltaicos. El software de simulación, Light Tools, permitía automatizar órdenes tanto de diseño como de simulación propiamente dicha. La documentación era de dificil acceso pero, gran momentazo, me di cuenta en los ejemplos de que tanto PRINT, PRINT USING y variables con '$' cuando eran alfanuméricas sólo podían significar una cosa: en pleno siglo XXI, mis recuerdos de programación en BASIC me iban a servir para utilizar un software de cálculo de última generación.
El dios de Python-jQuery-DART-... se revolvía en su tumba.
Si, que tiempos! Soy del 68 y comencé con un Spectrum 48K en el 83. Cinta de casette e impresora térmica. Si no recuerdo mal, el Z80A de esa máquina fue el antecesor de la familia 8086. Lo que recuerdo es que para escribir en colores tenías que usar teclas de escape y fijar esos colores directamente en el código. Era curioso ver el código conm las constantes de texto en colorines o parpadeando. Cuando me cansé del Basic estuve indagando con el assembler y más tarde con un lenguaje llamado Forth que usaba un acceso directo a la pila de datos del tipo LIFO. Eran los tiempos del Commodore y estaban a punto de salir los MSX.
Después ya me pasé al XT de IBM. Los primeros Personal Computer en españa que llegaban a costar la friolera de 700.000 pesetas (42.000 euracos). 4.7 Megaherzios y un disco duro de 10 Mb. Si, que tiempos!...
"el Z80A de esa máquina fue el antecesor de la familia 8086"
No, no tienen nada que ver, el antecersor del 8086 es el 8080 de Intel, el Z80 era de Zilog y con una arquitectura totalmente diferente
700.000 pesetas son 4.200 euros, no 42.000
-- editado por última vez a las 16:59
Si que tiene algo que ver ya que el Z80 estaba diseñado para ser compatible a nivel de codigo con el 8080 de intel tambien de 8bits.
Efectivamente. De hecho la misma Zilog -la casa que sacó el Z80- fue creada por ex-ingenieros de Intel y el Z80 efectivamente fue diseñado para ser compatible con el Intel 8080 aunque el Z80 tenía muchísimas mejoras sobre él.
Es curioso que con el 6502 de MOS -el otro gran procesador de 8 bits- también sucedió algo parecido: MOS fue formada por ex-ingenieros de Motorola.
También es muy curioso que tanto el Z80 como el 6502 (en sus diferentes variantes) dominaron el panorama de los 8 bits -la inmensa mayoría de ordenadores usaba uno de estos microprocesadores- pero ambas pasaron casi al olvido con los 16 bits mientras que las casas de donde salieron los ingenieros que formaron MOS y Zilog -Intel y Motorola- sí fueron muy exitosas en los 16 y 32 bits.
La historia suele ser muy sorprendente.
-- editado por última vez a las 01:56
Vaya yo tenia ese mismo Amstrad :( Y aprendí a programar con él a los 13 años
El artículo bien hasta llegar a la parte de las conclusiones. Sinceramente, no las encuentro afortunadas. Hay que tener en cuenta que el BASIC del 84 en las máquinas personales es poco más que un juguete, con las limitaciones que imponían los compiladores e interpretes que se podían hacer funcionar en las máquinas de la época con sus limitaciones de potencia y memoria.
En el año 1984 ha se habían alcanzado hitos importantes de la programación que eran ajenos al microuniverso de estos interpretes de BASIC. C y Unix ya habían aparecido, C++ estaba al caer años después, pero la programación orientada a objetos ya era una realidad con Smalltalk y otros. Lisp llevaba en el mundo desde los 50, habiendo sido ideado para cálculo lambda y definiendo el paradigma funcional.
Por estas y muchas otras cosas, BASIC no es en absoluto representativo para valorar el estado de la programación en 1984 y compararlo con el estado actual. Si por "es todo básicamente lo mismo" entendemos que la programación estructurada ya estaba más que inventada, pues sí. El avance en otros campos, como lenguajes multiparadigma (que ya los había), refinamiento de los ya existentes, avances en las posibilidades de los compiladores y de los intérpretes, popularización de máquinas virtuales para ejecutar "byte-code", como el caso de Java, etc, creo que son hechos innegables a poco que se profundice en el campo de la programación con pretensiones "serias". Avances en hardware y el creciente paralelismo es otro de los factores que han hecho cambiar el enfoque a la hora de resolver ciertos programas.
En resumen, no estoy muy en desacuerdo con la conclusión, o al menos no he logrado entender el mensaje que intentaba transmitir, pues a mí me inspira ideas equivocadas.
Saludos
En Amstrad CPC (en el BASIC 1.1 por lo menos, disponible en los Amstrad CPC6128 y en los 472, disponíamos de "WHILE-WEND". Por lo tanto, sí teníamos algo semejante al While-Until o DO-LOOP.
El BASIC de Locomotive disponible en los Amstrad CPC era de los más potentes de la época, teniendo incluso instrucciones para controlar las interrupciones y programar timers y semáforos que ejecutaban subrutinas.
También tenías instrucciones para definir FUNCIONES.
Saludos.
-- editado por última vez a las 15:07
Escribir un comentario
Para hacer un comentario es necesario que te identifiques: ENTRA o conéctate con FacebookConnect