Delphi baja puestos

[REHome]

Si Delphi no muere, mejor que mejor.

En internet llevo un apr de añitos oyendo que se va y estarán otros por él. Bueno, espero que no se hunda.

En caso contrario volveré con los dos otra vez.

[JXJ]

Yo tambien soy testigo de que con delphi 2006 y 2007 win32
se pueden compilar programas. que se hicieron con delphi 1 y delphi 2
incluyendo los delphi 3,4,5,6,7,8,9

Por eso me gusta. el lenguaje pascal y su IDE.

[rolandoj]

Hola,

No sè si Delphi morirà; pero sì sè que ha disminuìdo su popularidad en mi zona. La ùnica universidad que lo incluìa en su plan de estudios ya no la hace y recientemente, una empresa de software con màs de 100 programadores no aceptò dar soporte a una de mis aplicaciones Delphi porque no encontraron a nadie capacitado.

Ahora bien, porque ha disminuìdo ?. Desde mi punto de vista el problema es que Delphi, aunque ha sido muy bueno en eso de la compatibilidad entre versiones, ha hecho un muy mal trabajo en cuanto a facilidades de migraciòn de versiones. Me explico mejor:

La orientaciòn de Delphi en cada versiòn ha sido a nuevos usuarios, descuidando totalmente, en cuanto a mejoras de teconologìas existentes, a sus usuarios màs viejos.

Para entender esto, piensen en lo que cada nueva versiòn de Delphi hace. Tìpicamente, deja en el aire la tecnologìa existente e impulsa una nueva. De esta forma, para justificar la inversiòn en una nueva versiòn, toca re-escribir grandes cantidades de còdigo bàsico, y ese costo no estàn dispuestos a asumirlo muchas empresas. Veamos un ejemplo: Cuando aparece Delphi 5, impulsan ADO y dejan estancado BDE; luego, en Delphi 6, sacan dbExpress, y lo demàs al olvido.

Para programadores nuevos a Delphi, o con relativamente poco còdigo desarrollado, eso no es problema; en particular, para los màs jovenes es hasta mejor porque estàn en la etapa de siempre buscar algo nuevo; pero, que pasa con los veteranos, los que ya tenìamos tanto còdigo desarrollado ?.

Que necesitabamos los que tenìamos mucho còdigo elaborado ?. Puès simplemente mejorar las tecnologìas que ya tenìamos. En el caso de BDE, el argumento bàsico para sacar dbExpress es el manejo de transacciones cortas, lo que es màs eficiente que el esquema BDE. En otras palabras, en lugar de crear dbExpress, lo que necesitabamos era que se cambiara
la base de BDE para optimizar esos aspectos. Por què no lo hicieron ? Por problemas tècnicos ciertamente que no, yo acabo de migrar de BDE a dbExpress y mi estrategia fuè simplemente crear componentes con los mismos nombres de los de BDE; pero descendiendo de los dbExpress, o sea, para el programador final, es bàsicamente la funcionalidad BDE; pero por debajo es la tecnologìa dbExpress. Sin ese truco de componentes, hubiera sido desastroso recodificar la aplicaciòn.

Y ese no es el ùnico ejemplo, podrìamos mencionar los casos de QuickReport, donde al final tuvieron que ceder, o que tal la falta de mejoras a controles visuales bàsicos. En fin, creo que la idea es clara.

Esos factores pesan en que muchos usuarios tradicionales de Delphi lo hayan venido abandonando, o por lo menos retrasando las actualizaciones.

En mi caso me he mantenido con Delphi 4 precisamente por eso; solo ahora actualicè una aplicaciòn a Delphi 2007, experiencia que considero muy triste, donde lo que he encontrado es una perdida de facilidades de programaciòn existente y unos errores que no me dan confiabilidad en el producto, por lo cual, a menos que me obliguen, pienso seguìr usando Delphi 4. (Nota: No sobra aclarar que tambièn he programado con las versiones 5, 6 y 7)

[[egostar]]

Amigo rolandoj, efectivamente, el problema que hemos tenido con Delphi es que no se ha enfocado bien en el mercado primario (Universidades), yo sostengo la teoria (cuestión que hemos platicado varias veces Al y yo) de que delphi debe de ser impartido en las universidades y siempre que tengo oportunidad comento el caso de éxito de CISCO, ellos tienen cautivos a la gran mayoria de profesionistas ya que es lo que les enseñan en las escuelas, por lo mismo y cuando tienen el "poder" de decisión siempre van a irse por esa tecnología.

Por otro lado, mi experiencia en la migración de mis sistemas de Delphi4 a Turbo Delphi, ha sido por demás simple, por una sencilla razón, uso principalmente componentes estandar y dos o tres componentes de terceros que no han tenido problema con las versiones de Delphi.

Lo que yo creo es que se abusa tanto de esos componentes de terceros que por esa razón es que las versiones pueden no ser compatibles.

Incluso, yo usaba Paradox y QReport en mis sistemas, ahora uso Firebird, QReport y Rave y he migrado 2 de mis sistemas con muy pocos "problemas" (y digo problemas entre comillas ya que mas que problema es desconocimiento de nuevas funcionalidades)

Salud OS.

[rolandoj]

Empezado por egostar

Amigo rolandoj, efectivamente, el problema que hemos tenido con Delphi es que no se ha enfocado bien en el mercado primario (Universidades), yo sostengo la teoria (cuestión que hemos platicado varias veces Al y yo) de que delphi debe de ser impartido en las universidades y siempre que tengo oportunidad comento el caso de éxito de CISCO, ellos tienen cautivos a la gran mayoria de profesionistas ya que es lo que les enseñan en las escuelas, por lo mismo y cuando tienen el "poder" de decisión siempre van a irse por esa tecnología.

Por otro lado, mi experiencia en la migración de mis sistemas de Delphi4 a Turbo Delphi, ha sido por demás simple, por una sencilla razón, uso principalmente componentes estandar y dos o tres componentes de terceros que no han tenido problema con las versiones de Delphi.

Lo que yo creo es que se abusa tanto de esos componentes de terceros que por esa razón es que las versiones pueden no ser compatibles.

Incluso, yo usaba Paradox y QReport en mis sistemas, ahora uso Firebird, QReport y Rave y he migrado 2 de mis sistemas con muy pocos "problemas" (y digo problemas entre comillas ya que mas que problema es desconocimiento de nuevas funcionalidades)

Salud OS.

Hola,

Puès sì, lo de las Universidades es clave. Yo formè parte de un muy pequeño grupo de profesores que introdujo Turbo Pascal 3.0 a los cursos universitarios a mediados de los 80s y los resultados obtenidos fueron excelentes. Desde aquella època me quedo claro la superioridad de la sintaxis Pascal para el desarrollo y mantenimiento de aplicaciones, y por supuesto, mucha gente de esa època saliò con esa idea. Yo dejè la docencia; pero en los 90s estuve un pequeño tiempo en la Universidad que impartìa Delphi en mi regiòn y quisè simular una empresa de software usando Delphi como lenguaje. Lo dejè porque no hubo compromiso de la universidad con el proyecto; pero es el tipo de cosas que se deberìan hacer.

De todas formas, como dije antes, creo que tambièn ha habido grandes errores por parte de Borland.

De hecho, recientemente vì en Internet un foro en Inglès donde se planteaba lo mismo y se manifestaban las quejas por parte de los viejos usuarios.

Lo que dices de usar un mìnimo nùmero de componentes de terceros es tambièn muy cierto; pero la culpa es màs bien de Borland; si hubiera dedicado mucho màs esfuerzo a mejorar sus componentes bàsicos, en lugar de introducir nuevas teconologìas, a menudo innecesarias, no habrìa que recurrir a componentes de terceros. Personalmente tampoco los uso frecuentemente, solo cuando es estrictamente necesario; pero entiendo a quienes lo hacen.

Por ejemplo, por que tener tantas alternativas para hacer lo mismo ?. Mira lo que pasa en dos apectos bàsicos, en impresiòn, Quick Report y Rave, para acceso a Bases de Datos BDE, ADO, IBX y dbExpress.

Peor aùn, su enfoque para hacer esto tiene otras debilidades. Tan solo mira lo que pasò con Bases de Datos, una funcionalidad crìtica en desarrollo de software:

Tornan obsoleto a BDE; pero su reemplazo propio, dbExpress, si bien supera un punto crìtico de rendimiento, desmejora mucho las facilidades brindadas por BDE. Es algo que no entiendo; mejorar està bien; pero no tiene sentido perder simultaneamente otros aspectos bàsicos; y, peor aùn si al mismo tiempo obligan a re-escribir el còdigo basado en BDE que se tiene. Incluso, lo màs asombroso es que despuès de varias versiones de Delphi con dbExpress no han podido (o no han querido) dotar a dbExpress de facilidades bàsicas, tales como una herramienta para administrar sus conexiones basadas en archivos .Ini como lo hace el BDE para administrar sus Alias(al punto que me ha tocado perder tiempo haciendo una)

Saludos

[mamcx]

Sinceramente no entiendo como dicen que Delphi es malo en cuanto a mantener la compatibilidad... si ese es precisamente uno de sus puntos fuertes.

Ademas, si incluso mantienen BDE hasta la version actual, y QuickReports lo incluyen.

Otro se queja de que hay muchos componentes "pa' lo mismo"... pues que eso sino soporte hacia atras? O mejor a lo MS... que quita del todo la posibilidad (como ej: ADO-ADO.NET).

Otro problema, y ese no lo arregla nadie, es programar sin pensar en el cambio:

http://dn.codegear.com/article/32388

[REHome]

Hola:

He dejado y he notado que Delphi no es lo que era en internet, veo que todos están con visual studio .net, en la empresa quetrabajaba, me decíanq ue me olvide de Delphi que ya no es lo que era y es una mierda. Que si pierdo el tiempo en algo que lo pierda en Java o Visual studio. net

Me he dado cuenta que la gente ya no le interesa tanto delphi como antes, en foros si, pero en lac alle, más bien habla de java, c/C++, visual basic pero Delphi, nadie le hace caso.

Vi en librerías que Delphi solo lo apolla Francisco Charte, un solo autor ahce algo de Delphi, solo uno.

El visual studio es muy nuevo y salía, salía y sigue saliendo muchos libros de todo tipo sobre visual studio, sobre todo el asp y el C#.

Menuda diferencia.

Por eso veo Delphi ya obsoleto.

Hasta en ese web que puse en el primer post lo deja claro. pero bueno.

Ya también se ha dicho que las empresas nuevas compren Visual Studio .NET, está por delante que Delphi y le sca mas provecho, y las empresas viejas, algún día harán el cambio.

[rolandoj]

Empezado por mamcx

Sinceramente no entiendo como dicen que Delphi es malo en cuanto a mantener la compatibilidad... si ese es precisamente uno de sus puntos fuertes.

Ademas, si incluso mantienen BDE hasta la version actual, y QuickReports lo incluyen.

Otro se queja de que hay muchos componentes "pa' lo mismo"... pues que eso sino soporte hacia atras? O mejor a lo MS... que quita del todo la posibilidad (como ej: ADO-ADO.NET).

Otro problema, y ese no lo arregla nadie, es programar sin pensar en el cambio:

http://dn.codegear.com/article/32388

Hola,

Es que se trata de conceptos diferentes.

Una cosa es que se pueda compilar un programa Delphi en una versiòn superior y otra cosa es que ese programa Delphi aproveche la versiòn superior (o sea, verdadera migraciòn).

Ciertamente, Delphi ha sido muy bueno en mantener compatibilidad; entendiendo por tal el poder compilar sin cambios, o con cambios mìnimos un programa de una versiòn anterior; pero al hacerlo, salvo una que otra excepciòn, simplemente estoy obteniendo el mismo programa que ya se tenìa, luego entonces, para que cambio de versiòn ?.

El problema, es que con el enfoque que ellos dieron, si se quiere justificar el cambio de versiòn toca re-codificar mucho. En el ejemplo que dì antes, lo lògico era que ellos re-escribieran el BDE para brindar las capacidades que incluyeron en dbExpress; asì el esfuerzo de cambio para el programador final serìa mìnimo.

En cuanto a lo que dices que me quejo de que hayas varias teconologìas de lo mismo y de que eso es soporte hacia atras, tienes razòn si lo miras desde la òptica de un Delphi 2007. Sin embargo, si lees con cuidado mi nota veràs que no era a eso a lo que me referìa. Lo que querìa decir es que nunca debieron haberse puesto a incluìr tantas variaciones de lo mismo; en su lugar, debieron mantener una sola base y simplemente mantenerse mejorandola; en otras palabras, lo que acabo de mencionar en el parrafo anterior. Màs claro aùn, estoy de acuerdo en que ahora toca mantenerlas todas, lo que estaba criticando es que considero una mala estrategia haberlas planteado porque al hacerlo se gastaron una cantidad de recursos que hubiera sido mucho mejor emplearlos en optimizar lo existente.

Sobre el problema de "programar sin pensar en el cambio" estoy totalmente de acuerdo, y soy de los defensores convencidos de la necesidad de programar para que las aplicaciones sean portables.

Por ejemplo, yo uso una metodologìa de portabilidad de Base de Datos, y en eso soy muy estricto, que me ha permitido cambiar de motor sin tener que cambiar programas, tan solo cambiando el Alias a nivel de BDE. Asì he pasado sin problemas, entre otros de Interbase a Oracle, y de Oracle a MS-SQL server. Otro ejemplo, tambièn uso otra metodologìa que me permite cambiar del modelo cliente servidor de dos capas convencional al modelo de conectividad Web, con un mìnimo de esfuerzo.

[mamcx]

Eso no serviria por la sencilla razon de que las cosas externas se mueven de forma impredecible, como es el caso de las librerias de acceso a datos.

Es muy diferente el modelo de acceso a datos de odbc-oledb por ejemplo... tanto que mezclar todo es un embrollo.

Ademas, es un error de diseño tener algo que "parece" igual pero funciona diferente. Eso introduciria bugs invisibles o problemas de desempeño que no serian previstos.... por ejemplo, el pasar de un acceso de archivos en paradox a un modelo desconectado en sql server.

Ahora, siguiendo la idea del articulo, intercambiar la libreria de acceso no es tan dificil... Renombrar clases, ajustar parametros... a lo sumo, con la documentacion necesario toma 1 dia... y hablo basado en experiencia, he usado todas las opciones del Delphi, mas las de VS desde la version 6, y foxpro, y python, y asp. Es realmente fastidioso escribir la mismas cosas de forma diferente pero teniendo una sola clase es un trabajo de carpinteria.

Mas dificil eso si son los controles visuales y el sistema de reporteo...

[rolandoj]

Empezado por mamcx

Eso no serviria por la sencilla razon de que las cosas externas se mueven de forma impredecible, como es el caso de las librerias de acceso a datos.

Es muy diferente el modelo de acceso a datos de odbc-oledb por ejemplo... tanto que mezclar todo es un embrollo.

Ademas, es un error de diseño tener algo que "parece" igual pero funciona diferente. Eso introduciria bugs invisibles o problemas de desempeño que no serian previstos.... por ejemplo, el pasar de un acceso de archivos en paradox a un modelo desconectado en sql server.

Ahora, siguiendo la idea del articulo, intercambiar la libreria de acceso no es tan dificil... Renombrar clases, ajustar parametros... a lo sumo, con la documentacion necesario toma 1 dia... y hablo basado en experiencia, he usado todas las opciones del Delphi, mas las de VS desde la version 6, y foxpro, y python, y asp. Es realmente fastidioso escribir la mismas cosas de forma diferente pero teniendo una sola clase es un trabajo de carpinteria.

Mas dificil eso si son los controles visuales y el sistema de reporteo...

Hola,

Respeto tú opinión; pero no la comparto.

Parte de la metodología de portabilidad es usar solo cosas standard. Con ello, a mí las cosas me han trabajado bien y rápido, y como dije antes, he pasado sin problemas entre diferentes motores, incluyendo versiones del mismo motor y drivers para el mismo motor. Los problemas de cambio se dan entre drivers, casi sin excepción, cuando se usan características que no son standard.

Ahora, disculpame la observación; pero creo que no te ha tocado desarrollar aplicaciones realmente extensas y/o complejas en código; o bien no te colocas en el caso de quienes usen metodologías diferentes a la tuya.

Dependiendo de la metodología hay diferentes necesidades y una cosa es emplear utilidades de reemplazo de cadenas de caracteres, y otra tener que, como obliga dbExpress sobre BDE en muchas de las metodologías usadas, recodificar segmentos completos.

En una aplicación que requiera fuertemente de cambios manuales, y que tenga centenares de formas, con docenas de miles de líneas de código, no es viable hacer el cambio en un tiempo remotamente cercano a un día. Si fuera así, esas aplicaciones tomarían menos de un mes, y todos sabemos que las aplicaciones realmente grandes toman usualmente más de un año.

Para ilustrar estos problemas, considera que dbExpress no soporta el filtrado, y piensa en lo que pasa al recodificar completa cada parte con eventos OnfilterRecord.

Te doy otro ejemplo, que además cubre lo del unidad que emula BDE.

Empiezo diciendo que, aunque hay algunas molestias (eso es otro tema); después de hacerla, cada aplicación me funciona bien practicamente con tan solo recompilar (podría incluso hacerse sin cambios si no fuera por un problema de diseño Delphi). Respecto que hacerlo así sea un "error de diseño", cada quién puede hacerse su propia opinión, por mi parte, y hablo por experiencia, estoy en total desacuerdo contigo. Lo de los problemas "invisibles" depende de que tan bien elaborado esté el código y de la metodología con que se trabaje.

Sus ventajas en rapidez y confiabilidad, dependiendo de la codificación, son enormes. El ejemplo es el caso del método Prepare. En TSQLQuery, no existe; su equivalente sería :

Prepared := True;

Por tanto, se podría decir "tan solo usa una utilidad de reemplazo de string"; pero que pasa si la aplicación tiene otras clases para las que se ha definido un método Prepare ?. Así tocaría realizar todos los cambios de esa índole uno a uno. En mi caso, tan solo creo un método Prepare con la línea Prepared := True;

Finalmente pensemos que una aplicación bien diseñada requiere tener módulos de datos lo más específicos posibles, así que en una realmente grande estamos hablando de docenas de ellos. Hay que ver lo que significa entonces revisarlos uno a uno. Y eso es solo lo correspondiente a módulos de datos.

Bueno, sobre todo eso hay mucho que se puede comentar; pero este hilo es para hablar lo que pasa con los problemas de Delphi en el mercado, y sobre eso creo que ya he expresado mis ideas

Saludos

[adfa76]

Creo que volvemos siempre a lo mismo en muchos temas.
Para mi lo mejor que tiene Microsoft es su sector de marketing, realmente hay que reconocerle que obran maravillas y son los responsables directos de poner a MS donde esta.
En cuanto a bondades de los productos ..... mmmm .... las hay pero .... como siempre ....
Cuando veo a alguien que programa en Visual Estudio de MS y queda maravillado porque ahora puede ver el contenido de una grilla conectada a datos en tiempo de diseño ... me pregunto a mi mismo: ¿cuanto hace que eso existen en Delphi? Mucho mucho tiempo verdad.
Y así con muchas otras cosas.
Como se dijo por ahí, lo más popular no siempre es lo mejor.
Esperad a que los chinos creen un lenguaje para lo que sea y vereis como llega al primer puesto instantaneamente.
¡¡¡¡Larga vida a Delphi!!!

[mamcx]

Empezado por rolandoj

O bien no te colocas en el caso de quienes usen metodologías diferentes a la tuya.

Puede ser. O mejor dicho, simplemente apunto a que hay maneras de disminuir significativamente los riesgos que eso plantea.

Un aspecto que es *crucial* es tener separado la logica de negocios del acceso a datos y tener una capa de ORM entre la logica y el acceso a datos. Si se mete codigo dentro de los TDataSet que no sea presentacional - o mejor dicho, no deberia existir nada de codigo alli - o si se hace SQL "clavado" en el codigo que no sea el minimo estandar, y cosas por el estilo, no hay de otra que rechequear todo. Eso es claro... y precisamente por eso fue que me puse a investigar. En el grupo de CodeGear oodesing aprendi un monton al respecto....

Empezado por rolandoj

En una aplicación que requiera fuertemente de cambios manuales, y que tenga centenares de formas, con docenas de miles de líneas de código, no es viable hacer el cambio en un tiempo remotamente cercano a un día.

Pues he ahi el problema. Es algo para pensar: PORQUE hay que hacer cambios manuales?

Es posible crear un soporte desde 0 a una aplicacion madura, con miles de lineas de codigo?

Pues si!. De hecho hace un mes hice exactamente eso.

http://code.djangoproject.com/ticket/5062

Le cree el soporte a django para Sql Server 2000/2005, haciendo varias emulaciones (como la implementacion de LIMIT/OFFSET que usa mysql), integre algo del codigo que habia por alli (las definiciones de tipos de datos) pero casi el 70% lo escribi yo. Luego vino otro tipo:

http://code.djangoproject.com/ticket/5246

y lo puso mas chulo. Tonces lo cogi y le hice otras mejoras.

En total, no me tomo mas de 15 horas de trabajo directo... y la mayoria fue mirar como era el asunto (no soy para nada experto en python. Me meti en el asunto porque vendi una tienda que necesitaba Sql Server y no habia programadores de django con experiencia en Sql Server).

Ahora la leccion no es que soy un super-programador, o que el cambio fue tan simple o que python es tan sencillo. La arquitectura del sistema permite este tipo de asuntos, y es porque esta desacoplado a todo nivel... lo que complica el diseño pero facilita los cambios. Y eso a pesar que todo el sistema estaba pensado para soportar mysql/postgree con sus propias idiosincracias que no trasladan o eran en opinion de algunos imposibles, a sql server.

Empezado por rolandoj

Respecto que hacerlo así sea un "error de diseño", cada quién puede hacerse su propia opinión, por mi parte, y hablo por experiencia, estoy en total desacuerdo contigo. Lo de los problemas "invisibles" depende de que tan bien elaborado esté el código y de la metodología con que se trabaje

Por lo que logro entender de tus aportes, no veo que haya un error de diseño ni estaba pensando que los tuvieras. Tenes BDE y lo vas adaptando a diversos entornos, y utilizas wrappers para ajustar las diferencias. No solo es una opcion adecuada, es la correcta.

El error seria por ejemplo, coger ADO.NET y "invisiblemente" hacerlo pasar como ADO. Eso no traslada. La arquitectura de BDE no traslada muy bien a la de dbexpress. Aunque quizas la de dbexpress se parece conceptualmente a ADO. En fin....


De todas maneras, lo que mencionas es un testimonio solido de las ventajas de Delphi y lo que se puede hacer si se activa la neurona . Eso es gracias en parte, a que a pesar de las gracias que hacen los productores de plataformas y los mismos de Borland en ir re-inventando ruedas ves tras vez, al menos no como el caso de MS, podemos seguir con la rueda "viejita" y darle una lustrada para que quede como nueva.

Mientras hayan programadores capaces que usen Delphi, y estos sigan expandiendo sus habilidades, no hay de que preocuparse!

[jhlsys]

Como se dice "El ser popular, no significa que seas el mejor", el hecho de que Delphi no sea tan popular en las universidades, o Institutos de informatica, es precisamente por que Borland no ha hecho un fuerte inversion en publicidad para sus productos, pero eso no significa que sea menos que otros, al contrario, es superior, tiene una experiencia muy rica en tecnologia con orientación a los objetos que muchos lenguajes envidiarian, sino, revisen la historia de Basic, quien a mudado de sintaxis y estructura, a tal punto que a tomado en su version Net lo mejor de otros lenguajes, es decir, es un lenguaje sin personalidad, y siempre se ha basado en su mayor parte detrás de cortina lenguaje C para salvarlo, hasta en sus Apis, sus DLL, nada es propio de el.

Por otro lado, Turbo Pascal o Turbo C, a evolucionado, tanto que muchos pensaba que desapareceria con la POO, sin embargo es algo que el ya poseía desde DOS, ahora imagínense estamos en otro siglo, y sin embargo sigue en el mercado, por que es uno de los lenguajes fuerte o denominado "Lenguaje todo terreno", pro que le entra a todo tipo de proyecto informático, por eso aposte por este lenguaje, comparándolo entre otros haciendo software.

De una comparación que hice entre rendimiento, robustes, mantenimiento, actualización entre versiones, explotación en POO, y actualización de win32 a la plataforma NEt, Con Delphi no tuve ningun problema ni muchos con C++ Builder, lo que si tuve con los otros productos. y sobre todo por su tecnología de plataforma cruzada para Interbase.

Ojo la reutilizacion de ADO en Delphi es superior a la del fabricante. sin necesidad de hacer artificios.

y las aplicaciones para PDA, WAB, o aplicaciones Para internet, se hacen con mucha facilidad con Intraweb que viene en Delphi, donde para hacer estas cosas, no necesitas aprender otro lenguaje por separado. Son tantas bondades que ofrece el producto que quedaríamos muy cortos mencionándolas.

Solo puedo decir, Delphi y C++ Builder o Java en cualquiera de sus versiones, sin ser talvez los más populares, son los mejores lenguajes que existen en el medio informático, lo digo con el criterio de haberlo comparado con otros lenguajes probándolos en el desarrollo de sistemas y probando su productividad.

Solo les digo una cosa, para tener criterio de comparación primero hay que investigar entre varios lenguajes, comparar haciendo software en la mayoría de ellos para poder dar opinión, y no enfrascarse en uno solo o dejarse llevar por la publicidad o apasionamientos adsurdos, hay que probarlo personalmente y sacar conclusiones, se los digo por eso es lo que hice, no me dejo llevar los que dicen otros solo de la boca para afuera, hay que convencerse por uno haciendo haciendo pruebas de fuego y luego ver resultados.

En mi humilde opinion, tenemos Delphi, C++ o Jbuilder para rato...y el que diga que no, es que solo sabe diseñar, pero no programar, en donde se ve el poder de los lenguajes en toda su magnitud y obviamente la destreza del verdadero programador.

[[ArdiIIa]]

Empezado por jhlsys

En mi humilde opinion, tenemos Delphi, C++ o Jbuilder para rato...y el que diga que no, es que solo sabe diseñar, pero no programar, en donde se ve el poder de los lenguajes en toda su magnitud y obviamente la destreza del verdadero programador.

Excelente exposición.

[Casimiro Notevi]

Empezado por ArdiIIa

Excelente exposición.

Totalmente de acuerdo

[xander]

aguas

[[enecumene]]

Hola, No se, pero para mi los IDEs de Microsoft son una especie de "copias" de Delphi, originalmente programaba Visual basic y me de daba brega hacer algo sencillo que en delphi lo he podido hacer sin problemas alguno, en mi opinion en cuanto a potencia y rapidez en programacion y accesos de bases de datos DELPHI esta muy por ENCIMA de MS, soy testigo de eso, que Delphi va a morir? eso lo dudo, los softwares de MS les llegara su momento mas rapido que delphi, digo eso es solo mi opnion.

Saludos.

[jhlsys]

Solo puedo decir, Delphi y C++ Builder o Java en cualquiera de sus versiones, sin ser talvez los más populares, son los mejores lenguajes que existen en el medio informático con personalidad propia, lo digo con el criterio de haberlo comparado con otros lenguajes probándolos en el desarrollo de sistemas y probando su productividad.

Solo les digo una cosa, para tener criterio de comparación entre lenguajes de programacion, primero hay que investigar entre varios, comparar haciendo software y haciendo pruebas de fuega a los mismo en la mayoría de ellos para poder dar opinión, y no enfrascarse en uno solo o dejarse llevar por la publicidad o apasionamientos adsurdos, hay que probarlo personalmente y sacar conclusiones, se los digo por eso es lo que hice, no me dejo llevar los que dicen otros solo de la boca para afuera, hay que convencerse por uno haciendo haciendo pruebas de fuego y luego ver resultados.

En mi humilde opinion, tenemos Delphi, C++ o Jbuilder para rato...y el que diga que no, es que solo sabe diseñar, pero no programar, en donde se ve el poder de los lenguajes en toda su magnitud y obviamente la destreza del verdadero programador.

[acertij022]

yo me inicie programando en Delphi y me gustaría seguir con Delphi , pero la realidad, el marketing y la necesidad mandan. En la empresa en la cual trabajo teniamos los productos realizados en Delphi, pero con la llegada de Windows Vista tubismo que frenar todo y trasladarnos al futuro para ver que combenia a la empresa dejando nuestros corazoncitos aun costado, llamamos a las 2 empresas Code Gears que nos presentaba Delphi 2007 y a Microsoft cada uno expuso lo suyo y lamentablemente gano Microsoft ya que nos ofrecia VS Team que incorpora muchas herramientas en el mismo IDE por el mismo precios y como mencionaron arriba ante una nueva tecnología que ofresca Microsoft siempre la 1º herramienta sera de Microsoft y en los negocios aveces se da que es mejor ser los 1º en el mercado para acaparar todo lo posible ante de tener un producto de calidad.

Yo no soy ningún experto solo trato de reflejar las cosas que me han tocado vivir.
Saludos a todos!!

[nuk3zito]

Delphi "morirá" hasta que Borland decida venderlo a Microsoft...
Así que cuando vean un producto nuevo llamado "Visual Pascal Studio with .NET Framework", ese día sabrán que Delphi ha muerto.

Así que... No os preocupéis!!!