El último código se entiende ^^

Bueno si comes mucho tocino te pones gordo, puedes morir de un ataque al corazon y entonces si... tu velocidad es cero, aún estando gordo
Pero bueno no voy a discutir más relaciones velocidad-tocino que pudiese escribirse un libro, exagero quizá solo una pequeña tesis

_____________________________

Pero en fin, volviendo al hilo normal, creo que es bastante ceptable el defender mi punto de vista en base a la legibilidad de los códigos (Aclarando nuevamente que es muuuuuuuuuuuuy personal, que por lo visto creeen que hablo por todos y nuevamente recalco "es personal" y es una de mis argumentaciones, no todas), puesto que no es lo mismo trabajar solo que hacerlo con 5 o 6 personas más, en realidad es mas estresante, y empiezas a agradecer esas líneas solitarias, en fin que si hay relacion y mucha, algunas veces es increible ver como en pocas lineas de código VB hace lo que otros no logran ni en 5 o veces, pero eso es gracias a lo que el mismo lenguaje regala, entonces si hay herramientas disponibles ¡Hay que usarlas! y no porque una de ellas tenga menos valor o haga menos cosas hay que desmeritar sus virtudes es como si fuera Racismo de lenguaje de programación :D(jajajajaja):D.


Weno me ha dado mucho gusto el ver como se apasionan en este foro, eso es bueno, entiendo totalmente que delphi sea el consentido y no me molesta al contrario siempre es bueno estar abierto a alternativas, y todos enemos nuestro gallo (el mio es builder6 en programacion, 3dsMax en animacion, seguidos por VB, delphi, blitzBasic y Blender, pero todos tendremos siempre nuestra lista y es completamente comprensible que muchos tengan su primer lugar )


saludos y gracias por las respuestas (se nota que tengo tiempo libre XD)

Si aquí todos son muy apasionados a Delphi, demasiado para ser sinceros, yo les mostrare un programa que estuve depurando en Delphi 4 hace ya 2 años y que me costo muchisimo asimilar las torpezas del que lo programo, solo para decirles que los comentarios que el código tenía solo daban risa en vez de orientación.

Hola ucanneo, me da gusto que defiendas tus ideas, es obvio que aquí somos delphi en un porcentaje mayoritario pero tambien te puedo decir que sabemos reconocer cuando se dan razones de peso.

Me pregunto si te interesaria hacer un ejercicio de ese código que mencionas y lo comparamos con lo que se puede hacer con delphi ?. :)

Salud OS

Eso estaría muy bien, sería casi como un concurso o prueba.
En fin, es una pena que ya no tenga ese código... o sí? :)

Si sería interesante hacer demostraciones pero que quede denotado que no como competición sino como demostración, a veces esto de las competencias no es muy bueno, sería más bien como una forma de diversión de parte y parte, ó eso considero yo.

Yo me apunto a esto de las demostraciones ^^, pero la pregunta es si solo vale código propio???

Para mi todo esto no tiene vuelta de hoja:

Delphi es como esto:


y VB como esto:


Y bueno, con cualquiera de los dos uno llega a su destino pero obviamente no hay comparacion.

Para mi Delphi es como un Ferrari porque ya sabemos la altísima calidad de todo lo que interviene en su fabricación así como la forma artesanal con que se fabrican. Al igual que Ferrari, Delphi no es para cualquier programador.

VB por su parte bueno, pues es como un cochecito GM u otra gringa, destinado a venderse y a las masas.

En fin....me quedo con mi Delphi a mil por hora y hasta ahora (valgase la expresión) mis "competidores" que usan VB no me han visto ni el polvo.

cualquier código maestrín... enseñanos esas lineas mágicas que dices...

No me imagino que cosa puedas hacer tu en 5 lineas de codigo que en delphi se lleven tantas como mencionas... anda, impresionanos!!:cool:

No deberías de decir que Delphi no es para cualquier programador, por qué el lenguaje no hace al desarrollador, esas son palabras de calibre demasiado alto que incluso para aquellos que se intenten arriesgar con el Delphi como lenguaje padre podrían sentirse defraudados de solo leerlas.

xander que pena decirtelo pero en que momento dije yo algo de líneas mágicas ó código en 5 líneas que este hace que no hace el otro????, no pogas palabras que no he dicho en mis mensajes.

sorry, lo dijo ucanneo (siempre me pasa por no leer bien las cosas), es mas como muestra de mi arrepentimiento de haber perjurado en tu contra en este mismo momento me estoy agarrando a bofetadas con mi propia boina del che...

Pero igual no deja de ser una buena demostración esa... si logras ponernos aqui algún código maravilloso o algun ejemplo de algo que se haga mejor en VB que en Delphi, pero pues con código por delante, que entre gitanos no nos vamos a leer la mano

Claro pero yo considero que en ambos lenguajes se pueden hacer por igual las cosas, solo que dependiendo de lo que es, llevara más tiempo en uno u otro lenguaje, con respecto al mensaje tranquilo la idea mía no es venir a molestar ni causar broncas, aunque en ocasiones es algo difícil tratar de escribir tratando de ser objetivo sin caer en preferencias ni herir susceptibilidades, pero insisto más que tratar de demostrar que lenguaje es mejor es mostrar las cosas que la mente del ser humano es capaz de hacer, da igual como se presenten las cosas lo importante es el empeño que se le ponga ó al menos eso pienso yo personalmente.

No le veo el punto.

Es facil sacar un ejemplo de como en pocas lineas algo es mas simple en un lenguaje que en otro. Para la muestra, miren este codigo python:

La parte marcada es una compresion de lista y es uno de los idiomas de python que pueden ser muy utiles.

En VB, a pelo, se podia hacer por mucho tiempo un for...in. Ademas, los CASE son mas practicos (no estupidamente limitados a tipos basicos), es mas simple una automatizacion OLE basica (pero imposible algo complejo), en fin....

Pero la fuerza esta en el trabajo a largo plazo. Es muy simple sacar un ejemplo en VB de 1 hoja maximo que sea mas compacto que Delphi, por la razones de como se hizo el lenguaje. Pero una vez que empieza a existir muchas unidades de codigo, la estructura y la claridad de codigo, la obligatoriedad de declarar variables, los tipos de datos, las conversiones explicitas (nada de EXPLICIT ON) y eso por el estilo le da la vuelta a muchos lenguajes.

Incluso, aunque python patea que da miedo, y en contraste la sintaxis de pascal es muy restrictiva, no es dificil darse cuenta las ventajas de pascal en el largo plazo.

Delphi no es para cualquier programador.

Es para el programador que:

* Se documenta cuando algo no entiende
* Investiga los temas que el lenguaje y su documentación no le aclaran como él quiere
* Le gusta trabajar con orden.
* Procura depurar su programa aunque de entrada ya funcione bien
* Es un eterno optimizador
* No teme hacerse sus propias herramientas si no encuentra las que él busca.
* Tiene mente abierte y es capaz de probar otras formas de realizar cosas que ya sabe hacer.
* Busca más el desarrollar código eficiente y funcional aunque tarde un poco más.
* No le gustan los "wizards" y "códigos mágicos", se pregunta siempre "¿Cómo lo hicieron?"
* Puede llegar a pensar en términos de OOP casi pura, cada sistema lo imagina de inmediato como una serie de objetos que se "ayudan" entre sí.
* No le teme a leer temas "esotéricos" o que a simple vista parecen demasiado "elevados".
* Es humilde.

Si todos los programadores del mundo son así, entonces estoy en un error, Delphi si es para todos.

Personalmente yo tengo todas y cada una de esas características, yo detesto los asistontos, me gusta indagar sobre como se hacen las cosas y no simplemente copiar y pegar, antes de realizar un programa analizo con detenimiento que debo hacer, desde la interfaz gráfica hasta la forma más eficiente de ahorrar código, mantengo ordenado el código lo indexo con mínimo 4 espaciados, trato de abrir y cerrar cada elemento que deba hacerlo, detesto el código de una sola línea donde se agrupan hasta 20 instrucciones.

Leo habitualmente sobre como se deberían de hacer las cosas, incluso leo los comentarios que traen códigos realizados por terceros (desarrolladores), me preocupo por mirar en que línea se hace ó no una cosa, llego a estar hasta 10hras sentado en la PC leyendo sobre lenguajes de programación.

En cuanto a lo de las herramientas, siempre procuro hacer mis propios controles, esto lo aplico incluso cuando programo en HTML con AJAX.

He trasladado de varios lenguajes código a VB (digase código en C, C++ y Delphi, aclarando que código de nivel medio/bajo), ya que desde que sé entienda la lógica del lenguaje y esté en tus facultades mentales asimilar el código no interesa si esta escrito en código morse.

Lo único es que no soy programador de Delphi, soy programador en estos momentos de C# y PHP con AJAX.

PD: Soy demasiado perfeccionista, incluso hasta para escribir.
PD2: Yo programo en VB como hobby.

muy graciosa esa ocurrencia :)

Y tambien se puede decir

Entre bomberos no se pisa la manguera

:D:D:D

Salud OS

Suponiendo que en la forma hay un txt multilinea, donde el usuario puede escribir lo que sea, y posteriormente separarlo por palabras para agregarlo a un combobox se me ha ocurrido poner el espacio blanco como delimitador(podría ser el enter o cualqueir cosa que se ocurra y para los fines que sean, bien podrian ponerse mas cosas o validarlas para juntarlas etc, pero sólo me interesa el dividir las palabras) considerando tambien el inicio del procedimiento su fin y hasta el "next" del for como lineas de código, e incluso el "Dim" ya que hasta podría precindirse de él (pero las buenas practicas de programación ante todo), vemos que en pocas lineas de código (y sobre todo muy pocas palabras) se ha hecho algo interesante



otro ejemplo es el clásico:

Ahorra muchisimo trabajo (bueno en realidad sólo si lo comparamos con c++)




Saludos


pd.- Me ha encantado la iniciativa de los códigos
Me imagino tambien que alguien más experimentado en delphi, se las ingeniará para hacer lo mismo en la misma cantidad de lineas y de forma entendible

Hola

Con Delphi lo haría así:

Código Delphi [-]
  
procedure TForm1.BitBtn1Click(Sender: TObject);
begin
  REPEAT
    ComboBox1.Items.Add(Copy(Edit1.Text,1,Pos(' ',Edit1.Text)));
    Edit1.Text := Copy(Edit1.Text,Pos(' ',Edit1.Text)+1,Length(Edit1.Text));
  UNTIL Pos(' ',Edit1.Text) = 0;
  ComboBox1.Items.Add(Edit1.Text);
end;

Tal vez pudiera optimizarse, esto es lo que me permite mi dominio de Delphi.

Salud OS

bueno, obviemos entonces lo obvio y nos centramos en el código que importa, tu primer ejemplo en Delphi se resolvería mas o menos así:

Código Delphi [-]
begin
  Combobox1.Items.Delimiter := ' ';
  Combobox1.Items.CommaText := Memo1.Text;
end;

Además, se utiliza mejor el paradigma orientado a objetos con este código...

el segundo no lo entiendo bien (porque no conozco mucho de VB) pero imagino que sea el equivalente a:

Código Delphi [-]
 SetLength (nArrayDinamico, elementos);

Ya me diran si estoy diciendo una barrabasada como acostumbro..

Vaya, pues mira que tengo muy pobres conocimientos de Delphi :o, incluso pudieramos obviar el delimiter, no se si sea mi version (Delphi4) pero me da un error de identificador no declarado.

Código Delphi [-]
begin
  Combobox1.Items.CommaText := Memo1.Text;
end;

Salud OS

Tal vez en delphi 4 la propiedad tenía un nombre diferente, yo lo he hecho con Delphi 2007, pero afortunadamente el valor por defecto de esa propiedad es el espacio en blanco asi que es cierto, le podemos quitar una linea mas al procedimiento... ¿¿cuantas quedaron???... mi aritmetica ya no es lo que era en la primaria...

hola,

me pudieras ayudar en decirme como empiezo a crear un cubo de desicion con la ficha desicion cube para una base de datos..

Pues en realidad el código si es el que pusiste en un principio, incluyendo hasta la linea que le quitas ya que no especificamente el delimitador es el espacio blanco, y pues casi casi es un empate, con la unica diferencia que si se desea modificar la lista pues adicionalmente se tiene en su propia variable y no hay que copiarla de ningun lado (patadas de ahogado jajaja :D :p)

y el segundo ejemplo, si és el que mencionas, pero la aclaracion ahí mismo presentada es que en cuanto a delphi no hay ningun ahorro, sólo en cuanto a c++
__________________________________

Orale,.... genial la idea, sigan participando, hay que proponer más ejemplos, la idea es que aprendamos todos, supongo que falta hacer lo contrario delphi >>>> vb (es obio que vb va a perder jejeje:D, sobre todo con eso de la herencia jaquemate para un lado, como para el otro por la integracion con el estandar office y no se trata de eso) pero es divertido (hay que darle una muerte digna a VB jajaja)



saludos

¿Cómo harían el mismo ejemplo de ucanneo pero usando coma como separador en lugar de un espacio en blanco? Si usan CommaText, se van a llevar una sorpresa :)

Bye

Bueno, yo lo haría así:

Código Delphi [-]
  Memo1.Lines.StrictDelimiter := True;
  Memo1.Lines.Delimiter := ',';
  Memo1.Lines.CommaText := Edit1.Text;

¿cual es la sorpresa? :eek: :eek:

Hasta luego.

;)

Je, je. Está bien, cambio lo dicho: quienes usen delphi 7 o menor, se llevarán una sorpresa :)

Bye

Asi es, de hecho ya lo habia comentado y xander lo comentó. :)

Salud OS

¡Ah! Pues con mayor razón. Eso prueba que apenas a partir del BDS, Delphi empieza a llegarle a los talones a VB, y del delphi 4 mejor ni hablamos. :p :D (broma, broma, no se sulfuren).

Bye

:D:D:D, y si te dijera que es Delphi4 Standard :eek: no me creerias que lo use por muchos años sin necesitar mas

Todo depende el sector de tu negocio :)

Ahora uso Turbo Delphi y no necesito mas, por el momento...... :cool:

Salud OS

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


salud!

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 :D:D:D

Salud OS

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.

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).

¿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 :)

No, sería exactamente igual ya lo dije solo que no agregue el resto para hacerlo más genérico.

Y en cuanto a lo otro creo que idea era evaluar el lenguaje no los controles como tal, pero bueno creo que el equivalente de la propiedad OnChange del Delphi para el TextBox es Text.

Solo tengo una duda y es para que versión del Delphi es el código????, además que veo que el array de controles es genérico pero puede ser reinstanciado a un control como si fuera una matriz, mmm si es así creo que tendría que agregarle algo más al código que yo trascribí.

Editado

Creo que la primer instrucción sería así en VB

Suponiendo que hacemos uso "TEdit(Controls[i]).OnChange" y lo cambiamos por otro evento, estariamos entrando a cosas que VB no puede hacer (o al menos no tan facilmente), puesto que su orientacion a "eventos" no permitiria tal cosa, pero bueno por ahi dice la etiqueta de "Tag" en cualquier control de vb "Guarda datos adicionales para sus programas", hay quien dice que se hizo para este tipo de situaciones (ya me he topado con este problema en vb antes y sólo s me ha ocurrido solucionarlo así... sigo investigando no se me habia ocurrido ir más allá :p)


saludos

Para todas. En las versiones más recientes, añaden algún nuevo tipo, alguna nueva propiedad... pero por lo general, el código es compatible con versiones anteriores y posteriores. Es otra de las genialidades que tiene Delphi :)

Estas completamente seguro de que sirve en todas las versiones de Delphi, es muy aventado decirlo así tan sobradamente, yo me he visto con problemas de códigos que hechos en la versión 4 en la 6 toca prácticamente recodificarlos :eek::eek::eek::eek: aunque esto no aplica en todos los casos.

Un ejemplo sencillo de concatenación y conversión de datos

Hola
La verdad no se que es lo que se defiende?.
Los números, por lo menos en este debate son claros 94,44% Delphi 5,56% VB.
Que se defiende, Código, ventajas, desventajas.?
Yo creo que depende mucho del programador y del entusiasmo o conocimiento que tenga del lenguaje en especial.
Estoy convencido y nadie me va ha hacer cambiar de opinión en que VB es mucho mas complicado, exigente, tedioso, poco entendible y no se cuantas cosas mas que delphi.
No solo por mi experiencia en esto (autodidacta), si no por la experiencia de las personas que contrate y que programaban en VB, Profesionales ,(Pobrecillos).
Defender lo indefendible es absurdo.
No hay comparación Delphi le da una paliza a VB, por donde lo quieran ver, querer seguir en este debate no tiene lógica, para mi.
Siempre habrá quien quera nadar contra corriente, tarde o temprano lo veremos sacudido por esta, irremediablemente la corriente lo arrastrara, tiempo al tiempo.
Es como seguir con IE, cuando Firefox es mas rápido, efectivo, eficiente, etc, etc.
No he visto, objetivamente, una razón lógica y mucho menos técnica que demuestre que VB es un lenguaje que se acerque por lo menos un poco a Delphi, en esta vida hay que demostrar, no hablar, lo pueden hacer los que se afanan en defender lo indefendible?, lo dudo.
Si pueden hacer de un aprendiz un Novato, hablamos.:D
Saludos

Se que me van querer colgar quienes defiendan VB pero la verdad es que yo también no le veo el sentido a este debate... ¿Que se desea comparar? ¿Algoritmia? ¡Por dios!
¿Desde cuando se ha llegado al extremo de querer comparar un lenguaje por la capacidad de desarrollo de algoritmos?

En parte suena lógico el decir que, por ejemplo, si un determinado algoritmo en Delphi nos lleva 4 LDC y si en VB nos toma 6... entonces podríamos decir entonces que Delphi es 4/6 más eficiente que visual.

Si hay algo que conserva un algoritmo de un lenguaje a otro es su complejidad. Y ésta no depende de lenguaje alguno sino de la información necesaria para llevar a cabo su opración y los pasos lógicos (no de programación). Por ejemplo... implementar un algoritmo de Ordenación requiere complejidades del orden Cuadráticas (si usamos burbuja) ya sea en VB, C, C++, el que sea.... el algoritmo posee una expresión mínima.

La capacidad de abstracción y de escribir ese algoritmo en un lenguaja a otro dependerá en última de las habilidades del programador... pero las condiciones mínimas no variarán.

Si nos basamos en la teoria de Halstead, podríamos decir que un lenguaje es más ventajoso que otro dependiendo, debido a la abstracción y otros factores.

Lo que he descripto es un resumen de la toería de Halstead.

¿Cuál es el error aquí?
Pensar que las simples LDC son una medida de la verdadera eficiencia de un lenguaje.... amigos... si deseamos hacer una comparación justa y objetiva olvidemos condiciones subjetivas.

Los diversos estudios de Halstead han demostrado que si bien los lenguajes han evolucionado a la par del grado de abstracción, existe y existirá una fuerte correlación entre la expresión de una solución y la habilidad de programación.

Propongo que se evalue al lenguaje con la "habilidad técnica" que ofrece para expresar un problema.

Veamos, en Delphi, como buen lenguaje POO dividiríamos el problema en clases, las clases están en "módulos" (o mejor dicho units)... y esto nos lleva a expresar la complejidad en función de los módulos y clases.

Supongamos que tenemos k clases repartidas en n módulos. Podríamos decir que la complejidad del problema es de k/n. El problema ha sido repartido k veces a lo largo de los módulos... Entonces quedamos en que:

C = k/n

En visual basic podemos contar con esas pseudo-clases. y como sabemos... no son verdaderas representantes de la teoria POO... Estimativamente podríamos decir que en promedio k/2 clases están un un módulo de clases. (recordemos que las clases en VB no permiten la herencia, y es necesario repetir el código...) Podríamos decir que el resultado es:

C = k/2 + n/2

Teniendo esto en cuenta, yo me animaría a decir que conviene usar Delphi que Visual Basic....

Técnicamente hablando y suponiendo que empleamos lo mejor de cada lenguaje... es lógico pensar que Delphi es superior.

¿Que sentido tiene comparar LDC si al final la relación entre el esfuerzo en programar en cada lenguaje con sus capacidades técnicas es casi la misma?

De hecho... el esfuerzo por mantener el código en POO es cuadráticamente a k, mientras que en entornos como VB es a n.... Al final los resultados se tienden a "nivelar"... Más o menos el esfuerzo viene así:

E = d(k^2); para Delphi
E = d(n^2); para VB

La explicación es simple, minetras que en Delphi el esfuerzo se centra en las clases, en VB se centra en los módulos. Por lo general las clases tienden a aumentar más rápido que los módulos.

d es una constante de proporción que depende del lenguaje.

Ojo, no digo que el costo de desarrollar en VB sea el mismo que en Delphi. Sino que la ecuación E/C entre ambos tiende a ser la misma.

Si lo pudieramos ver gráficamente, el diseño de sistemas en VB sería a lo largo de n para S funcionalides, mientras que en Delphi para esas S funcionalidades tenemos k clases. Mientras uno se mueve verticalmente, otro lo hace horizontalmente.

No se si me explico.

Considero que debemos evaluar hacer un estricto debate entre Delphi y VB saquemos el factor humano de la ecuación y quedemonos con lo técnico. Si bien k y n dependen del valor subjetivo, la distribución de C y E se mantiene para cada uno con dichas fórmula.

¿A ver diganme ahora que lenguaje usarían? ¿Delphi o VB?

Debatamos ahora otro factor técnico... el factor reutilización. Mientras que en Delphi las clases tienen a ser más independientes unas a otras... en VB es más dificil conseguir esta independencia.

¿Punto a Delphi?;):rolleyes:
Hasta ahora si... al menos para mi.

Y si deseamos hacer una pequeña prueba de lo que dije... Aquí tengo una:

Se tiene una Clase (Módulo, en VB) X que está siendo usada en varios aplicativos que están en desarollo... En el sistema que te han encargado notas que que esta clase X (Módulo) tiene elementos que te son de mucha utilidad, pero que no obedecen totalmente a la interfaz o requisitos que tu tienes.
Pregunta: ¿Cómo harías en Delphi (Visual Basic) para conseguir implementar los añadidos sin que se vieran perjudicados los otros proyectos de modo que se aprovechen al máximo los beneficios de reutilización?

A ver... ahora si está lindo el debate... no se trata del algoritmia... sino de algo técnico. Espero respuestas.

Saludos,