Despreciado por la academia, Visual Basic es  el lenguaje más usado para el desarrollo de aplicaciones pequeñas y RAD. Hace años una historia de cubierta del  Byte  decía que la programación orientada a objetos no había cumplido las expectativas de masificar la reusabilidad del código, en cambio esto se había logrado con el "componentware"

En otra historia atípica la revista "Computing" de junio del 2000 trae un artículo sobre lo mismo, han pasado siete o mas años entre ambas publicacioness y la situación sigue igual que antes. La mayor promesa de la OOP, la reutilización del código,  no se ha cumplido, los códigos de C++ y Java  muestran poco o ningun nivel de reutilización ¿cuantas bibliotecas comerciales para propósito especifico hay en esos lenguajes? ¿se comparan con la cantidad de componentes reusables?, la verdad es que ni se acercan.

"Tres grandes revoluciones han ocurrido en la historia de la tecnología de computadores durante los últimos 50 años: el computador con programas almacenados, los lenguajes de alto nivel y la programación a nivel de componentes" escribe el doctor Peter M. Maurer en el último número de "Computer" , "cuando hablamos de programación a nivel de componentes, estamos hablando del futuro. La revolución ya ocurrió, y en la comunidad académica nadie se ha hecho cargo todavía"

La programación con componentes fue desarrollada casi desde cero por Visual Basic, es su principal característica y ha convertido a la reutilización del código en una realidad, ahora mismo existen miles de componentes con las más diversas rutinas, en su mayoría de bajo costo o  freeware. La rapidez y facilidad de uso de los componentes hacen de Visual Basic un estándar de facto para el desarrollo RAD (Rapid Aplication Development) así como para la construcción de prototipos para aplicaciones mayores 

Para quien no conozca la programación a nivel de componentes es una experiencia asombrosa la cantidad y calidad de los componentes hoy disponibles, cubren casi todos los campos que podamos imaginar; bases de datos, adquisición de datos, modelamiento en 3D, hojas de cálculo y procesadores de texto completos (incluyendo corretor ortográfico) en fin, la disponibilidad es inmensa.

Los componentes cambian radicalmente la manera en que programamos nuestras aplicaciones, en lugar de escribir rutinas para sesolver cada una de las funcionalidades del sistema se trabaja a un nivel más alto, la tarea se divide en distintos componentes, algunos los programamos nosotros mismos localmente y otros los conseguimos o los compramos de terceros proveedores. Como los componentes están encapsulados las posibilidades de falla se reducen considerablemente.

A mi, como electrónico el desarrollo de componentes me parece muy similar a la transición de los circuitos discretos con transistores a los circuitos integrados. La idea es similar, no reinventar la rueda en cada aplicación, disponer de componentes baratos (y aún gratis) en gran variedad y poder concentrarse en el desarrollo macro sin las distracciones propias del detalle.

ELa tecnología de los componentes también está hoy disponible para Visual C++, Java y Delphi y el secreto de su éxito es la facilidad de uso. Una vez "fabricado" un componente como el Winsock.OCX por ejemplo, bastará dar valor a sus propiedades para usar los métodos disponibles en respuesta a eventos u órdenes de código.

Bueno, dira cualquiera que provenga de la OOP, eso mismo lo pueden hacer las bibliotecas. Y tiene razón, incluso las bibliotecas son generalmente más eficientes que los componentes para una misma tarea ¿por que la gran popularidad de los componentes entonces?. Por su facilidad de uso, requieren menos instrucciones de código, son visuales e intuitivos. Hay que recordar que la eficiencia por si sola no es lo único que cuenta al desarrollar aplicaciones, de otro modo todavía estaríamos programando en lenguaje de máquina.

Desde las primeras versiones Visual Basic introdujo algunos conceptos muy novedosos. Hasta ese momento todas las componentes visuales de un programa de Windows se debían hacer por medio de mensajes a la API (Aplication Program Interface), obviamente estos mensajes solo se podían enviar en C, C++ o Assembler lo que hacía la programación de una simple ventana algo bastante complicado. Visual Basic creó una capa superior donde lo que se  programaba eran las especificaciones de las ventanas (cajas de dialogo, o formularios para usar el lingo VB), ademá esto se hacía "visualmente" dibujandolas en lugar de escribir coordenadas, tamaños, etc. en código.

Si vemos los archivos que genera un proyecto en VB (formularios y módulos), a partir de la versión 4.0  nos sorprenderá comprobar que bien podríamos haber escrito la aplicación usando el Notepad, ya que los archivos .frm son simplemente especificaciones en texto ASCII de manera muy parecida a lo que son los archivos .ini

Las primeras versiones de Visual Basic venían con un conjunto estándar componentes: Botón de comando, Textbox, ListBox, Combobox, SrollBar, Imagebox. Con estos "controles" (o componentes) es posible programar casi cualquier aplicación normal, pero al diseñar Visual Basic se pensó en la conveniencia de poder agregar componentes programados por los usuarios o terceros, lo que dió cabida a los componentes .vbx. En poco tiempo la cantidad de .vbx disponibles aumentó exponencialmente, siendo por si misma un área importante de desarrollo. A partir de la versión 3.0 apareció el DataControl, un componente que permitía conexión con variedad de bases de datos lo que dió un gran empuje a visual Basic como lenguaje para desarrollo rápido de aplicaciones comerciales.

La versión 4.0 trajo un gran terremoto que descontinuó las vbx, creando un nuevo tipo de componente basado en la tecnología OLE, los ocx, la explicación oficial de Microsoft fue que las vbx estaban demasiado ligadas a la tecnología de 16 bits del Windows 3.x, en tanto las ocx eran completamente de tecnología 32 bits. La verdad es que al usar los métodos OLE las ocx tuvieron la ventaja de ofrecer un método de desarrollo mucho más formal y estandarizado que permitió su uso en otros lenguajes como Delphi por ejemplo. Los problemas de incompatibilidad con vbx y por ello con Windows 3.x que no fueron menores, con el correr del tiempo fueron desapareciendo.

La versión 5.0 de Visual Basic trajo una característica notablemente poderosa: los componentes ocx se podían programar en el mismo Visual Basic, ya no era necesario recurrir al C++ con lo que la creación de nuevos componentes se convirtió en algo rápido y relativamente sencillo.

Para la versión 6.0 la tecnología OLE había evolucionado a otra más simple, más estandarizada, más eficiente y sobre todo menos "inestable" (creo que Microsoft inventó el eufemismo de la "inestabilidad" para referirse a sus propios errores de programación), con ello lcambió también los métodos de conectividad con bases de datos desde ADO (tecnología OLE) a DAO (tecnología ActiveX). Estos cambios afectan más a los futuros desarrollos que a características actuales, tal como pasó con la transición de los 16 a 32 bits en su época.

Sabemos que en Microsoft nunca han sido tímidos para alabarse a si mismos y que acostumbran a anunciar características de los nuevos productos mucho antes de saber si realmente van a funcionar. El hecho es que para la versión 7.0  se implementa por fin la herencia como funcionalidad del lenguaje, con lo que Visual Basic quedaría con todos los requisitos para calificar como lenguaje 100% orientado a objetos.

Así, Visual Basic quedaría como el primer lenguaje de computación que a la vez es orientado a objetos y orientado a hackers, ya que además de cumplir con las funcionalidades exigidas por la OOP no tendría las restricciones de programación que todos los demás lenguajes orientados a objetos poseen, aún sera posible usar las "malas prácticas" de programación tales como no declarar las variables, usar goto, y todas esas cosas que enfurecen a los profesores. Visual Basic ganará en funcionalidad pero no perderá la escencia de su apellido, el Basic, lo que para los desarrolladores de sistemas pequeños, es muy conveniente

¿Ha tocado techo el desarrollo de la programación a nivel de componentes?. es difícil saberlo, la nueva generación de componentes desarrollada por Microsoft se basa en la tecnología COM que, además de estar sólidamente fundada en la OOP como las anteriores, es aún más estándar, más formal y más portable. Las especificaciones COM ya no sirven solo a nivel PC-Windows, sino que pueden desarrollarse en cualquier otro entorno, desde Unix a sistemas operativos propietarios ya se están desarrollando objetos COM incluso usando lenguajes como el antiquísimo COBOL. Más aún, el conjunto de especificaciones DCOM (COM distribuído) permite la creación de objetos distribuidos que pueden llamar y utilizar desde distintos equipos conectados a Internet.

Pero los objetos COM, a diferencia de los componentes usuales de Visual Basic han sido diseñados no como interfases a usuarios sino que para proveer servicios ocultos en tiempo de ejecución, de manera similar a los componentes no visibles, como winsock.ocx, listitem.ocx, etc. que solo pueden controlarse en tiempo de diseño. Tal vez esto les quite la "magia" que hizo tan populares a los componentes como los Textbox, Combobox  y todos esos que hasta hoy me siguen asombrando por lo genial de la idea

Claro que no pues, con todas sus ventajas para el desarrollo rápido y fácil de aplicaciones pequeñas, Visual Basic tiene sus puntos negros.

Uno de los principales dolores de cabeza para el programador el la distribución de las aplicaciones, cuando todo funciona de maravillas en el equipo del programador pero al instalar comienzan a aparecer los mensajes "no puede crear el objeto". Y esto no es solo un problema de registrar las ocx, todavía quedan Micro-bugs en el nebuloso proceso de instalar las aplicaciones, especialmente cundo se usa el famoso "asistente"

Después tenemos que el Visual Basic con su gran permisividad, objetivamente fomenta la creación de código redundante o inconsistente. La verdad es que en todo lenguaje se puede crear código inconsistente pero en Visual Basic es mucho más fácil que, digamos en C++ o Java. Una solución bastante útil para esto es el uso de analizadores de código, esto que es ampliamente conocido en C++ se está comenzando a aplicar a proyectos de Visual Basic con excelentes resultados y productos como el Project Analyser detectan problemas de optimización, inconsistencia, estilo y analizan la métrica de los sistemas, generando además una completa documentación del sistema. Una muestra de este análisis se encuentra en la sección Proyectos Personales de este mismo sitio

Para los que aprendimos computación a principios de los ochenta, cuando en la universidad se consideraba que el Assembler era el unico lenguaje "de hombres" y que el que no era capaz de diseñar un compilador no merecía llamarse programador, no es nada nuevo que esto de los lenguajes de programación son un asunto de compromiso.

En la vida real se trabaja en base a resultados, en un ambientye lleno de restricciones y plazos fatales y nos damos cuenta bien pronto que la cosa es bien distinta a lo que nos enseñó el profe que venía de su beca de Inglaterra lleno de teorías en un mundo ideal. Peor todavía es que los profesores que nos enseñaron jamás trabajaron desarrollando sistemas en la "vida real" lo que explica la seguridad de sus ideas y lo rotundo de sus afirmaciones.

Creo que todo programador que trabaja en la práctica, y que tiene la opción de elegir las herramientas que mejor le acomoden (cosa muy rara en las grandes organizaciones) hace un compromiso, una especie de pacto on el diablo entre optimización y facilidad de uso. Algunos optan por la facilidad de uso en su nivel más alto, dedicándose de lleno al restringido mundo de las bases de datos y lenguajes de muy alto nivel que lo sitúan a cientos de metros de altura sobre el código de máquina subyacente. Otros prefieren trabajar muy cerca de este código y usan C++ incluso para las aplicaciones más comunes y simples.

Creo que la verdad está en el justo medio. Para el desarrollo de aplicaciones pequeñas Visual Basic o Delphi (según la preferencia del programador por Basic o Pascal) son de un nivel intermedio que permite concentrarse en los problemas macro sin perder el control de lo que ocurre en las capas inferiores. Visual Basic es, a mi modo de ver, el que más se ha desarrollado por ser pionero en muchas áreas y tener el respaldo de Microsoft, la misma empresa que creo el Sistema Operativo estándar para PC.

Por último es solo cuestión de gustos, nada más ocioso que las discusiones sobre la "potencia" de un lenguaje, cuando todos se usan en aplicaciones bastante similares y finalmente solo transforman de manera cómoda nuestras ideas al mismo conjunto de  instrucciones de código de máquina