Delphi baja puestos

[JXJ]

php se va a acabar por que no puedo compilarlo. para windows

--es broma. de que se acabe. pero sigo sin poder compilarlo.--

[kenkatana]

Ya vieron la posición de PowerBuilder??
Les aseguro que aun asi PowerBuilder (y RPG y otros) tiene para años

Daniel

[eudy.net]

Tal vez ya sea un poquito tarde para dar mi opinion. Pero como quiera la daré. Yo ya tengo casi un año programando en Delphi, y en tan poco tiempo he hecho varios proyectos (aunque sencillos, pero proyectos) y creo que con mis relativos escasos conocimientos sobre el tema puedo establecer que seria hasta un poco ingenuo pensar que Delphi (por mas comodo que sea) NUNCA oigase bien NUNCA se puede comparar con el Visual Studio de Microsoft claro hablando en programacion para Windows.

Y es que es bastante logico señor@s como Delphi va a superar a Microsoft en un sistema que creo el mismo Microsoft. El VS usa atajos que Delphi nunca conocerá. LoL como dice el dicho El corazon del ñame solo lo conoce el cuchillo. Y en este caso Microsoft le lleva la delantera.

Resumiendo lo que dije Microsoft da mas facilidades. Pero no comparto la opinion de que Delphi este decayendo.

Att. Eudy

[[eduarcol]]

Empezado por eudy.net

Tal vez ya sea un poquito tarde para dar mi opinion. Pero como quiera la daré. Yo ya tengo casi un año programando en Delphi, y en tan poco tiempo he hecho varios proyectos (aunque sencillos, pero proyectos) y creo que con mis relativos escasos conocimientos sobre el tema puedo establecer que seria hasta un poco ingenuo pensar que Delphi (por mas comodo que sea) NUNCA oigase bien NUNCA se puede comparar con el Visual Studio de Microsoft claro hablando en programacion para Windows.

Y es que es bastante logico señor@s como Delphi va a superar a Microsoft en un sistema que creo el mismo Microsoft. El VS usa atajos que Delphi nunca conocerá. LoL como dice el dicho El corazon del ñame solo lo conoce el cuchillo. Y en este caso Microsoft le lleva la delantera.

Resumiendo lo que dije Microsoft da mas facilidades. Pero no comparto la opinion de que Delphi este decayendo.

Att. Eudy

No te me voy a lanzar a la yugular como muchos lo haran pero eso que dices no tiene ningun tipo de basamento, cuales atajos son esos que mencionas??

[Ñuño Martínez]

Delphi morirá, como ya han hecho Fortran, COBOL y FORTH, que nadie los utiliza.

Hoy mismo acaba de llegarme un correo de Infojobs con trabajos. De las 40 ofertas, "sólo" 10 son de COBOL, 3 de Fortran, 11 de Delphi y (sorpresa) 1 de FORTH (la primera que he recibido en los dos años que llevo apuntado, no obstante). Estos lenguajes están muertos...

Nota: si no te salen las sumas, es porque una de las ofertas de Fortran también pide FORTH y varios de COBOL se codean con Java.

Vamos, que llevo oyendo lo de que "COBOL/Fortran tiene los días contados" desde ántes de que mi padre empezara a trabajar como agente de IBM, y de eso han pasado ya veinte años...

[REHome]

Empezado por Ñuño Martínez

Delphi morirá, como ya han hecho Fortran, COBOL y FORTH, que nadie los utiliza.

Hoy mismo acaba de llegarme un correo de Infojobs con trabajos. De las 40 ofertas, "sólo" 10 son de COBOL, 3 de Fortran, 11 de Delphi y (sorpresa) 1 de FORTH (la primera que he recibido en los dos años que llevo apuntado, no obstante). Estos lenguajes están muertos...

Nota: si no te salen las sumas, es porque una de las ofertas de Fortran también pide FORTH y varios de COBOL se codean con Java.

Vamos, que llevo oyendo lo de que "COBOL/Fortran tiene los días contados" desde ántes de que mi padre empezara a trabajar como agente de IBM, y de eso han pasado ya veinte años...

DElphi me da la impresión que morirá, después de una década, no morirá tan rápido y facilmente pero morirá. Ya tienen IDE del C#, el lenguaje que se está empezando a usar ahora.

[jhlsys]

Bueno conozco y he programado en Vbasic, Foxpro y Power Builder, solo les digo una cosa, bueno reto a alguno de ustedes que traten de hacer correr un programa hecho en power Builder, Foxpro Visual Basic hecho sus primeras versiones, a las versiones actuales, veran que se quedaran con los crespos hechos, ya que no lograran hacer nada, simplemente tendra que empezar desde el inicio. (Hice las pruebas personalmente para poder decirdirme por un lenguaje sin problemas de compatibilidad entre versiones)

Es mas hagan correr un programa hecho en Visual Basic 4, 5 o 6 ha VBasic Net que son mas cercanos y veran que no lograran nada, les aperece un dialogo haciendo la supuesta actualizacion, pero sorpresa, los benditos problemas de compatibilidad entre version, en donde tendra que intervenir y hechar mano a cambios en un 50 o 60% de codigo para qe corra, que preferiran empezar desde el inicion.

Sim embargo en Delphi o C++Builder no sucede eso, hice correr cada programa algunos hechos en delphi 1 y oto hechos en Delphi 2, a cada version que aparecia y no tuve ningun problema de compatibilidad, es mas ahora correr sin ningun problema en Borland Studio 2006, obviamente han crecido en productividad con cada novedad que aparece en cada version, haciendo uso de sus mecanismo de reutizacion en POO, que obviamente en este campo borland tiene muchas experiencia.

Por otro lado Net aun es un experimento, que ha tomado lo mejor de cada lenguaje productivo (Delphi, C++Builder y Java Sun), en pocas palabras su personalidad es prestada de otros lenguajes. Por si fuera poco algunas empresas de software reconocidas que apostaron a Net, volvieron a regresar su software a Win32, por algo sera?

En C++ Builder o Delphi logras hacer muchas cosas sin necesidad de aprender tantos lenguajes, tienes todo en un solo producto.

Por otro lado en mi comunidad cada vez son mas las personas que estan apostando al desarrollo en Delphi dejando sus lenguajes de programacion en los que solian programar (VBasic y Foxpro)

Recuerden, el hecho de que una empresa gaste millonarias sumas para hacer sus lenguajes populares, no significa que sean 100% productivos, en pocas palabras, el mas popular no siempre es el mejor.

[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

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

[jhlsys]

No se ustedes, pero en mi comunidad, muchos de los informaticos que solian programar en Visual basic o VFoxpro incluyendo las plataformas Net, han cambiando al entorno de Delphi por ser productivo, tener un IDe avanzado con todo lo necesario ypor que no tiene problemas de compatibilidad entre versiones y sobre todo por que hacen una variedad de cosas sin aprender tantos lenguajes..

Creo que ahi Delphi y C++Builder para Rato,

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