[delphi.com.ar]

Yo voy a enumerar unas cuantas razones por las que no utilizaría VB (no me refiero a VB.NET ya que lo considero otro lenguaje totalmente diferente), e iré agregando ítems según recuerde:

• Producto final lento e inestable.
  Creo que no hay que ahondar mucho en el tema, cualquiera que haya trabajado en VB, sabe que lo que compila no siempre funciona igual que desde el IDE, sabe que su aplicación no responderá igual en todas las terminales, en grán culpa por la tecnología COM.
  .
• Falta de funciones y herramientas básicas.
  Para hacer una breve reseña, las funciones aritméticas son básicas, no existe forma nativa de hacer obtener el resto de una división de dos números decimales, no existe en forma nativa la forma de truncar un número sin redondeo, no existen funciones de desplazamiento de bit, no existen funciones serias para el tratamiento de fechas, archivos... (No vale correr la coma ehh!! )
  .
• Carece de un tratamiento de errores serio.
  Quien haya trabajado en VB sabe a lo que me refiero.
  .
• Los errores son capturados por el runtime y no pueden ser debugueados fuera de este.
  Si un error no es capturado el resultado final es la terminación abrupta de la aplicación.
  .
• El IDE es el encargado de interpretar el código y no es igual que el código compilado.
  Me a sucedido en mas de una ocasión, que el código ejecutado desde el IDE se comporta distinto que al ejecutarlo desde el EXE. Además, como el proceso del IDE es el encargado de interpretar el código, si desde nuestro código escrito producimos un error del sistema, perderemos todo los cambios porque el sistema operativo cierra un único proceso.
  .
• Compilador pobre.
  Recuerdo haber asistido a las presentaciones de VB4 y VB5, en la primera, si no me equivoco el orador era Willy Reinoso, habló durante un buen tiempo sobre la ventaja del PCode, tiempo después, con la aparición de VB5 tiró por la borda todo lo que nos había “¿mentido?” sobre la versión anterior.
  El producto final es lento, y poco optimizado. El compilador no da ninguna advertencia sobre el código escrito. Y por otro lado solo permite crear ejecutables runtime-dependientes y objetos COM.
  .
• Falta de compatibilidad entre versiones.
  El código de VB entre las versiones 3-4 4-5 6-.NET (si la admitimos como VB), es incompatible. Culpa de la falta de diseño y la pobre filosofía original del lenguaje. Años atrás trabajaba en una empresa que había pagado U$S 1.000.000 por un sistema muy grande, desarrollado en VB3, cuando aún era una tecnología válida, y a la hora de migrarlo a una plataforma de 32bits, ya que Win9x solo reserva un espacio fijo de la memoria para aplicaciones de 12bits y esta la desbordaba continuamente, se vieron en el inconveniente que la migración era la reprogramación del sistema.
  En innumerables ocasiones escuché que se decidía por VB porque se tenía soporte, pero cuando aparece una nueva versión, M$ deja de soportar las versiones anteriores, y al ser radicalmente distintos, el soporte no sirve de nada.
  .
• Imposibilidad de utilizar ciertos objetos creados en runtime
  Esto evidencia que VB trata a sus diseñadores distinto que al código que escribamos. Hay ciertos componentes que es imposible crearlos en runtime con la opción WithEvents que es al que nos permite capturar el evento del objeto. Por ejemplo cualquier objeto que se haya cargado la librería que lo contiene dinámicamente, o simplemente algún objeto tipo el MSCOMM32
  .
• Carencia de Hilos de ejecución y mal tratamiento de objetos externos multihilo
  Simplemente no tiene una forma nativa de tratar hilos, y aparentemente el runtime no soporta que creemos hilos utilizando las funciones del SO. Digo aparentemente porque me baso en las pruebas que he hecho.. (Subo el código si alguien lo quiere)
  Por otro lado, tuve muy malas experiencias utilizando controles ActiveX que utilice mas de un hilo.
  .
• continuará...
  .