Delphi VS Visual Basic

[Neftali [Germán.Estévez]]

Si quieres comparar Delphi debes compararlo con otra cosa.

He trabajado con VB desde la versión 3 en adelante (hasta llegué a hacer mis pinitos con la versión 3 que era para MSDOS -una virguería por cierto-) y creo que es un lenguaje de iniciación. NO lo veo adecuado para proyectos grandes, por sus características en general.

Para proyectos pequeños o para empezar en programación, tal vez, por su simplicidad y rápido aprendizaje, pero no para algo más allá...

[[Lepe]]

Estoy con Neftali.

Yo usé VB 5 durante un año y medio (me iniciaba en lenguajes visuales), despues tuve la posibilidad de probar Delphi 3; con el mismo desprecio que se tira un pañuelo usado, deseché VB.

Con Delphi llevo 5 años, y todavía tengo para rato .

Saludos

[[seoane]]

Yo estuve trabajando con Visual Basic durante un año y cuando querias hacer algo un pelin complicado tenias que recurrir a la API, cosa que no es nada facil ya que habia que importar las funciones una a una. Para mi el basic no vale ni para enseñar, siempre me ha parecido que el pascal es un leguaje mucho mas apropiado para aprender a programar.

Aun asi es sorprendente el numero de empresas que ofrecen puesto de trabajo para programador de visual basic. ¿buena promocion por parte de microsoft? ¿muchos programadores disponibles? ¿expediente X? Lo cierto es que en algunas escuelas se esta utilizando para enseñar a programar y puede que de ahi venga su popularidad.

[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!

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

[Neftali [Germán.Estévez]]

Empezado por Neftali

...para empezar en programación, tal vez, por su simplicidad y rápido aprendizaje

Bueno yo dije esto y lo sigo manteniendo.
Para gente que nunca ha programado, le es más fácil empezar con Visual Basic que con Delphi.
He estado unos cuantos años dando clases de programación y la experiencia avala esta afirmación.
Para alguien que no sabe lo que es un IF, qué diferencia hay entra una VARIABLE y una CONSTANTE o que piensa que un FOR es una marca de coche, os aseguro que programa antes una AGENDA en VB que en DELPHI.

La premisa de esta afirmación es que sean personas que se inician en la programación. Yo creo que esta otra afirmación se refiere a lo mismo:

Delphi es más difícil de usar que Visual Basic al principio...

No entro en otras cuestiones, ni en pensamientos "a más largo plazo"; Creo que esto es debido (también me baso en la experiencia) es que una programación orientada a eventos únicamente (VB) es más sencilla de "digerir" al principio que una Orientada a Objetos (DELPHI). Realmente para principiantes en la programación el concepto de Objeto, que hay que crear y destruir "cuesta un poco de entender".

[[ArdiIIa]]

Empezado por Neftali

Bueno yo dije esto y lo sigo manteniendo.
Para gente que nunca ha programado, le es más fácil empezar con Visual Basic que con Delphi.
He estado unos cuantos años dando clases de programación y la experiencia avala esta afirmación.

Que debemos entender con "gente que nunca ha programado", considerando que nos estamos moviendo en un entorno profesional ?
La evolución de estas herramientas ha sido tan grande, que cuando uno llegaba al "hola mundo", ya se consideraba programador, y esto gracias a las herramientas (visuales). Antes cuando había que picar más código, la gente no era tan osada.
Yo también he dado clases, y es obvio que la gente que arrastraba una sólida formación, aunque fuera en otras materias, asimilaba perfectamente los conceptos OPP y cualesquiera otros, pero claro está, asimilar conceptos, no es lo mismo que tener una visión clara de lo que se puede o no se puede.
Otra cuestión es si se debería considerar a Delphi como un lenguaje ideal para la formación; que a mi juicio y a pesar de que tenga una "supuesta" curva de aprendizaje algo dura, sería lo ideal dado los resultados posteriores. Que mas o menos vendría a ser asimilable con sacarte un carnet para ciclomotor o para un Airbus380

[Neftali [Germán.Estévez]]

Empezado por ArdiIIa

Que debemos entender con "gente que nunca ha programado", considerando que nos estamos moviendo en un entorno profesional ?

Bueno, no tiene porqué...
Ni en el mensaje original, ni en la comparativa se cita que estemos hablando de profesionales de la informática.
Mucha gente aprende (o intenta aprender) a programar por hobby o por curiosidad; No todos los que se adentran en el mundo de la programación lo hacen para dedicarse a ello profesionalmente.

Hay personas que son usuarios avanzados en windows y que quieren hacer sus "pinitos" en programación. Igual que yo puedo hacer mi "pinitos" en diseño gráfico; No soy ni mucho menos diseñador, ni he estudiado para ello, pero me gusta "toquetear" programas, hacer pruebas y voy aprendiendo sobre la marcha. Posiblemente PhotoShop sea mucho mejor que PhotoFilter (por cuierto muy bueno y gratuíto; link ) pero para mí sea más "adecuado" empezar por el segundo y luego "saltar" al primero.

[roman]

Sería interesante leer la opinión del amigo Caral. Si no entiendo mal, él no es un profesional de la informática, sino un empresario que decidió hacer su propio sistema- ¡y muy bien que lo hizo! -y lo hizo en Delphi. Desconozco si antes programó en VB.

De cualquier manera, yo creo que decir que es más sencillo para el novato, entender la programación orientada a eventos de VB que la orientada a objetos de Delphi, si bien es una afirmación dictada por la experiencia, no estoy seguro que sea aplicable precisamente en el contexto de un usuario avanzado que quiere hacer sus pininos. Si bien Delphi permite una buena programación orientada a objetos, ¿cuántos de nosotros realmente aprovechamos esa característica? El instanciar un objeto y asignarle propiedades, no es programar orientado a objetos. Yo creo que tal usuario avanzado, la mayoría de veces, programará usando exclusivamente eventos. Y en ese punto estamos "igual" que con VB, y creo que es así como habría que hacer la comparación en cuestión de facilidad de aprendizaje.

// Saludos

[[ArdiIIa]]

Empezado por roman

El instanciar un objeto y asignarle propiedades, no es programar orientado a objetos.
Yo creo que tal usuario avanzado, la mayoría de veces, programará usando exclusivamente eventos.

Es obvio que siempre tienes bastante razón, pero siempre está la excepción que rompe la regla...
Yo conocí la OPP en Clipper de la mano de Antonio Linares con su famosa librería Fivewin, de la que estoy seguro que muchos "viejos cliperos" conocerán, así como de la versión 5 de Clipper en la que ya se podían hacer pinitos con sus browsers y columnas.
Desde entonces considero que ese tipo de programación te brinda un rendimiento superior a lo tradicional y en todos aquellos lugares que puedo potenciarlo, así lo hago.
Supongo que no estoy diciendo nada nuevo, sino únicamente remarcar que la tendencia genérica, no tiene porque ser la de programación de eventos, aunque seguramente, si sea la mayoritaria.

[roman]

Empezado por ArdiIIa

Desde entonces considero que ese tipo de programación te brinda un rendimiento superior a lo tradicional y en todos aquellos lugares que puedo potenciarlo, así lo hago.

Pero, ¡es que yo nunca dije lo contrario! A ver; aquí se mencionó- o así lo entendí -que para el novato, y específicamente aquél que no es informático, sino usuario avanzado, es más sencillo el paradigma de orientación a eventos que el de orientación a objetos. Yo no dudo que así sea, como tampoco dudo que la orientación a objetos sea superior. Pero muchos usan o usamos delphi sin realmente usar ese paradigma, por ello aclaré lo de que usar un objeto no es lo mismo que hacer OOP. Y muchos de quienes se ponen a programar como usuarios avanzados harán lo que muchos hemos hecho: colocar componentes en un formulario y programando sus eventos. Y eso es lo mismo que hace quien comienza a usar VB. Así que, ¿donde está la mayor facilidad de aprendizaje en VB?

// Saludos

[[Delphius]]

Empezado por roman

De cualquier manera, yo creo que decir que es más sencillo para el novato, entender la programación orientada a eventos de VB que la orientada a objetos de Delphi, si bien es una afirmación dictada por la experiencia, no estoy seguro que sea aplicable precisamente en el contexto de un usuario avanzado que quiere hacer sus pininos. Si bien Delphi permite una buena programación orientada a objetos, ¿cuántos de nosotros realmente aprovechamos esa característica? El instanciar un objeto y asignarle propiedades, no es programar orientado a objetos. Yo creo que tal usuario avanzado, la mayoría de veces, programará usando exclusivamente eventos. Y en ese punto estamos "igual" que con VB, y creo que es así como habría que hacer la comparación en cuestión de facilidad de aprendizaje.

¿A quien estaríamos considerando un novato? Como ya se ha dicho en este debate... y se sabe muy bien... el novato puede ser tanto aquel universitario que recien estudia la carrera como la ama de casa que busca divertirse en su rato libre (creo que fue exagerado el ejemplo... pero creo ilustrar el amplio concepto de lo que es un novato).
Para aquellas personas que se inician en la actividad le resulta (debería serlo) más sencillo aprender... obvio.
Yo estoy estudiando para ser ingeniero en informática (y aclaro que la formación que se nos ha dado en mi universidad no está muy enfocada en la programación sino más bien en la dirección y formulacion de proyectos informáticos) y creo que muchos de los que estamos analizando estas cuestiones somos (o seremos) profesionales de la materia.
Viendolo desde el punto de vista académico (disculpen que lo exponga según mi experiencia como alumno), lo ideal para armortiguar la curva de aprendizaje no va por una cuestión del lenguaje sino más por la lógica de aprendizaje. ¿Qué es lo primero que se le enseña? Pensar, abrir la mente... una vez que la mente se adapta a pensar en forma lógica/matemática se le enseñan simples herramientas visuales (diagramas de bloques), pseudocódigo y a la par las sentencias simples: IF, CASE, FOR, REPEAT, WHILE, ASIGNACION y estructuras de datos. Esta primera absorción es a modo simple: conocer que hacen o para que se las emplea.
Cuando comienzan las primeras lecciones de prácticas se toma contacto con problemas sencillos, sumas, promedios, ordenacion de arrays, busqueda... Para ello lo ideal es emplear un lenguaje similar a la sintaxis que fueron vistas, algo intituivo, sencillo y que no sea "rebuscado". En mi caso fue Pascal.

Lo anterior corresponde a los inicios... para climatizar al programador. Lo que sigue en su enseñanza es la polémica desatada en los últimos mensajes.
Cuando se entiende la programación procedural... le salen con un mundo distinto: la programacion por eventos u objetos. Yo la vi en ese orden... y a mi parecer esto influye en la mente y el aprendizaje.
Decirle al estudiante que ahora cuenta con eventos asociados a un boton es totalmente distinto que decirle: el boton es un objeto que posee eventos (y demás cosas...) y puedes heredar de el y agregarle más eventos.
Y según el lenguaje que se use en su enseñanza le resultará sencillo o complicado.

Yendo al tema VB vs Delphi: Yo vi POO con VB y la programacion por eventos en Delphi. ¿Sería lo correcto? No sé...
Todo se resume en la lógica (a si lo veo y entiendo yo) que les hablaba inicialmente.

A lo que voy es que el aprendizaje dependerá de lo que vea inicialmente y con que herramienta lo aprenda. Resulta mejor ver primero por eventos y luego POO. Ver ambas cosas a la vez, resulta demasiado complicado.

Como dices roman... todo depende de la facilidad de aprendizaje. Pero éste aprendizaje depende de la "cultura informática" que posea la persona. La cultura de un programador pasa por pensar lógicamente. Si uno entiende lo que es un IF, no interesa el lenguaje. Si se tiene la mente para pensar en sentencia simples ya no interesa si es por eventos u POO. Cada enfoque o paradigma tiene sus sutilesas y manera propia: Ahora es cuestión de que el estudiante entienda lo que es evento y lo que es objeto. Y como emplear dichas sentencias simples en cada paradigma.

Ahora... pongamos al ama de casa. ¿Entiende lo que es POO?¿Un IF?¿Que es evento? Lo más seguro es que se agarre un libro especializado en un lenguaje. Pongamos un ejemplo: Delphi y la Cara Oculta. En los primeros capítulos vera un poco de eventos... POO... controles... deteción de errores... como manejar el IDE. ¿Esto lo hace programadora? Yo, lo dudo. Se verá con un mundo de controles, objetos clases... y deberá buscar otro libro que le explique POO... cuando entienda objeto se dirá: "y ahora ¿que le pongo?... se lo que debe hacer pero como le digo que hacer?" Busca algo más simple: las sentencias simples... Si sabe inglés, tiene la mitad hecha.

¿Se ha entendido lo que dije? Porque eso espero

Con respecto a lo que remarqué con rojo en tu frase: se trata de la manera de como implementar la POO. Se tiene un problema: se buscan las clases... su diagrama de secuencia, de estado, etc. Se codifica... Ahora se usa el aspecto visual para pasar los parámetros hacia los objetos (previamente creados, obvio). Se disparan los eventos necesarios y se deja que las relaciones entre los objetos (mensajes... o como prefieran llamarle) se disparen hasta objeter el resultado final. Si debe notificarse el resultado, se lo muestra en pantalla. Asi lo veo yo... una mezcla de eventos y POO.
Es cierto también que no siempre vamos a hacer 20 clases, es más... si ya tenemos las suficientes y las adecuadas sólo bastará "engancharlas" con el aspecto visual (mediante los eventos) para obtener el aplicativo. ¡Eso es lo lindo y sencillo que le encuentro a Delphi!
Ahora bien... diste un punto clave:El instanciar un objeto y asignarle propiedades, no es programar orientado a objetos
.Cierto... pero tampoco hay que ser extremistas para decir que nunca hacemos POO. La POO se construye mediante los mensajes entre los objetos y el poder de concentrar variables, estados. Y hay casos en que ni siquiera es necesario emplear objetos pues se trata de sistemas muy simples. Yo para ello declaro unidades al estilo clásico: funciones y procedimientos sueltos (yo las llamo "Unidades API"). Si veo que la solución es algo más rebuscado, como pasos de variables, secuencia de acciones y procedimientos, almacenamiento de variables, interaccon entre varias funciones, y demás... declaro cases según el diagrama de clases adecuado (y tratando de seguir los patrones) y hago empleo de dichas funciones "API" mediante eventos y mensajes en los objetos.

Saludos, y disculpen que suelte semerendo rollo de hilo.

[sakuragi]

esto ta mas claro que el agua, pues claro esta mejor delphi que visual basic como de 1 a 1000


salud!

[jachguate]

Bueno, allí va un código, a ver en cuantas líneas queda en vb:

Código Delphi [-]
  for I := 0 to ControlCount - 1 do
  begin
    Controls[i].Top := Controls[i].Top + 5;
    if (Controls[i] is TButton) then
      TButton(Controls[i]).Caption := TButton(Controls[i]).Caption + '!';
    if (Controls[i] is TEdit) then
      TEdit(Controls[i]).OnChange := NuevoEditChange;
  end;

Hasta luego.

[[egostar]]

Empezado por jachguate

Bueno, allí va un código, a ver en cuantas líneas queda en vb:

Código Delphi [-]
  for I := 0 to ControlCount - 1 do
  begin
    Controls[i].Top := Controls[i].Top + 5;
    if (Controls[i] is TButton) then
      TButton(Controls[i]).Caption := TButton(Controls[i]).Caption + '!';
    if (Controls[i] is TEdit) then
      TEdit(Controls[i]).OnChange := NuevoEditChange;
  end;

Hasta luego.

Bueno haciendo honor a nuestro compañero ucanneo, porque no comentas que es lo que hace ese código digo, ya sabes que habemos muchos que no tenemos esa capacidad de conceptualización

Salud OS

[HCammus]

Empezado por jachguate

Bueno, allí va un código, a ver en cuantas líneas queda en vb:


Código Delphi [-]
for I := 0 to ControlCount - 1 do
begin
Controls[i].Top := Controls[i].Top + 5;
if (Controls[i] is TButton) then
TButton(Controls[i]).Caption := TButton(Controls[i]).Caption + '!';
if (Controls[i] is TEdit) then
TEdit(Controls[i]).OnChange := NuevoEditChange;
end;





Hasta luego.

En VB quedaría exactamente igual solo que no necesitas ni el Begin ni el end; además que si se desea un If de una sola línea debería quedar al frente.

Yo ese código le agregaría un ElseIf en vez de otro If ya que el control ó es un TButton ó es un TEdit y no ambos al mismo tiempo.

Creo que para la versión 6 ó 4 del Delphi no se puede concatenar así tan olimpicamente el primer If, me disculpo si me equivoco.

Otra cosa es que la propiedad OnChange no existe para el TextBox, por cierto deberían de tratar de poner ejemplos para versiones iguales, el VB solo quedo hasta la versión 6, además deberían ser código que no relacionen en si a las propiedades de los objetos ya que el tratamiento de ellos si es abrumador entre ambos lenguajes.

Código PHP:

Dim/Private ctl As Object

For Each ctl In NombreFormulario.Controls
    If (TypeOf ctl Is TipodeControl) Then

    End If
Next 


[ixMike]

Empezado por HCammus

En VB quedaría exactamente igual solo que no necesitas ni el Begin ni el end; además que si se desea un If de una sola línea debería quedar al frente.

Yo ese código le agregaría un ElseIf en vez de otro If ya que el control ó es un TButton ó es un TEdit y no ambos al mismo tiempo.

Creo que para la versión 6 ó 4 del Delphi no se puede concatenar así tan olimpicamente el primer If, me disculpo si me equivoco.

Otra cosa es que la propiedad OnChange no existe para el TextBox, por cierto deberían de tratar de poner ejemplos para versiones iguales, el VB solo quedo hasta la versión 6, además deberían ser código que no relacionen en si a las propiedades de los objetos ya que el tratamiento de ellos si es abrumador entre ambos lenguajes.

Código PHP:

Dim/Private ctl As Object

For Each ctl In NombreFormulario.Controls
    If (TypeOf ctl Is TipodeControl) Then

    End If
Next 


El código de jachguate tampoco necesitaría del begin-end si no hubiera puesto esto:

Código Delphi [-]
Controls[i].Top := Controls[i].Top + 5;

y hubiese usado un else if (en Delphi va separado, pues es lo mismo, y en el ejemplo de jachguate lo único que arregla ponerlo es ahorrarse el escribir el begin-end del bucle for).

Empezado por HCammus

además deberían ser código que no relacionen en si a las propiedades de los objetos ya que el tratamiento de ellos si es abrumador entre ambos lenguajes

¿Por qué no? ¿Acaso no se están comparando? Tu código sería algo más largo si hubieras puesto un ejemplo (aunque sea con otras propiedades de otros tipos de objetos).


Salu2