Aclaración: No hablo de VB.NET, solo de VB que es lo que conozco.
Lo primero que te diran es que Delphi falla muy rápido, estan acostumbrados al:
Código:
On Error Resume Next ' y a tomar por saco...
Y no estoy enojado, el programador cuando escribe la instrucción, siempre dice en voz alta el comentario, lo digo por experiencia
.
y claro, al ver un Access Violation, le echan la culpa al lenguaje, ¡¡ su código está bien !! el lenguaje es muy pobre
Me gustaría saber como lanzar una excepción en una rutina pequeñita y poder capturar el error 5 rutinas más arriba en VB
. ¡¡ Hombre !! y ¿para qué se quiere capturar un fallo? lo mejor es obviarlo (sin duda, es la forma de pensar en VB).
La mayoría de los comentarios que hagan sobre delphi, están basdos en:
- pobre o nulos conocimientos de programación (POO)
- Conceptos equivocados basado en lo anterior.
- Desconocimiento de 'la verdad'
Me encantaba trabajar con VB porque se tenía acceso a la API de Windows, necesitaba de un programa que mostraba ejemplos de la api de windows, copiaba la declaración de las funciones al portapapeles de windows y lo pegaba en mi módulo de VB adaptándolo a mis necesidades.... hasta que instalé delphi y vi la API integrada en el lenguaje ¡¡ y con ayuda!!.
En cuanto a la curva de aprendizaje, para mí al menos, es más grande en Delphi que en VB. En VB no tienes que aclarar conceptos ni aprender nada, simplemente se usa. En Delphi si no tienes los conceptos claros obtienes un Abstract Error (
que nadie sabe que es). Cuando lo sufrí en mis propias carnes estuve varios días en el limbo; menos mal que los amigos de ClubDelphi me ayudaron a regresar (no encuentro el tema para poner el link, sorry)
En VB se solucionaban los problemas mediante OCX y ActiveX, es decir, ¿como hago tal o cual cosa?, directamente busca un control que lo haga y pegalo en el programa. En mi caso con 4 controles de ese tipo, el programa se relentizaba mucho.
saludos