Ir al contenido


Foto

Lenguajes de programacion mas populares Indice Tiobe Octubre 2010


  • Por favor identifícate para responder
70 respuestas en este tema

#61 Delphius

Delphius

    Advanced Member

  • Administrador
  • 6.295 mensajes
  • LocationArgentina

Escrito 28 octubre 2010 - 02:01

Hola Marc,

[quote name="Marc" post="42433" timestamp="1288292220"]
Parece que nos van quedando menos puntos de fricción :).
[/quote]
Yo no estaría tan seguro  :D ¡que soy de cabeza bien cuadrada!  :p  :o

[quote author=Marc link=topic=4061.msg42433#msg42433 date=1288292220]
Evidentemente este cambio no se haría para ahorrarse unos kbs en el .dfm, es para simplificar y tener más coherencia en el entorno. Personalmente preferiría poder ver la inicialización del formulario en el mismo código Pascal en el que se escribe el resto del programa.
[/quote]
No me convence que eso sería coherente con el entorno. ¿Mejor lo dejamos como que esta característica sea opcional y configurable por el programador? Podríamos seguir y seguir con este punto... yo no voy a aflojar.

[quote author=Marc link=topic=4061.msg42433#msg42433 date=1288292220]
Por cierto, ¿ porqué dices que con muchos Forms sería confuso ?. Si heredo un Form en otros Forms hijos, se ejecutaría el OnCreate del padre y el OnCreate de los hijos, haciendo la correspondiente inicialización en cada caso, que es lo que se quiere. No me parece confuso.
[/quote]
Si bien apoyo la idea de que en lo posible hay que aplicar la herencia visual, no siempre es posible. Yo hablé en términos generales... tanto como se si deba heredar como crear tanta ventanas de una misma clase pero tienen algunas cosas diferentes de una a otra.
A mi me resultaría confuso.

[quote author=Marc link=topic=4061.msg42433#msg42433 date=1288292220]
Bueno, a mi utilizar esos nombres me parece muy intuitivo, pero si lo encontráis problemático se pueden cambiar por cualquier otro para que no coinciden con las palabras usadas en la declaración de clases.
[/quote]
Como he dicho, es un mal menor. Si se modifica al compilador para entender apropiadamente el contexto en donde se declara las clásulas public/private se puede emplear para ambas (y otras) cosas.

[quote author=Marc link=topic=4061.msg42433#msg42433 date=1288292220]
Respecto a donde ubicaría las clases, pues la inmensa mayoría deberían ir en la parte public, pero por simetría también podrías declarar clases en la sección private de la Unit, cuando tengas la necesidad especial de que solo sea accesible en ese módulo.
[/quote]
¿Y allí mismo la pondrías todo junto... declaración y código de sus métodos? Entonces yo entiendo que tu idea sería hacer a las secciones public y private opcionales, como lo son initialization y finalization.


[quote author=Marc link=topic=4061.msg42433#msg42433 date=1288292220]
Ya estaba escribiendo que te equivocas, cuando me he fijado que estaba escribiendo mal tu prueba  :(. No me había fijado que lo habías colgado debajo de implementation (supongo que cuando lo miraba, ni siquiera leía esa primera línea, daba por asumido que era la línea Unit).

Tienes razón, hay clases privadas (nunca se me había ocurrido declarar una clase en la sección de implementación).
[/quote]
¿Viste?  ;) Pues si... una gran mayoría de las clases se diseñan para ser públicas, pero nada impide, si el diseño lo amerita, que existan clases privadas.  :)

[quote author=Marc link=topic=4061.msg42433#msg42433 date=1288292220]
Aunque creo que este argumento ya no deberíamos tenerlo más en cuenta, puesto que hemos visto que es sencillo de solventar en una sintaxis unificada alternativa.
[/quote]
Aquí me pierdo  ^o| ¿A cuál argumento te refieres? ¿Que no deberíamos tener en cuenta? ¿Lo de clase privada y públicas? Ten presente que estamos tratando en 3 temas centrales, que están medianamente relacionados:
1. El tema de uso de .dfm vs concentrarlo todo en un Create
2. Separación Interface/Implementation vs Compactar y unificar: Código en la definición
3. Clases públicas y privadas: ¿Existen las privadas?

No comprendo a cual de esos temas te refieres.

[quote author=Marc link=topic=4061.msg42433#msg42433 date=1288292220]
Ahora entiendo por donde vas, y no, nunca he programado patrones (en mis tiempos la programación orientada a objetos aún no estaba en los planes de estudio).
[/quote]
Pues cuando cursé la cátedra de Lenguajes III y Lenguajes IV y ví la teoría de OO no tenía en el programa el tema de patrones. Incluso en cátedra de Ingeniería de Software cuando estudié UML tampoco tenía patrones en el programa.

Lo estudié por mi cuenta, como la gran mayoría de las cosas que he aprendido.  (h)  ;)

[quote author=Marc link=topic=4061.msg42433#msg42433 date=1288292220]
En definitiva estamos hablando de lo mismo que en el párrafo anterior.
[/quote]
Mitá y mitá diría yo  :p
Nos estamos confundiendo porque estamos apuntando a e temas un tanto relacionados... por ello yo al comienzo de cada párrafo intentaba dar pié y aclarando sobre el nuevo tema pero luego me hice bolas.  :p  :D

[quote author=Marc link=topic=4061.msg42433#msg42433 date=1288292220]
Es cuestión de gustos, a mi me parece más fácil de escribir y leer si solo tengo :



delphi
  1. TMiClase = class
  2. private
  3.   procedure Foo;
  4.   begin
  5.     // aqui el código
  6.   end;
  7. end;


[/quote]

Por eso yo ya me digo... ¿y si lo dejamos a opción de que el pogramador lo configure? Solución salomónica y nos evitamos seguir en la misma. Que venga el próximo debate.  :|

[quote author=Marc link=topic=4061.msg42433#msg42433 date=1288292220]
Lo veo más sencillo, y más fácil de aprender. Creo que la gente se animaría a programar más POO con esta sintaxis. Hay que pensar en el usuario novato.  La curva de aprendizaje en Delphi es demasiado pronunciada al principio. Recuerdo que mucha gente se asustaba al conocer el lenguaje, y optaba por soluciones con una curva mucho más suave como Visual Basic (con el que es un juguete empezar a hacer código útil), sin saber que todas esas facilidades iniciales las acabarían pagando con sangre más adelante (si lo sabré yo, que sufrí VB, por obligación de una empresa donde trabajé, durante cinco años para olvidar).

Admito que si miras el código fuente en bruto de cualquier clase con esta sintaxis, en seguida se vuelve intratable. Pero es que nunca tratamos (o deberíamos tratar) con el código en bruto, ni siquiera me acuerdo de la última vez que saqué un listado de código, siempre trabajamos dentro de un IDE. Y para cualquier IDE debería ser bien sencillo mostrar de una forma rápida las declaraciones. Ya sea con una política minimamente inteligente de colapsar las secciones con código, ya sea con una ventana adicional, del estilo del inspector de objetos, que en este caso sería un inspector de clases declaradas, etc. ...

Saludos.
[/quote]
Fácil y difícil son términos abstractos y cada quien lo mide con su propia regla. La sintaxis de Delphi es lo suficiente entendible y sencilla de asimilar. Para alguien que en su vida a programado puede que le cueste... pero si ha tenido formación con Pascal, e incluso me animo a decir con VB, le resultará bastante intuitivo de ambos modos pero le resultará extraño ver como dentro de una clase se está declarando código cuando en realidad está declarando un método.

El estándar exige que se definan los métodos y luego se los implemente. No veo el porqué debamos cambiarlo. ¿Funciona? Si...
Ahora si tu deseas que por cuestriones de IDE y de visualización se muestre de la forma que tu comentas eso es otra cosa.

Yo considero que esos cambios van más allá del IDE sino que afectarán la forma de trabajar, en el diseño del compilador, y habrá que cambiar demasiado. Si hay algo que me alegra mucho y que han sabido cuidar mucho en Borland, CodeGear y Embarcadero, es la compatibilidad hacia atrás y que las cosas se mantengan uniforme de una versión a otra. No como .NET que el cambio de una versión a otra hace tronar todo y resulta más incompatible que una pareja entre un ganzo y una yegua.

El problema de los componentes que dices, es el problema que llamo componentitis aguda. Eso, mi amigo, es ajeno a Delphi... ya es problema de terceros, de los creadores que no supieron como mantener el soporte de una versión a otra. Por ello se debería primar el uso de los componentes oficiales antes que los de terceros.
Aunque claro, no me opongo a la idea y la magnífica funcionalidad y todo un acierto que nos aporta Delphi de extender la VCL y añadir más componentes y bibliotecas.

El gran aciertto de Delphi es la gran portabilidad de una versión a otra. Ha decir verdad, la cirugía mayor y necesaria hoy en día es la de soporte multiplataforma. Lo que estamos discutiendo son nimiedades. No veo razón para seguir dándole más cuerda al asunto.

Lo nuestro ya roza los límites de querer que la herramienta se ajuste a nosotros y forzar a la herramienta a nuestros propios intereses.

Saludos,
  • 0

#62 luk2009

luk2009

    Advanced Member

  • Moderadores
  • PipPipPip
  • 2.040 mensajes
  • LocationSanto Domingo

Escrito 28 octubre 2010 - 06:20

La verdad que da gusto leerlos y    :shocked: la verdad es que no tenia idea que este tema lograria sacar tantas cosas buenas.
Sigan asi y espero que otros se animen a participar y asi aportar mas ideas interesantes.

Que bien (y)

  • 0

#63 Marc

Marc

    Advanced Member

  • Moderadores
  • PipPipPip
  • 1.484 mensajes
  • LocationMallorca

Escrito 29 octubre 2010 - 03:01


Evidentemente este cambio no se haría para ahorrarse unos kbs en el .dfm, es para simplificar y tener más coherencia en el entorno. Personalmente preferiría poder ver la inicialización del formulario en el mismo código Pascal en el que se escribe el resto del programa.

No me convence que eso sería coherente con el entorno. ¿Mejor lo dejamos como que esta característica sea opcional y configurable por el programador? Podríamos seguir y seguir con este punto... yo no voy a aflojar.


En un proyecto comunitario open-source, aquí se impondría un fork, y seguirían dos proyectos paralelos y relacionados : Delphi Classic y Delphi New Generation.

Pero como Embarcadero no querrá dividir sus esfuerzos y su comunidad, las cosas seguirán como están, y por eso solo nos traen mejoras del lenguaje en cuentagotas (como los recientes genéricos).

Aquí me pierdo  ^o| ¿A cuál argumento te refieres? ¿Que no deberíamos tener en cuenta? ¿Lo de clase privada y públicas? Ten presente que estamos tratando en 3 temas centrales, que están medianamente relacionados:
1. El tema de uso de .dfm vs concentrarlo todo en un Create
2. Separación Interface/Implementation vs Compactar y unificar: Código en la definición
3. Clases públicas y privadas: ¿Existen las privadas?


No, nunca he dudado de la posibilidad del punto 3), solo he pedido explicaciones por curiosidad personal, porqué nunca he declarado clases privadas ni recordaba haberlas visto y no sabía como se declaraban.

Lo que me refiero es que este punto 3) no puede ser un inconveniente para el punto 2), que es una de las modificaciones que he propuesto del lenguaje de Delphi. Haciendo unos retoques mínimos a mi primera propuesta inicial se ha dado cabida a que en los módulos se puedan declarar clases, variables y procedimientos públicos y privados.

Por eso yo ya me digo... ¿y si lo dejamos a opción de que el pogramador lo configure? Solución salomónica y nos evitamos seguir en la misma. Que venga el próximo debate.  :|


De nuevo se impondría un fork. Pero como de nuevo en lugar de ser un proyecto open-source comunitario, es un proyecto comercial de una empresa privada, se va a quedar como está.

El problema de los componentes que dices, es el problema que llamo componentitis aguda. Eso, mi amigo, es ajeno a Delphi... ya es problema de terceros, de los creadores que no supieron como mantener el soporte de una versión a otra. Por ello se debería primar el uso de los componentes oficiales antes que los de terceros.
Aunque claro, no me opongo a la idea y la magnífica funcionalidad y todo un acierto que nos aporta Delphi de extender la VCL y añadir más componentes y bibliotecas.


Demasiadas veces es simplemente inevitable. Delphi no tiene componentes para informes, en cada versión ha ido incorporando componentes de distintos fabricantes (QReports, Rave Reports, ...), las grids de Delphi son ridículamente pobres, no veo que hayan ganado ni una sola funcionalidad en los más de 10 años que llevo programando en Delphi, esto te obliga a utilizar cualquiera de las miles de Grids que han surgido para paliar esos defectos.  Hay componentes como los magníficos LayoutControls de DevExpress que simplemente no tienen ningún equivalente entre los componentes oficiales de Delphi. Y así podríamos seguir ...

El gran aciertto de Delphi es la gran portabilidad de una versión a otra. Ha decir verdad, la cirugía mayor y necesaria hoy en día es la de soporte multiplataforma. Lo que estamos discutiendo son nimiedades. No veo razón para seguir dándole más cuerda al asunto.


Cierto, si me dan a elegir entre que Embarcadero publique este año una nueva versión con las modificaciones propuestas, o con soporte multiplataforma, evidentemente escojo la versión multiplataforma.

Delphi necesita urgentemente una versión donde la VCL se base en un framework multiplataforma como QT. Y que por tanto permita la creación de ejecutables en toda la gran variedad de plataformas que soportan QT : Windows, Linux, Mac, Symbian, Windows Mobile, Maemo/Meego, etc. ...

Y es que este soporte multiplataforma no debe tan solo permitir escoger distintos S.O. de destino, sino también distintas arquitecturas de hardware. No veo la hora en que podamos programar con Delphi aplicaciones nativas para procesadores ARM bajo Windows Mobile, Android, iPhone, iPad, etc. ...

Por cierto, creo que esta exigencia de compatibilidad hacia atrás es la mayor diferencia que estamos teniendo. La compatibilidad hacia atrás está muy bien, pero la sacrificaría con gusto si es necesario para mejorar el lenguaje, es decir prefiero que evolucione el lenguaje a no que se mantenga una estricta compatibilidad hacia atrás para permitirme compilar con el último Delphi un código que escribí hace 20 años.

Después de todo, siempre tengo instaladas dos versiones de Delphi, Delphi 6 y Delphi 2010. Los nuevos productos los hemos portado a Delphi 2010, pero nuestro principal producto aún sigue desarrollándose en Delphi 6. Es un entorno que funciona perfectamente, y que por culpa de los componentes utilizados (básicamente FastReports 2.4 y QuantumGrid 3) es imposible portarlo a Delphi 2010 sin un esfuerzo enorme que difícilmente podemos asumir.

De la misma forma que tengo que vivir manteniendo varios entornos de desarrollo simultáneamente por culpa de los componentes usados, también podría vivir manteniendo distintos entornos por culpa de incompatibilidades del lenguaje.

Lo nuestro ya roza los límites de querer que la herramienta se ajuste a nosotros y forzar a la herramienta a nuestros propios intereses.


Esa es la idea. :)
  • 0

#64 Delphius

Delphius

    Advanced Member

  • Administrador
  • 6.295 mensajes
  • LocationArgentina

Escrito 29 octubre 2010 - 11:11

En un proyecto comunitario open-source, aquí se impondría un fork, y seguirían dos proyectos paralelos y relacionados : Delphi Classic y Delphi New Generation.

Naturalmente, es todo a base de supuestos... si esto estuviera en nuestras manos. Me gusta esos nombres.  :)

Pero como Embarcadero no querrá dividir sus esfuerzos y su comunidad, las cosas seguirán como están, y por eso solo nos traen mejoras del lenguaje en cuentagotas (como los recientes genéricos).

Bueno... prefiero que sea a cuenta gotas antes que nada. No creo que sigan como están, de una forma u otra deberá evolucionar... que sea a ritmo lento es otra cosa. Y eso ya es problema de algunas políticas y decisiones de algunas de las altas cabezas de Embarcadero.
El IDE y el lenguaje no tiene culpa.

Lo que me refiero es que este punto 3) no puede ser un inconveniente para el punto 2), que es una de las modificaciones que he propuesto del lenguaje de Delphi. Haciendo unos retoques mínimos a mi primera propuesta inicial se ha dado cabida a que en los módulos se puedan declarar clases, variables y procedimientos públicos y privados.

Quizá me esté equivocando al afirmar con demasía pero tengo entendido que desde siempre se ha podido declarar clases, variables, constantes, tipos, y procedimientos tanto privados como público.  ;)

Demasiadas veces es simplemente inevitable. Delphi no tiene componentes para informes, en cada versión ha ido incorporando componentes de distintos fabricantes (QReports, Rave Reports, ...),

En eso te doy la razón. No es una buena la jugada de que te hagan el cambiazo de un reporteador por otro. Es como si experimentaran para ver con cual se quedan.

las grids de Delphi son ridículamente pobres, no veo que hayan ganado ni una sola funcionalidad en los más de 10 años que llevo programando en Delphi, esto te obliga a utilizar cualquiera de las miles de Grids que han surgido para paliar esos defectos.  Hay componentes como los magníficos LayoutControls de DevExpress que simplemente no tienen ningún equivalente entre los componentes oficiales de Delphi. Y así podríamos seguir ...

Mucho de esto no podría opinar. No soy de probar componentes de terceros. Desconozco a todas esas suites. En los foros veo comentarios de varios componentes... por un lado me sorprende... el enorme abanico de posibilidades que ofrece Delphi para generar componentes da para mucho... por el otro me digo que tener demasiados componentes de terceros hace que uno dependa demasiado de herramientas externa y los problemas sean mayores.

Delphi necesita urgentemente una versión donde la VCL se base en un framework multiplataforma como QT. Y que por tanto permita la creación de ejecutables en toda la gran variedad de plataformas que soportan QT : Windows, Linux, Mac, Symbian, Windows Mobile, Maemo/Meego, etc. ...

Y es que este soporte multiplataforma no debe tan solo permitir escoger distintos S.O. de destino, sino también distintas arquitecturas de hardware. No veo la hora en que podamos programar con Delphi aplicaciones nativas para procesadores ARM bajo Windows Mobile, Android, iPhone, iPad, etc. ...

Pues si, es necesario. Hoy en día el mercado presiona en ese sentido. El problema es que Delphi nació en Windows y se especializó en Windows, mientras otros andaban buscando nacer y potenciarse en multiplataforma y multihardware.

Por cierto, creo que esta exigencia de compatibilidad hacia atrás es la mayor diferencia que estamos teniendo. La compatibilidad hacia atrás está muy bien, pero la sacrificaría con gusto si es necesario para mejorar el lenguaje, es decir prefiero que evolucione el lenguaje a no que se mantenga una estricta compatibilidad hacia atrás para permitirme compilar con el último Delphi un código que escribí hace 20 años.

Evidentemente mantener compatibilidad hacia atrás cuando más se avanza es más costosa de mantenerla. Es lo que da origen en parte a la reingeniería y se pierde la compatibilidad. Delphi ya tuvo un "quiebre" razonable: la llegada de Unicode.

El punto ahora es que el segundo quiere vendrá, necesariamente, con la llegada de multiplataforma. Lo que no me agrada es que vengan estos quiebres tan seguido. Por ello yo invito a un progreso razonable. No hace mucho que llegó unicode... ahora se está viendo multiplataforma. Su error es no haber iniciado más temprano el paso y haber hecho las cosas juntas: unicode + multiplataforma.

En algún momento se ha de sacrificar, no es mi intención impedir que no exista la compatibilidad y la evolución: es necesario avanzar... el punto es que el traspazo no se tan costoso. Y a mi me huele a que costará mucho.

Esa es la idea. :)

Pero no deberíamos llevarla al extremo. Porque la herramienta debe ser general y no en el interés de dos tipos. Se supone que el desarrollador debe irse adaptando y no que únicamente la herramienta se adapte. Es un feed-back bi-direccional. No lo veas como uni-direccional y que apunte hacia el desarrollador. Al menos ese es mi parecer.

Saludos,
  • 0

#65 IcebergDelphi

IcebergDelphi

    Advanced Member

  • Moderadores
  • PipPipPip
  • 176 mensajes
  • LocationVillaflores, Chiapas, Mexico

Escrito 29 octubre 2010 - 01:13

Vaya Escafandra,

Pensé que me darías unos tirones de orejas.  :D

Como dije: C puede ser muy potente... para el que se anime. No es muy recomendable para alguien que se inicia. Hay que tener mucha cabeza, ser muy cuidadoso. Eso es para gente que ya tiene una mejor comprensión y dominio.

Si yo repasara algo de punteros quizá algún momento me plantee la posibilidad de estudiarlo. Por allí se dice que C# pinta bien... aunque en lo posible quisiera evitarme algún producto que huela demasiado a Microsoft. En todo caso sería adecuado C++ y en caso de que lo aprendiera adecuadamente, hasta me animaría a probar suerte aportando y colaborando con Firebird o algún otro proyecto de código libre.

El punto es como dice escafandra es que el compilador/lenguaje demanda demasiado por el programador. Yo tengo la idea de que el programador debe centrarse más en otros aspectos, aunque también debe ser consciente de lo que sucede y hace el compilador. Eso no se lo puede pedir a alguien que apenas entiende lo que es un IF...

Tengo fe en que Delphi seguirá avanzando lo suficiente como para estar a la altura de las demandas actuales y futuras. Delphi seguirá siendo mi prioridad.

Saludos,


La bronca por aca en Mexico y mas en mi estado es que ni si quiera conocen Delphi, si buscas trabajo aca en Chiapas o sobre todo en la parte sureste de Mexico, todo mundo esta con Visual Basic o PHP, grandes ERP estan programados en esos lenguajes, y en las entrevistas de trabajo te piden esos lenguajes si no no entras, y en la parte central y norte de Mexico veo poco Delphi y mas Java, C# , VB.net y otros lenguajes que sabe Dios de que anfiteatro los sacaron como Centura GUPTA jejej,saludos.
  • 0

#66 IcebergDelphi

IcebergDelphi

    Advanced Member

  • Moderadores
  • PipPipPip
  • 176 mensajes
  • LocationVillaflores, Chiapas, Mexico

Escrito 29 octubre 2010 - 01:16

Cuando yo me metí a este asunto de la programación me enseñaron Ensamblador, Basic, Cobol, Pascal, Fortran, RPG y desde esa época me gustó Pascal por sobre los demás y por aquellos asuntos de la vida que no se puede uno explicar, comencé a trabajar con Turbo Pascal y de ahí hasta hoy no lo he abandonado.

Por supuesto he aprendido otros lenguajes y otras herramientas, pero programar con Delphi es lo que realmente me gusta hacer, creo que ahí está la principal diferencia entre un desarrollador Delphi y los desarrolladores de otras herramientas, que suelen ir por el lenguaje de moda y por supuesto monetario $$$$$$, pero que no echan raíces en ninguno.

Y como dice el comercial, programar por placer no tiene precio......... ;)

Salud OS


Estoy contigo Ego, todos se van por los lenguajes de Moda que al fin y al cabo vienen terminando en Programitas win32 o programitas para hacer agendas jejej,saludos.
  • 0

#67 IcebergDelphi

IcebergDelphi

    Advanced Member

  • Moderadores
  • PipPipPip
  • 176 mensajes
  • LocationVillaflores, Chiapas, Mexico

Escrito 06 noviembre 2010 - 11:05

Por cierto en la Lista Falto el Visual FoxPro 9.0 pense que ya no existia, veo que aun tiene fanaticos en el Mundo y hasta estan encontra de VS.net.
  • 0

#68 cram

cram

    Advanced Member

  • Miembro Platino
  • PipPipPip
  • 832 mensajes
  • LocationMisiones, Argentina

Escrito 20 mayo 2014 - 04:11

Si ya se que es viejo. Veo el aviso rosadito de arriba. Pero es un tema que debería actualizarse. Ya que Delphi está por desaparecer del TOP 20.
No digo que por descutir o charlar sobre el tema se levante, pero quizá sirva para evitar confusiones como las que se me vinieron a la cabeza en mi regreso a la programación luego de varios años. Y esto va más para aquellos que recién comienzan. Ahora gracias a DA, lo tengo claro: TIOBE solo indica cuantos preguntan por algo de lo que ven publicidad. Los programadores cuando se hacen expertos, dejan de preguntar.

Recientemente vi que un lenguaje llamado C Sharp suele ser conflictivo por parecer más moderno y ¿poderoso?. Pero no estoy de acuerdo. Viendo una clasificación de lenguajes de programación noté que Delphi es el último en su escala evolutiva, más allá de intentos como Oxygene, que personalmente me interesó por, creo, unas cinco a ocho horas netas. C Sharp tiene como mejora o evolución a Nemerle, que es un lenguaje que viene a limar sus asperezas, como aquellas citadas en cuanto a muchos caminos para hacer lo mismo, ser más legible y más compacto.

Para mí no tiene sentido comparar a C, con C Sharp, siendo que uno no tiene nada que ver con otro, más que en parte del nombre y similitud en la sintaxis. Por otra parte comparar a un lenguaje de alto nivel como C Sharp, Delphi con C p C++ que se entienden como de nivel medio (entre bajo y alto), no tiene sentido, es como exagerando para entender mejor: comparar Ensamblador con COBOL.
C es la base, con C se crean Sistemas Operativos y Controladores, etc. Y para aquellos a los que le gusta el dolor, también sistemas de gestión, por que todo le es posible.
Leí un 80% de este hilo, es interesante, solo me aburrió, las disculpas, aclaraciones, etc.
|-)
Hay muchas cosas que se omitieron y por esta razón intento reactivar este debate (ya que no es encuesta, ni noticia).
;)
1. Interface, Implementation son una forma clara de algo que existe en C++ y que es posible pero no obligatorio en C (Pido a Escafandra que me corrija si no es así). Ya que al igual que en Delphi, en C++ se enuncia la función y luego se escribe su implementación. La diferencia es que en C++ nada se hace fuera de una función, ya que el programa mismo es una, y Delphi adoptó a los objetos pero no es completamente orientado a objetos.

2. Que un lenguaje no cambie con el transcurso del tiempo, no significa que sea anticuado, sino que fue muy bien diseñado (demasiado diría). Hejslberg en ese entonces era muy joven e hizo un trabajo extraordinario que no fue hecho incluso cuando se pasó de C a C++ para permitir la inclusión de objetos. Y digo esto, porque la manera en que se declaran y usan es extraordinaria. C++ tiene ciertas dificultades para esto pues en ciertas ocaciones se usa el lado izquierdo y en otras el lado derecho de las expresiones para cuestiones análogas o del mismo nivel de compresión.

3. C Sharp utiliza las llaves al igual que C y C++, pero esto no lo hace igual que C o C++. Las llaves se cuentan cuando se hacen estadísticas sobre la densidad de los códigos como una ventaja sobre begin y end, pero al fin y al cabo, la manera en que las escriben en C Sharp, no tiene mucho sentido, pues alargan desesperantemente el código con espacios horribles, que los codificadores de C++ no, pues lo usan inmediatamente después de la definición de una función, o de un if, por ejemplo.

4. El hecho de no agregar el contenido de los .dfm en el código es algo simple y comprensible. Aquellos que piensan que esto sería buena idea, podría mostrarle un código en Turbo Pascal para Windows, seguro cambiará de opinión. Este es el mismo camino que los creadores visuales de bindings de XE3 en adelante para Firemonkey.

5. Un programador de Delphi, a veces o siempre, dedica su tiempo a la creación de base de datos, interfaz, etc. Comúnmente los programadores de C solo codifican y pueden leer los códigos incluso sin aclaraciones.

6. No es posible afirmar que Delphi sea igual de poderoso que C++, dado que de ser así, ya lo hubiera desplazado por su facilidad de comprensión. C++ permite entre otras cosas acceder a características que en Delphi no es posible. Por ejemplo, el uso de una variable de control declarada como register, que hace que la variable no sea ubicada en memoria sino en un registro de la CPU, acelerando su uso dramáticamente.

7. Considerar a C Sharp o Java mejor que Delphi no me cabe. Java y C Sharp son de código intermedio y Delphi compilado totalmente igual que C y C++ generan código nativo (aunque C no es cruzado). El día que C Sharp y Java prescindan de un entorno para tiempo de ejecución, quizá, pero ya no sería su naturaleza, ya que sus supuestas ventajas como garbage collector no tendrían mucha gracia. Además si los recolectores fuesen "lo más" ¿por qué C++ no implementa uno? R: porque cuando el prgramador dice es mejor. Yo diría que deberían comparar a C Sharp o Java con PHP, y aquí amigos, van de cabeza.

8. Los compiladores se dividen en dos partes fundamentales por un lado los analizadores de el código escrito por programadores para generar el bytecode o código intermedio (aquí termina C Sharp y Java) y por otra parte el generador de código objeto, que en el caso de Delphi permite más de una plataforma (O sea que es un compilador cruzado).

9. Hacer una encuesta por la preferencia entre C y Delphi, no tiene cabida, ya que de ser así, creo que Embarcadero hubiera adoptado solo a Delphi, ya que la mayoría de los desarrollos que se hacen en C y C++ son con herramientas de Microsoft.

El entorno de desarrollo de Delphi permite enlazar bases de datos sin importar preferencias gananciales, mientras que .NET solo permiten enlazar directamente a Oracle y SQL Server. Esto para mí es una desventaja para Visual Studio.
Basic y Cobol no son lenguajes para programadores, son lenguajes para no programadores o al menos así fue su origen. Lo digo de nuevo: BASIC y COBOL nacieron para no programadores. Los creadores de Visual Basic intentaron sin logro hacer de él un lenguaje serio (No se ni por qué se lo menciona).

Básicamente soplé unas brasas, espero que se encienda el fueguito y no haga mucho humo.
Digo esto, porque casi cree un nuevo hilo para este tema (aunque con título diferente)
Las opiniones de los colegas son muy valiosas.
Saludos.

  • 0

#69 escafandra

escafandra

    Advanced Member

  • Administrador
  • 4.107 mensajes
  • LocationMadrid - España

Escrito 20 mayo 2014 - 05:05

Sólo puedo decir que estoy de acuerdo con tus opiniones.  :)


Saludos.
  • 0

#70 IcebergDelphi

IcebergDelphi

    Advanced Member

  • Moderadores
  • PipPipPip
  • 176 mensajes
  • LocationVillaflores, Chiapas, Mexico

Escrito 20 mayo 2014 - 07:11

Antes que nada saludos cordiales amigos, ya tiene tiempo que no pasaba por aca, retomando el tema, encontre esta lista, no se si sea oficial pero es del 2013 al 2014:

http://www.comoprogr...e-programacion/

Ahorita el que va de subida es JavaScritp, ya ven que todo se esta enfocando a la web, etc

Saludos.
  • 0

#71 egostar

egostar

    missing my father, I love my mother.

  • Administrador
  • 14.446 mensajes
  • LocationMéxico

Escrito 20 mayo 2014 - 09:13

Ah que bien, aún estamos (delphi) por arriba de COBOL, Fortran y RPG :p

Saludos

[ot]Un gustazo verte por aquí estimado Hiber  (y)[/ot]
  • 0




IP.Board spam blocked by CleanTalk.