¡Chin! El peso de la compatibilidad...

En gwBASIC, BASICA y otros lenguajes afines (como QuickBASIC y TurboBASIC), la única forma que se tenía para declarar el tipo de dato de una variable era a través de este tipo de símbolos. De facto, una variable escrita por sí sola era del tipo Single (punto flotante de precisión sencilla). Si querías utilizar una variable de otro tipo, tenías que adjuntar un símbolo de estos para establecerlo. Ello se ciñe a los siguientes:

 Como ves, era una forma muy bizarra de programar (aunque te acostumbrabas).

Imagínate ver un programa escrito de la siguiente forma:

10 ' Programa CalculaDias
20 INPUT "Teclea tu día de nacimiento: ", DIA%
30 INPUT "Teclea tu número de mes de nacimiento: ", MES%
40 INPUT "Ahora, tu año de nacimiento: ", ANIO%
50 DIASUSU! = (CSNG(ANIO%) * 365) + (MES% * 30) + DIA%
60 DIASIS% = CINT(VAL(MID$(DATE$, 4, 2)))
70 MESSIS% = CINT(VAL(LEFT$(DATE$, 2)))
80 ANIOSIS% = CINT(VAL(RIGHT$(DATE$, 4)))
90 DIASSIS! = (CSNG(ANIOSIS%) * 365) + (MESSIS% * 30) + DIASIS%
100 DIASVIV! = DIASSIS! - DIASUSU!
110 PRINT "Has vivido aproximadamente"; DIASVIV!; "días."
120 END

Ahora bien, para facilitar la declaración de tipos surgieron instrucciones como DEFxxx que establecían el tipo predeterminado de una variable (como ya había dicho, el predeterminado era el SINGLE) utilizada sin ningún tipo de símbolo adjunto. Por ejemplo, en esos tiempos escribir una asignación a una variable así:

variable! = 1.5

era lo mismo que escribirla así:

variable = 1.5

La variable contendría el valor de 1.5. Sin embargo, si modificabas el tipo de dato predeterminado con una instrucción DEFxxx, ya no sería lo mismo lo uno que lo otro. Por ejemplo:

DEFINT A-Z
variable! = 1.5
variable = 1.5

Aunque te parezca increíble, ambas son variables diferentes. DEFINT A-Z indica que todas las variables declaradas sin ningún sufijo serán de tipo entero. El sufijo, así, declararía el tipo exacto de variable. Así, la asignación a variable! dejaría internamente un valor de 1.5, pero la asignación a variable dejaría internamente un valor de 2 (se redondea). Ésto podía traer (y trajo) serios problemas a la hora de intentar depurar programas, pero así funcionaba BASIC y poco a poco se ha ido depurando.

PDS7.1 ya incorporaría OPTION EXPLICIT para obligar a la declaración de variables, lo mismo que VB-DOS. Tal facultad se agregó en Visual Basic a partir de la versión 2, para obligarte a tí mismo (y por salud mental) a declarar las variables explícitamente y no recurrir a medios tan abyectos como DEFINT A-Z.

NOTA: DEFINT, DEFLNG, DEFSNG, DEFDBL, DEFCUR y DEFSTR podían definir el tipo de dato de las variables de acuerdo con la letra con la que empezaba su nombre. Por decir, DEFINT A establecía que todas las variables cuyo nombre empezara con A (AGUA, ACUMULADO, ACABADO) tendrían un tipo Integer predeterminado, el resto permanecería con un tipo de dato predeterminado de Single. DEFSTR N,D definía que las variables cuyos nombres empezaran con N o D (como NOMBRE y DOMICILIO) tendrían un tipo predeterminado de String.

Podías, de hecho, determinar diferentes tipos predeterminados para cada nombre de variable. Sin embargo, si no tenías un claro control del código, esto podía traer serias confusiones en el código.

Visual Basic, aunque no lo parezca, aún carga un enorme peso de compatibilidad. Aún puedes utilizar instrucciones como ON ... GOTO, ON ... GOSUB, GOSUB, DEFINT y los caracteres de tipos %, &, !, #, @ y $. Esto puede traer problemas a la hora de hacer programas, dado que empiezan a ocurrir errores inexplicables, como en el siguiente ejemplo:

unVariant = unDato&otroDato

En ocasiones, la anterior instrucción puede producir un error, dado que VB no podrá determinar si unDato es una variable de tipo Long, o si intentas hacer una concatenación. Por ello, en este tipo de símbolos es importante el uso de los espacios.

unVariant = unDato & otroDato

Así, no habrá problemas.

Este tipo de cargas provocadas por la compatibilidad (entre lo que se incluye a los números de línea, las instrucciones duplicadas como WHILE-WEND y DO WHILE-LOOP, entre otras cosas) son lo que ha sobrecargado al Visual Basic tal como lo conocemos. Tales sobrecargas no hacen sino entorpecer el funcionamiento de nuestros programas, y por ello comprendo el cambio radical de VB.NET: Ya no necesitamos tales sobrecargas. Si se intentara agregar funcionalidad sin quitar las sobrecargas, seguiríamos con los mismos problemas a los que nos hemos enfrentado hasta hoy. Cabe tomar en cuenta que prácticamente nadie ya utiliza BASICA o gwBASIC como para justificar semejante compatibilidad. Por añadidura, en QuickBASIC 4.x ya existe la declaración de tipos como tal. En cada procedimiento se puede utilizar DIM variable AS tipo sin mayor problema, por lo que se podría propender a quitar los sufijos de tipos entre muchas otras cosas (en caso de querer programar para Windows y para MS-DOS o la consola).

Por ello no me extraña que VB haya sido rediseñado para ajustarse a nuestros tiempos. Aún es VB, pero sin sobrecargas y sin cuestiones que salían de la lógica (por ejemplo, para abrir un archivo de texto teníamos que escribir OPEN "archivo" FOR INPUT AS #1, y para abrir una base de datos cnn.OPEN "CadenaConexion"; unas partes de VB están basadas en objetos y otras no; salen objetos mágicamente sin que sepamos de dónde provienen, como MsgBox, Print y cosas así). VB.NET propende a que pensemos de forma más estructurada y limpia, lo cual mejorará nuestro nivel como programadores.

Ya pronto empezaremos a hablar más de VB.NET y cómo aprovechar mejor a VB6 como tal. Acaso, tal vez hubiera servido agregar una instrucción OPTION COMPATIBILITY OFF para reducir la sobrecarga en VB6.