Delphi VS Visual Basic

[vtdeleon]

Creo que es un mal sitio para hacer esa encuesta. No creo que VB gane.

He votado por Delphi, es el lenguaje por el cual he comenzado(*) y el cual tambien me ha gustado. He probado el VB y ... no se, me complica mucho la vida.

*Estoy alrevez de los demas. 1ro con Delphi y despues con los demas (probando un poco)

[delphi.com.ar]

Yo trabajo con ambos, y cuando estoy en VB extraño Delphi pero no al revés. Por otro lado, VB tiende a crear malos hábitos, muchos de los programadores que se iniciaron por VB, es muy difícil encarrilarlos en la programación prolija y terrenal (No mágica ). Un comentario mío, que no ha quedado muy viejo:

Técnicamente son lenguajes incomparables, aunque Delphi ha nacido como rival de VB, creo que el rival le ha quedado pequeño desde su nacimiento. Cuando en le año 95 salió a la luz Delphi 1, poseía muchas cualidades que vimos hace poco como novedad en VB.NET, tales como: Programación Orientada a Objetos con todo lo que esto implica (Herencia, encapsulamiento y polimorfismo), sobrecarga de procedimientos y funciones, soporte de multithreading, evaluaciones por circuito corto, programación condicional verdadera, integración de la WinApi al lenguaje, posibilidad de bajar y subir de nivel de una línea de código a otra con código assembler integrado, un debugger muy completo... Además de ser un lenguaje fuertemente tipado con una extensa librería de clases, una extensa gamas de componentes con código abierto!!! y un IDE muy customizable. Las versiones posteriores ya compilaban en 32 bits, y tenían ventajas como Herencia Visual, anclaje de componentes (Anchors), programación de aplicaciones Web, WebServices, utilización y creación de objetos COM + ActiveX......
Otra diferencia notable en la primer versión, es que Delphi compilaba en código nativo, sin necesidad de runtimes ni DLL´s extras logrando velocidades de ejecución 9 veces superiores a las de VB3.
Con Delphi Borland lorgó un lenguaje con sintaxis elegante, con una curva de aprendizaje muy cercana a la de VB con una potencia final similar al C.

Para el desarrollo de aplicaciones de base de datos, simplemente hay que ser un buen diseñador, porque en este sentido Borland se ha tomado muy en serio la programación visual, simplemente definiendo las tablas, sus relaciones y las consultas que necesitemos, y arrastrando los campos sobre cualquier formulario, tendremos ya resuelta una grán parte de la aplicación.
Con respecto a los reportes, si quieres algo integrado que quede dentro del EXE puedes utilizar el QuickReports, si este no te gusta, a mi parecer es el talón de aquiles de delphi, puedes utilizar CrystalReports como en VB... o alguno otro de delphi

[roman]

Empezado por delphi.com.ar

VB tiende a crear malos hábitos, muchos de los programadores que se iniciaron por VB, es muy difícil encarrilarlos en la programación prolija y terrenal

Por más que me guste Delphi sobre VB la verdad no estoy de acuerdo con este argumento. Tanto en VB como en Delphi se puede programar horriblemente y yo le echo la culpa más al RAD en general que a uno u otro lenguaje.

// Saludos

[delphi.com.ar]

Empezado por roman

Por más que me guste Delphi sobre VB la verdad no estoy de acuerdo con este argumento. Tanto en VB como en Delphi se puede programar horriblemente y yo le echo la culpa más al RAD en general que a uno u otro lenguaje.

Estoy de acuerdo en que en cualquier lenguaje se puede escribir código horrible. Pero lo he visto en más de un caso, y confirmo lo que digo. VB le da al programador ciertas "facilidades" como la no declaración de variables, la compilación tardía, la magia del lenguaje (Infinidad de detalles que si les interesa con tiempo puedo nombrar), la carencia de tipos de datos (que hacen al programador diseñar incorrectamente funciones y esquemas), la creación automática de ciertas cosas y ciertas no (ejemplo formularios)... etc... etc… etc…
Muchos de estos detalles fueron replanteados en VB.NET que poco tiene que ver con VB mas que heredar alguna sintaxis…

Como dije alguna vez: ¡VB Destroy your mind!

[roman]

No me convences. Varias de estas características que mencionas a mi me parecen muy prácticas. No digo que en VB pero he visto código en PHP muy prolijo, y PHP me gusta entre otras cosas, precisamente por no tener que declarar cada simple variable, cada I y cada J que usemos de contador- a veces resulta exasperante. Y, bien usado, la falta de tipos me gusta cada vez más. Que una función, por ejemplo, te pueda devolver o bien un objeto o bien false en caso de no existir tal objeto, se me hace muy cómodo, el tipo de datos se adapta a tus necesidades.

// Saludos

[OSKR]

delphi.com.ar:

Estoy de acuerdo en que en cualquier lenguaje se puede escribir código horrible. Pero lo he visto en más de un caso, y confirmo lo que digo. VB le da al programador ciertas "facilidades" como la no declaración de variables, la compilación tardía, la magia del lenguaje (Infinidad de detalles que si les interesa con tiempo puedo nombrar), la carencia de tipos de datos (que hacen al programador diseñar incorrectamente funciones y esquemas), la creación automática de ciertas cosas y ciertas no (ejemplo formularios)... etc... etc… etc…
Muchos de estos detalles fueron replanteados en VB.NET que poco tiene que ver con VB mas que heredar alguna sintaxis…

Estoy 1000% de acuerdo .....No!! no hay error!! es un 1000 no un 100 .
Estuve hace una semanas probando funciones de aqellas q reemplazaran el estilo de las DLL (las de las funciones) por clases como "IADS" en el maravilloso mundo de la .NET y lo q en Builder me fue de patadas o en Visual C++ con extenso codigo no me servia sin razon aparente, en Visual Bashit con codigo màgico y mucho mas corto servìa, eso es porq ya existen cosas predefinidas pero si vas a hacer o construir algo serio....vas a sudar la gota gorda.
roman:

Que una función, por ejemplo, te pueda devolver o bien un objeto o bien false en caso de no existir tal objeto, se me hace muy cómodo, el tipo de datos se adapta a tus necesidades.

Eso para mì simplemente sería el objeto o un NULL q en mi mundo es simplemente igual q un false (C), para nada aceptarìa una funcion q recibiera parametros e internamente a veriguar q tipo de dato recibió...para mi eso es inaceptable....a excepciòn de los Variant....ellos si lo justifican

[roman]

Empezado por OSKR

para nada aceptarìa una funcion q recibiera parametros e internamente a veriguar q tipo de dato recibió...para mi eso es inaceptable....a excepciòn de los Variant....ellos si lo justifican

A mi esto me maravilla. Es como si dependiendo del humor con que me levante un día paso unos parámetros y otro día otros de naturaleza totalmente distinta y la rutina tiene que batallar con mis locuras. Las funciones tienen un cierto objetivo, normalmente documentado y deberán usarse así, no le veo problema.

Normalmente no intentaría averiguar qué clase de parámetros estoy pasando. Hacerlo así presupondría que intento usar una misma rutina para múltiples cosas, lo cuál, eso sí, se me hace inaceptable.

Y más me maravilla que los variant, que vienen a ser variables sin tipo, esos sí son válidos. Si la falta de tipos no fue válida, no lo será en ningún caso.

Empezado por delphi.com.ar

Digamos, venimos usando una variable iCantidadPersonas y de golpe en algunos lugares de código escribimos iCantdadPersonas, el compilador lo tomará como válido y esa variable no sera "procesada" cuando tenía que serlo.

Ciertamente, y bien podría ser un verdadero problema en VB, no lo sé. Pero digamos en PHP, si yo pongo

Código PHP:

print $hola; 


el intérprete sí me marcará un warning indicando que la variable $hola no está definida. Sin embargo, si pongo:

Código PHP:

$hola = 'pos, hola';
print $hola; 


no tendré ningún problema y aún así no tuve que declarar la variable: el primer uso la declara y determina el tipo de datos.

Empezado por delphi.com.ar

apuntaría a la sobrecarga de operadores, algo de mucho mas nivel

Algo que, por cierto, al menos hasta la versión 7, no existe en delphi.

// Saludos

[delphi.com.ar]

Empezado por roman

...me gusta entre otras cosas, precisamente por no tener que declarar cada simple variable, cada I y cada J que usemos de contador...

La no declaración de variables lleva a producir errores totalmente inesperados, y difíciles de encontrar, cuando tenemos un problema sintáctico al nombrar una variable. Digamos, venimos usando una variable iCantidadPersonas y de golpe en algunos lugares de código escribimos iCantdadPersonas, el compilador lo tomará como válido y esa variable no sera "procesada" cuando tenía que serlo.

Empezado por roman

...la falta de tipos me gusta cada vez más...

La falta de tipos termina resultando que todos los tipos son tratados como un tipo genérico, absurdamente casi siempre una cadena, lo que es totalmente imperformate. Me gustan mucho mas los lenguajes fuertemente tipados, en el caso que comentas, apuntaría a la sobrecarga de operadores, algo de mucho mas nivel...

PD: Sobre gustos no hay nada escrito, decía la viejita mientras se comía los mocos

Saludos!

[[seoane]]

Empezado por delphi.com.ar

La no declaración de variables lleva a producir errores totalmente inesperados, y difíciles de encontrar, cuando tenemos un problema sintáctico al nombrar una variable. Digamos, venimos usando una variable iCantidadPersonas y de golpe en algunos lugares de código escribimos iCantdadPersonas, el compilador lo tomará como válido y esa variable no sera "procesada" cuando tenía que serlo.

Para eso esta la Option Explicit que obliga a declarar las variables antes de utilizarlas. Yo es lo primero que escribia cuando usaba Visual basic

[[egostar]]

Empezado por vtdeleon

Creo que es un mal sitio para hacer esa encuesta. No creo que VB gane.

Coincido con este comentario.

Si quieres que te digamos con que debes programar, la respuesta es DELPHI por razones obvias.

Y siendo objetivos, podrias hacer esta misma encuesta en un foro para seguidores de VB y te darás cuenta de las tendencias. Yo sugiero que programes con lo que realmente te haga sentir comodo. Ya no depende del foro.

Saludos