Últimamente estoy programando en BASIC para cierta plataforma que no puedo olvidar.

¿Por qué BASIC? Sinclair Basic es bastante más lento que Microsoft Basic (desarrollado para múltiples microordenadores), y especialmente que Locomotive Basic, desarrollado para el Amstrad CPC. Además, utiliza números de línea con GOSUB/RETURN, algo por lo que no estoy dispuesto a (volver a) pasar.

Sí, hay gente que programa en Sinclair BASIC y después va y lo compila, con herramientas de la época como el Colt Compiler de Hi-Soft.

Otra elección natural sería Z88DK, que permite programar en C para múltiples retro-multi-plataformas.

El caso es que... ZXBasic, mi elección de compilador esta vez, permite programar en algo parecido a Microsoft Visual Basic, bueno, más bien a FreeBasic, y generar archivos .tap(preparados para cargar desde cassette virtual) para ejecutar en un emulador de ZX Spectrum. El caso es que, al contrario que con Z88DK (que está muy bien para programas multi-retro-plataforma), ZXBasic permite utilizar las características propias del Spectrum, como los ¡8 colores!, el brillo, los comandos gráficos como CIRCLE() o LINE(), o los UDG's (Gráficos definidos por el usuario, o User-Defined Graphics).

El caso es, que al fin y al cabo, Basic ha inspirado Python. Y lo estoy notando, porque... ¡tengo que escribir menos para programar en BASIC! En BASIC moderno, claro.

if ( x > 2 ) {
    printf( "¡Programar en C mola!" );
}

if x > 2
    print( "¡Programar en BASIC también es molón!" )
end if

Si analizamos el código, nos encontramos con que 1) No es necesario poner un punto y coma (';'), al final de cada instrucción; 2) No hay que abrir un bloque de código con '{', sino que la propia línea if x > ... es el propio comienzo del código. En Python es similar, excepto que hay que añadir dos puntos (':'); 3) El final de un bloque de código se indica con end if, de forma similar a otros lenguajes de programación como Pascal. Esta forma de indicar los bloques de código automáticamente elimina ambigûedades (lo suele derivar en polémicas), como por ejemplo dónde colocar la llave de apertura en C.

Como nota al pie, desgraciadamente Python no soporta un end de ningún tipo para marcar el final de un bloque de código, para mi disgusto personal, confiando solo en la indentación.

No todo son ventajas, claro. Por ejemplo, una condición compuesta para if...

if x > 2 _
and x < 10
    print("2 < X < 10:", x)
end if

Diferentes dialectos de BASIC soportan diferentes caracteres para indicar el final de la línea de código. En este caso, se utiliza el subrayado, como '_'. Quizás esto no es muy estético, pero desde luego compensa el tener que colocar un ';' al final de todas las sentencias. Python toma claramente la delantera al definir expresiones multilínea. Si una expresión de cualquier tipo se encuentra entre paréntesis, entonces puede traspasar el límite de la línea de código tantas veces como lo necesite.

for(int i = 0; i < 10; ++i) {
    printf( i, " x 5 = ", i * 5 );
}

for i = 0 to 9
    print( i, " x 5 = ", i * 5 )
next

Sí, el bucle for() de C es potentísimo. Pero, ¿merece la pena tener que escribir siempre tanto? Debería tener una versión mínima más parecida a for... next de BASIC. Aquí Guido Van Rossum (creador de Python), lo tuvo claro.

for i in range(0, 10):
    print(i, "x 5 =", i * 5)

Y aunque existe una palabra clave para indicar comentarios (REM), la abreviatura más común (el apóstrofe) es soportada prácticamente en todos los dialectos.

' Tabla de multiplicar del 5
for i = 0 to 9
    print( i, " x 5 = ", i * 5 )
next

Además, hay que tener en cuenta que este BASIC es mucho más moderno, estructurado, y por tanto soporta procedimientos (subrutinas) y funciones.

function isdigit(byval s as string) as bool
    dim sc as ubyte = code( s( 0 ) )
    return sc >= code( "0" ) and sc <= code( "9" )
end function

sub print_code_array(byval s() as ubyte)
    for i = lbound( s ) to ubound( s )
        print( chr( s( i ) )
    next
end sub

No todo son ventajas. Aunque FreeBASIC soporta estructuras e incluso objetos, ZXBasic no soporta ninguno de las dos. Lo de soportar POO me parece excesivo, pero en cambio soportar estructuras me parece básico. Así, hay que adaptar un tanto la forma de pensar, pues no se pueden empaquetar variables que actúen con un objetivo común.

Es refrescante desempolvar los conocimientos de programación arcanos, pero también aprender a complementarlos con las extensiones de subrutinas y funciones.