Delphi VS Visual Basic

[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

[OSKR]

roman:

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.

Yo supongo q para algo asi se pudo inventar el polimorfismo, lo cierto del caso es q no me importa si es declarada o no la variable, lo q si me enferma es la magia q te devuelve ciertas funciones como el GetObject de VB y un for magico q adivina las iteraciones q ha de hacer respecto a algo q devolvio la funcion anterior, esto es un ejemplo muy especifico...para no ahondar en el tema.

[roman]

Empezado por OSKR

para no ahondar en el tema

¿Y por qué no hacerlo?

Realmente yo no estoy defendiendo a VB. Yo apenas llegué a la versión 4 y la dejé en cuanto me enteré de la existencia de Delphi. Más que nada la hago de abogado del diablo porque me parece que a veces tendemos a descalificar dando argumentos que no van sobre la esencia misma del problema y a quien se inicia en la programación posiblemente no le quede claro el porqué un lenguaje puede ser mejor que otro.

Por ello no me molestaría en lo más mínimo que se ahonde en el tema. Creo que es el objetivo de preguntas como la de este hilo.

// Saludos

[Robert01]

¡visual basic es un lenguaje muy lindo! ... ¡pero hay cosas que con el no se pueden hacer!

[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

[delphi.com.ar]

Empezado por seoane

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

Si, si.. es una opción IMPRESCINDIBLE en cualquier proyecto serio en VB... Pero no es una opción por defecto, y me he peleado mas de una vez con el lenguaje, cuando la olvido en un nuevo archivo

[OSKR]

roman:

¿Y por qué no hacerlo?

Porq es una encuesta, lo q pide el chamo son razones supongo q generales como las q explico delphi.com.ar, no entrar en el detalle...es màs tal vez no sepa q era IADS (q por cierto va de la mano con Visual Studio xq ahi si funciona), si necesita usar VB por una u otra razòn no serìa conveniente echarle a perder la tarde por una caso tràgico de mi existencia, mas bièn como una advertencia por si acaso un dia se topa con la misma ocurrencia .

Más que nada la hago de abogado del diablo porque me parece que a veces tendemos a descalificar dando argumentos que no van sobre la esencia misma del problema y a quien se inicia en la programación posiblemente no le quede claro el porqué un lenguaje puede ser mejor que otro.

bueno...viejo...es mas o menos parte de lo q qiero decir

[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á...
  .

[amadis]

LA ELECCION DE UN LENGUAJE

En mi carrera de analista comenzamos con lenguajes de DOS, como Cobol, Basic, Clipper,y Pascal .

Salimos con buena base en los 3 ultimos, a mi particularmente me encantaba Clipper por la potencia con bases de datos y sencillez de programacion incluco con menues y graficos complejos.

Pues llego el momento de migrar a Windows, comencé por Microsoft Visual Fox ya que la sintaxis era similar a Clipper y me parecio muy basico y nada mas orientado a manejar cualquier tipo de operaciones con tablas.
Y si te sales de eso se muere o te complica la vida...

Luego Pasé Visual Basic, me gustó más incluso hice varios proyectos pero me resulto muy basico.

Y cuando conocí Delphi 6 me voló la cabeza la potencia y sencillez de todo.
Y el ver que cada dia que pasa era una limitación menos.

Actualmente programo en el 7 y estoy muy conforme.

Aunque me sigo rompiendo la cabeza mas aun con tal de aprender.

[Elias_02]

Yo he trabajo con c++ builder 6 de la borland y es magnifico,pero cuando conoci delphi me encanto!!! siemplimente me gusto.

[[poliburro]]

No se ustedes, a mi estos debates me dan sueño,

Por supuesto Delphi será mejor que visual basic, por n + 1 cosas.

Punto.

Creo que ahora que microsoft ha apostado al 100 % a Punto net, Este debate tiene un tufo de anacronismo que ni el se lo aguanta.



Mi muy particular punto de vista.

jejejej

[roman]

Tienes razón, ahora que ya ni Microsoft defiende a VB, esto es como debatir qué es mejor, si Lotus o QPro

// Saludos

[[felipe88]]

!!! Viva Delphi ¡¡¡ :d

[[poliburro]]

Pues, Viva¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡ jajajajaj

[HCammus]

Vaya veo que la encuesta fue aplastante, leí casi todos los comentarios y realmente me ha parecido bastante injusto culpar a uno u otro lenguaje de nuestra poca capacidad para desarrollar x ó y programa.

Yo me maravillaba al ver las cosas que hacia pascal siendo un compilador de DOS, no culpen a los lenguajes de programación de su poca capacidad para pensar, eso SI es patético.

Que con VB no se puede hacer esto, que con Delphi tal cosa, yo he visto hacer cosas en ambos lenguajes que dejarían descrestado a más de uno, incluso vi un programa para hacer multithread en VB (cosa que dicen es imposible de hacer con este lenguaje para principiantes), hablando un poco del Delphi solo me parece un lenguaje engorroso para programar y el VB me parece que no es demasiado exigente al fin y al cabo el lenguaje no es culpable de nuestras torpezas al escrbir código, si fuese el caso realmente ningún lenguaje de programación serviria para los desarrolladores de software, si tienen una mente tan cerrada de solo hacer lo que humamente el lenguaje permite, gracias a DIOS si hay gente que aprende lo importante de la programación la cuál es su LÓGICA y no que este lenguaje me es más bonito, que este lo desarrollo sultanito ó que este si sabe entender mis frustracciones y este otro no.

[[egostar]]

Empezado por HCammus

Vaya veo que la encuesta fue aplastante, leí casi todos los comentarios y realmente me ha parecido bastante injusto culpar a uno u otro lenguaje de nuestra poca capacidad para desarrollar x ó y programa.

Yo me maravillaba ver las cosas que hacia pascal siendo un compilador de DOS, no culpen a los lenguajes de programación de su poca capacidad para pensar, eso SI es patético.

Que con VB no se puede hacer esto, que con Delphi tal cosa, yo he visto hacer cosas en ambos lenguajes que dejarían descrestado a más de uno, incluso vi un programa para hacer multithread en VB (cosa que dicen es imposible de hacer con este lenguaje para principiantes), hablando un poco del Delphi solo me parece un lenguaje engorroso para programar y el VB me parece que no es demasiado exigente al fin y al cabo el lenguaje no es culpable de nuestras torpezas al escrbir código, si fuese el caso realmente ningún lenguaje de programación serviria para los desarrolladores de software si tienen una mente tan cerrada de solo hacer lo que humamente el lenguaje permite.

Hola HCammus bienvenido al Club, respeto tu postura, solo se te olvida una cosa, este es un club de delphi, si la encuesta (y las hay) estuviese en un foro de VB, por supuesto que la tendencia resultaria diferente y SI estoy convencido de que la calidad de las aplicaciones son en un porcentaje muy alto culpa o fortuna del programador.

Delphi desde mi punto de vista no es engorroso y efectivamente en aquellos años de pascal en DOS si que lo era, ahora puedes incluso hacer un programa digamos decente sin escribir una sola linea de código.

Salud OS