Delphi .Net o Visual Studio .Net

[[RONPABLO]]

Empezado por fer21unmsm

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

... posterior a windows XP

[ContraVeneno]

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)

[rcm861]

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

[[Al González]]

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

[mamcx]

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
-

[[gluglu]]

... ahí te han dado !

Excelente comentario, Mario !

[ContraVeneno]

Bueno, pues gracias a los comentarios que aquí me proporcionaron, sobre todo el de Mario y el ejemplo del netscape , 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".

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

[[Al González]]

Empezado por ContraVeneno

...nada más movió un poco el ojo izquierdo y dijo "vamos analizándolo para el próximo año"...

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