Delphi .Net o Visual Studio .Net
 

Siempre hemos trabajado con Delphi, muchos de nuestros procesos están basados en Delphi y yo estoy feliz de que así sea.

En estos días, tenemos la posibilidad de migrar hacia una nueva versión uno de nuestros sistemas más importantes. Yo soy de la idea de seguir con Delphi, pero mi jefecito está maravillado con todo lo que Microsoft dice sobre Visual Studio .Net y está muy convencido de que debemos dejar de utilizar Delphi y migrar todo a Visual .Net

No se que tanta diferencia tenga el .Net de ms y el .Net de borland y esa es la intensión de este tema. Me gustaría tener más conocimiento o más herramientas para tratar de seguir trabajando con Delphi.

¿que tiene VS.Net que no tenga Delphi.Net?

Hola,

La diferencia es el lenguaje. Visual Studio, sin "plugins", permite desarrollar aplicaciones para la plataforma .NET utilizando C++, C# y Visual Basic, si no me equivoco. Delphi .NET presenta Object Pascal para crear aplicaciones para la plataforma .NET. Por lo demás, en ambos casos se hará uso de los mismos servicios, clases, componentes, y recursos de todo tipo que proporciona la plataforma .NET.

PD. Si no me equivoco con el IDE para .NET de Delphi también es posible usar C#. Lo contrario, sin embargo, sigue siendo cierto: sin "plugins" (que habría que mirar, hace poco se habló en estos foros de "Oxygene") Visual Studio no soporta Object Pascal.

Hola amigo [Contra] tienes mucho trabajo por delante si quieres cambiar la idea del "jefe", ve ésta página donde hay una comparativa entre Delphi y C#, yo me quedo con esta frase del autor

Solo te puedo decir que C# no es tan difícil, pero no te da el mismo control que Delphi, tal vez porque no lo he sabido usar al 100%.

Salud OS

También está el tema de las versiones de .Net; Creo que las últimas versiones de Delphi soportan .Net 2.0, mientras que las últimas versiones de VS incoporan soporte para... ¡.Net 3.5!.

Mal que nos pese a los amantes de Delphi, en tema de .Net siempre estará (nunca mejor dicho) varios "puntos" por detras de la criatura de Guillermo Puertas. De hecho, parece que Delphi 2007 para Win32 (y recalco Win32) está bastante bien, pero no se comenta nada sobre "Net".

Un saludo

Entre tantas ideas que trata cumplir .Net es que un grupo de programadores puedan desarrollar una aplicación sin importar si la hacen en VB.Net, C#, C++.Net o cualquier otro lenguaje que tenga su adaptación a .Net (Por ejemplo Delphi), de tal forma que una aplicación podrá tener un formulario programado en C#, otro en C++.Net otro y otro y otro en lo que sea.Net, se supone que no se verá afectado la velocidad entre programar con uno u otro lenguaje ya que usted siempre programa para el frameworck (Cualquier parecido con Java es pura cop... casualidad).... es multiplataforma, es decir corre muy bien entre Windows Vista y Windows XP... ahí cubre a cabalidad dos SO (que mas puede querer una persona normal y sensata)... ya si quiere trabajar con Windows 98 (pero quien va a querer usar eso.... eso es un dinosaurio) tendrá algunos problemitas menores... cosas prescindibles, es más, si tienes depronto un usuario con windows 95 (aun quedan de eso... pago por ver) .Net tiene la mejor y mas grandiosa solución... un emulador de pocket Pc (aaaahhh... no creen que es grandioso... MS son geniales).... además... si quieres mirar para el mundo del pingüino, pues por ahí hay unos mechudos que esperan pacientemente a que tengan una versión (o de pronto dos) más adelante para sacar una cosa muy particular llamada mono la cual afirma poder trabajar con .Net en Linux, eso si no esperes que estén a la par con el .Net, es decir, si el FrameWorck va en la versión 4, lo mas probable y por un tiempo algo así de uno o dos años el mono será medianamente compatible con la versión 3... y cuando por fin tengas el mono en la versión 4, pues lo mas seguro es que .Net estará en una versión 5 (muy probablemente incompatible con la versión 4 en un 30 o 40%, y no es que la versión 5 sea un 30 o 40% má innovadora, es que no soporta hacia atrás un 30 o 40% de comandos anteriormente existentes)....

Temo decirte que Delphi si soporta .NET 3.0, y que se exija que Delphi este a la par de MS pues es mas que imposible como ya se ha hablado hasta el cansancio, jamas puedes suponer que una empresa libere su tecnologia para que la competencia este a la par que ella; ni siquiera nos limitemos a hablar de MS.

Salud OS

Otro de los comentario fue: "si quieres te mando a un curso de una semana, ya para que puedas hacer todo en vs.net"... me quedé sorprendido de el hecho de que la curva de aprendizaje para C picudo (C# pues) sea de una semana :eek:

¿Con un curso de una semana puedo empezar a desarrollar sistemas complejos? ¿cuál es la curva de aprendizaje del .Net?

Yo creo que más bien conocen tus capacidades y por eso te estimulan (presionan) así...

Esta más que claro que en una semana aprenderás cosas básicas, pero algo es algo..

Salu2:p:D

Te voy a dar mi experiencia con C#....

Un buen dia, mi jefe me dijo que necesitaba un módulo pero que era indispensable hacerlo con C#, pues yo no sabia nada de C#, es mas ni de C++, pues me costo 3 semanas aprenderlo y no fui a tomar un curso fue autodidacta, asi que no creo que tengas problemas para aprender a usarlo ya traes buen nivel el Delphi, asi que lo demas pues es cosa juzgada :D:D:D.

Salud OS

Edito: Y necesitaba usar WebServices que ni los conocia :)

¿En RAD studio 2007 se puede programar en C#?

Bueno no he usado delphi para .net, pero si visual studio .net, es toda una tecnología bastante buena en mi humilde opinion, posee diversos componentes que te simplifican la vida, te permite ordenar bien tu codigo, ya que hay diferentes tipos de archivos y carpetas para cada cosa, tiene mejoras en ado.net (ejemplo system.data.common y más), tipos genéricos, que me ha sido muy util, el que estoy probando actualmente es el 2008, que tiene analizador de codigos, plantillas para planes de prueba, y otras herramientas muy utiles, y se le puede adaptar el sourcesafe del 2005 (para trabajar en equipos), ya que para el 2008 todavia no ha salido, o no estoy enterado.

Tiene muchas más cosas

Lo malo que le he visto, es que para cualquier cosa que haga y quiera distribuir, tengo que poner el bendito framework, si hago un activex y lo coloco en una determinada pc (tengo que instalar el framework).

La migracion del 2003 a 2005 es pésima.

Dicen que es portable a cualquier plataforma, pero se olvidaron de poner plataforma microsoft.

... posterior a windows XP

había pensado en poner una encuensta .net delphi vs .net vs... pero en un foro de delphi, seguro gana la versión de delphi y si la pongo en un foro de visual studio seguro gana la visual studio.

Me pregunto: en un foro de Visual studio, ¿cuantos van a conocer la versión de delphi?

Al menos aquí se que la gente que apoya al visual studio, conoce delphi.

Desde mi muy novato y particular punto de vista, no existe punto de comparación entre delphi 5 y su similar VB 6. Delphi 5 es mucho más poderoso. Si siguiera ese ejemplo, me podría hacer a la idea de que la versión de Delphi para .net es más dinámica y potente que la versión del visual studio.

Aunque claro esta que según se, VS.net lo hacen los mismo que hacen el framework.

En fin, espero encontrar motivos suficientes para utilizar Delphi (.Net en caso de ser necesario) en lugar de visual studio.

solo para confirmar:

¿hay algo que Delphi .Net no pueda hacer que Visual Studio .Net sí? (ambos trabajando sobre el framework 3.0)

Hola

Si quiere seguir programando en Object Pascal y poder reutilizar tu código en .Net 3.5 entonces puedes adquirir Oxygene de RemObjects el cual se le instala al VisualStudio y colorin colorado estas programando en ObjectPascal con Visual Studio.

El .Net 3.0 no trae nada importante tan es así que inmediatamente saco M$ la version 3.5 que trae LINQ y Silverlight y no se que otras cosas mas.

El dichoso Framework de M$ ya esta instalado en los Vistas y muchos producto incluyendo RAD Studio requiere que el Framework este instalado.

Te agrego el link de Oxygene para que hagas tu propia investigación lo puedes bajar para probar.

http://www.remobjects.com/product/?id={DC0A9947-5FED-4D34-8CC8-F2DCFA87A1FE}

Saludos
Ramiro

¡Hola a todos!

Carlos, escucha (lee) bien esto. Este sería el peor momento para que una empresa o persona que lleva años desarrollando con Delphi abandone el lenguaje de programación por otras alternativas.

Vaya, caramba, si no lo hicieron en los últimos dos años, cuando CodeGear carecía de respaldo real por parte de una Borland desvirtuada, menos ahora que el lenguaje ha sido adoptado por una empresa más hecha y vigorosa como Embarcadero y su padre TCB.

Vamos, que lo que hay que hacer en estos momentos (y eso lo recomendé esta mañana a uno de los principales clientes de CodeGear en México) es esperar cuando menos a enero para darle tiempo a Embarcadero y CodeGear de empatar y mejorar sus esquemas de trabajo a favor de Delphi y otros de sus productos.

Nadie abandona un barco porque ha hecho algo de agua durante una supertormenta que hubiera despedazado a cualquier otro, cuando ya ha salido el Sol y nueva tripulación se está haciendo cargo de las averías.

Dejar Delphi antes de ver cuál fue el resultado de la función Embarcadero, es simplemente azaroso y nada inteligente.

Un abrazo sin chatarra publicitaria.

Al González. :)

Cosas que no deberias hacer NUNCA

Mas conocido como "el error estrategico numero 1 de los desarrolladores"

http://www.joelonsoftware.com/articl...000000069.html

Mira, he ayudado a VARIAS empresas de software a subirse al vagon de .NET. Les advierto, les suplico y les vuelvo a suplicar que miren otras alternativas, pero tercos que son... asi que trato de hacer que tengan el paseo menos doloroso posible. Pero nunca es los suficientemente indoloro.


Como concepto, .NET es una idea genial... el framework en si es muy potente, elegante y todo. Precisamente por eso es un dolor de cabeza para la mayoria de los desarrolladores que he conocido (quizas los de Delphi estan en mejor posicion, quizas por tener el mismo padre?).

Tu jefe obviamente no tiene idea de lo que dice. Y piensa hacer el experimento con la aplicacion que lleva muchos años-codigo de depuracion y codificacion?

La mejor manera es hacer un desarrollo nuevo y pequeño. COntratar un par de "expertos" de .NET de esos que abundan y le puedo apostar lo que quiera al que sea, de cualquier empresa, que ni en 6 meses estan cerca de abosolutamente nada - o sea, en cuanto igualar sus desarrollos actuales-.

Algunas cosas que son convierten en grandes bloqueos:

- Con todo el respeto que se merece, .NET esta enfocado a departamentos de IT de empresas medianas y grandes. No para desarrolladores "INDIE" ni independiente ni ISV ni micro-ISV ni videojugadores ni nada. Que se puede usar eso si, pero no es el mercado importante. Una mirada a download.com corrobora eso (que es una de las mas grandes paginas de aplicaciones de empresas que no son IT de empresas medianas y grandes)

Eso trae consecuencias "ocultas" pero importantes. Un equipo pequeño con .NET a pelo es obligadamente menos eficiente que uno que use Delphi para aplicaciones de windows y utilerias, C++/Delphi/Lua/Python para juegos, PHHP/Python/Ruby para web, etc. Por la razon que esos otros entornos estan realmente enfocados a los equipos pequeños y agiles.. y tienen una infraestructura mas completa de despliegue


- Winforms es muy lento, y se supone que esta obsoleto hacer 4 años. WPF es una cosa IMPRESIONANTE .... pero nadie puede usuarlo. No hay tooling, no hay controles, el mercado de terceros es muy pobre, es muy bueno para hacer multimedia pero no mucho para aplicaciones de negocios.

- A menos que se quiera hacer una interface Win95 los controles GUI de Winforms no dan la talla ni a palos. Hay que usar controles de terceros, que practicamente sin excepcion son de pago.

No recomiendo hacer aplicaciones de negocios en .NET sin usar www.devexpress.com o www.infragistics.com. Fallar en este punto aumenta varios meses el desarrollo. Fijo.

- El sistema de reportes nativo de .NET es muy pobre, a menos que se use SQl Server Reporting Services.

OBLIGATORIAMENTE hay que usar un reporteador de terceros y para .NET hay pocos

- La programacion de BD es tan potente que no he visto quien no tenga problemas importantes. Esta hecha para un mundo (la web y n-tier) que no es el punto fuerte de las aplicaciones que la mayoria hacen (que a duras penas es 2-tier con pretenciones de 3-tier).

LINQ y los tipos anonimos y todo eso es muy bonito pero es un nivel mas arriba de la OOP y por experiencia pocos dominan la OOP, menos le dan a las programaciones dinamicas. Solo veo a alguien que use Fox, Dbase, Smaltalk, Ruby o Python que veo masomenos intuitivo lo que trae .NET al respecto.

Solo hay un OPF de facil uso y gratis, y sin embargo a muchos les falla el "chip" que entiende que es mejor escribir 3 lineas de codigo dinamico que 40 de codigo clavado.

- Es mas dificil desplegar .NET. Mucho mas si se depende de WPF u otras tecnologias mas "modernas"

- La enorme magnitud de .NET impide que alguien sea medianamente bueno en .NET. Solo es posible la especializacion. En comparacion, frameworks grandes y potentes como la VCL o las librerias de Python o Visual FoxPro, que por experiencia no son nada "pequeñas" se pueden dominar con los años. Eso es imposible con .NET o Java.

- Lo que en legnuajes mas especializados toma poco codigo en .NET normalmente requiere mas plomeria. Existen casos especiales, por ejemplo los tipos anonimos, la delegacion, lINQ y demas hacen muy facil hacer un OPF que en Delphi (pero no tanto como en python o ruby) pero la experiencia total seguramente parece mas frustrante

- De todas las empresas que han hecho migraciones en mi ciudad (conozco el caso de por lo menos unas 10, 5 de las cuales son las mas "grandes") NI UNA SOLA ha sido exitosa. Se de esfuerzos muy grandes, en mi caso creo que fui el primero en iniciar algo de envergadura y desde que sali, nadie a podido continuar - lo han intentado, no miento, unos 7 desarrolladores -. Eso fue hace 5 años.

Todos los demas tienen partes, pero no sistemas completos.

Y las versiones que siguen vendiendo? La misma hecha en Fox, Cobol, Delphi o lo que sea.

--------------------
En total:

- .NET a igual que cualquier cosas sirve para hacer cosas simples.
- .NET esta OK para hacer sitios Web. Pero quizas PHP o mejor aun, Python o Ruby es mas productivo
- .NET esta OK si hay un equipo de desarrollo de mas de 5>. Menos de 5 es muy poquito, y en todo caso deben estar equilibrados en capacitacion
- .NET , al igual que CUALQUIER cosa incluido assembler, esta OK para iniciar algo nuevo.
- Al menos uno del equipo debe ser o muy bueno en .NET o tener el "chip" Delphi y/o el chip FoxPro y ser muy adaptable, no temer buscar mucho en google, y querer aprender muchos paradigmas de desarrollo en paralelo
- Es un error fatal reescribir una aplicacion y deberia dar pena eterna reescribirla en otro lenguaje, se cual sea, excepto SI:

--- Es masoquista
--- El lenguaje anterior esta mas abajo en la cadena de productividad (ej: de assembler a c, de c a pascal)
--- Ya averiguo y sabe que usar para los reportes, el instalador, los controles, la conectividad, etc... el rango full de todo lo que va a necesitar
--- Le pagan. Como a mi. Por eso yo si puedo hacerlo a ciegas ;)
-

... ahí te han dado ! :p

Excelente comentario, Mario ! ;)

Bueno, pues gracias a los comentarios que aquí me proporcionaron, sobre todo el de Mario y el ejemplo del netscape :D, tomamos la decisión de seguir trabajando con la versión win32 de delphi que ya tenemos y con la que hemos estado trabajando.

Lo destacable es que durante el proceso de desarrollo, se acordó tener un proceso de análisis y capacitación para en un futuro (próximo año) estar preparados para hacer la migración a la plataforma .Net. Análisis de ver si será Delphi .Net o VS.Net y una vez decidido eso, capacitarnos y aprender la plataforma.

Además, cuando le informe a mi jefecito sobre el costo de la licencia para .net (cualquiera de las dos), nada más movió un poco el ojo izquierdo y dijo "vamos analizándolo para el próximo año". :D

Gracias a todos por su participación en este tema.

Excelente decisión de tu jefe, Carlos. Felicítalo de mi parte, por favor.