sharp - ¿Cuáles son las ventajas de c#sobre, por ejemplo, delphi/realbasic para aplicaciones de Windows

ventajas y desventajas de c# frente a otros lenguajes (10)

Bueno, .NET Framework se comparte para todas las aplicaciones .NET, por lo que solo lo tiene una vez en su máquina y 35 MB no son nada hoy (compárelo con el tamaño de su instalación de Vista). Para su segunda aplicación .NET no tiene que volver a descargarla.

¿Alguna vez alguien ha escrito una aplicación más grande que su equipaje .NET? La gente solía criticar a VB6 por su tiempo de ejecución de 2 MB, pero raramente empequeñecía la aplicación que acompañaba.

Hoy, a pesar de tener Vista en mi máquina, tuve que descargar 35 MB del framework 3.5 y reiniciar para luego probar una aplicación de la mitad de ese tamaño.

Cuando se tiene en cuenta la disminución de la seguridad del código fuente, me pregunto por qué alguien podría desarrollar una aplicación de Windows en .NET en lugar de un lenguaje que permitiera la construcción de ejecutables nativos.

¿Qué tiene de superior .NET que eclipsa estos inconvenientes cuando se trata de escribir aplicaciones para ejecutar en Windows?

Hay muchas razones. No sé mucho sobre RealBasic, pero en lo que respecta a Delphi:

Menos extendida que .NET, comunidad de desarrollo más pequeña. Muchos de los recursos de Delphi en la red son antiguos y obsoletos.
Hasta Delphi 2009, Delphi no tenía soporte unicode completo.
No sé sobre Delphi 2009, pero 2007 no tenía muy buena recolección de basura. Tenía algún tipo de recuento de referencias torpes que requería alguna intervención en nombre del desarrollador. .NET tiene un GC mucho más avanzado que hace prácticamente todo por ti.
.NET tiene una biblioteca estándar más grande y bibliotecas de terceros más actualizadas.
Los lenguajes .NET como C # son posiblemente mejores, y ciertamente más fáciles de entender para los nuevos en el lenguaje.

La "simplicidad" de desarrollar aplicaciones complejas (y simples) que lo usan. Muchas cosas básicas ya están codificadas para ti en el marco y puedes usarlas. Y descargar el archivo de 35mb hoy es mucho más fácil que el archivo de 2mb hace 8-6 años.

Para nombrar unos pocos:

Manejo automático de la memoria, recolección de basura
Tipo de seguridad
Comprobación de límites
Acceda a miles de clases que no tendrá que crear

Aceptar primero, Ningún idioma / plataforma será universalmente superior.

La especialización siempre proporcionará un mejor caso de uso en ciertas áreas, pero los idiomas de uso general se aplicarán a más dominios.
Los lenguajes multi-paradigma sufrirán de casos límite complejos entre paradigmas, por ejemplo
- Escriba inferencia en cualquier lenguaje funcional que también permita OOP cuando se presente con subclases
- La gramática de C ++ es asombrosamente compleja. Esto tiene un efecto directo en las capacidades de su cadena de herramientas.
- Las complejidades de la varianza co / contra junto con los genéricos en c # son muy difíciles de entender.

Los idiomas antiguos tendrán bases de código existentes que funcionen, esto es positivo (experiencia, bien probado, amplia literatura de apoyo) pero también negativo (la inercia resultante contra el cambio, múltiples maneras diferentes de hacer las cosas que llevan a confusión para los nuevos participantes).

La selección / uso de ambos idiomas y plataformas es, como la mayoría de las cosas, un equilibrio entre los pros y los contras.

En las siguientes listas, Delphi tiene algunos de los mismos pros y contras, pero también difiere en muchos.

Negativas potenciales de .Net (si no son un problema para usted, no son negativos)

Sí, necesita el tiempo de ejecución implementado (e instalado), y es grande.
Si quería un idioma con herencia múltiple, no lo va a obtener
La biblioteca de colecciones BCL tiene algunos defectos serios
No es ampliamente compatible fuera del universo de MS (mono es genial pero retrasa significativamente la implementación oficial)
Posible carga de patentes / derechos de autor
El tiempo de arranque jitted (ignorando ngen) siempre será más lento y se necesitará más memoria.

Hay más, pero estos son los aspectos más destacados.

Positivos Positivos (nuevamente si no te importan)

Un GC universal, no hay conteo de referencias que impida el uso de ciertas estructuras de datos, no conozco un lenguaje funcional ampliamente utilizado sin GC, no puedo pensar en un lenguaje significativo de los últimos 10 años sin al menos GC opcional. Si crees que esto no es un gran problema, parecerías ser una minoría.
Un BCL grande (algunas partes no son tan buenas como otras pero es muy amplia)
Se pueden usar e interactuar grandes cantidades de idiomas (y un sorprendente número de paradigmas) (utilizo c #, f #, C ++ / CLI en una aplicación más amplia usando cada uno de ellos donde tiene más sentido, pero puedo usar fácilmente aspectos de uno de otro).
Completa introspección presentada combinada con soporte de programación declarativa. Una amplia variedad de marcos se vuelve mucho más simple y fácil de usar de esta manera.
Jitted: las modificaciones en la arquitectura de la CPU subyacente pueden ser en gran parte transparentes, las optimizaciones sofisticadas de tiempo de ejecución no disponibles para los lenguajes precompilados son posibles (java lo está haciendo bastante mejor en este momento)
seguridad de acceso a la memoria
Fusion dll carga y el GAC para sistema dlls

Del mismo modo, específicamente para c #

Estafa:

Sintaxis basada en C fundamentos
(pre 4.0) enlace tardío únicamente a través de la herencia
Más detallado que algunos lenguajes imperativos
manejo deficiente de literales incrustados complejos (regexes / xml / multi line strings)
la captura variable dentro de cierres puede ser confusa
Los generadores anidados son engorrosos y funcionan atrozmente

Pro:

Sintaxis basada en C fundamentos
Mucho soporte funcional a través de lambdas
Expresiones que permiten la validación en tiempo de compilación de áreas sin código como Linq a SQL
Fuertemente tipeado pero con alguna inferencia Tipo para hacer esto más fácil
si realmente necesita inseguridad está ahí para usted
la interacción con el código C ++ ABI existente a través de P / Invoke es simple y clara.
modelo de evento multicast integrado.
generación de código de tiempo de ejecución ligero

Los fundamentos de C realmente son pro y contra. Es comprensible para un gran número de programadores (en comparación con el estilo basado en pascal) pero tiene una cierta cantidad de cruft (las declaraciones de cambio son un claro ejemplo).

Los sistemas de tipo Fuerte / Débil / Estático / Dinámico son un debate polarizador, pero ciertamente no es polémico decir que, donde el sistema de tipo es más restrictivo, debe esforzarse por no exigir una excesiva verbosidad como resultado, c # es ciertamente mejor que muchos en ese considerar.

Para muchas aplicaciones internas de Line of Business, una gran cantidad de las plataformas .Net Cons son absolutamente irrelevantes (la implementación controlada es un problema común y bien resuelto en las empresas). Como tal, el uso de .Net (y esto en gran medida significa c #, lo siento chicos VB.Net) es una opción bastante obvia para el nuevo desarrollo dentro de una arquitectura de Windows.

De acuerdo, dudo que esto te persuada ya que no quieres que te persuada, pero esta es mi opinión sobre las ventajas de .NET sobre las tecnologías más antiguas. No voy a decir que todas las ventajas se aplican a todos los idiomas que mencionaste en la pregunta, o que .NET es perfecto, pero:

Un entorno administrado detecta errores comunes antes y ofrece nuevas oportunidades:
- La tipificación fuerte evita tratar un tipo como otro incorrectamente
- La recolección de basura elimina en gran medida las preocupaciones de administración de memoria (no totalmente, lo admitiré fácilmente)
- "Error de segmentación" generalmente se traduce en "NullReferenceException", ¡pero de una manera mucho más fácil de depurar!
- No hay posibilidad de sobrepasar el búfer (aparte de la posibilidad de errores CLR, por supuesto), que elimina de inmediato una gran preocupación de seguridad
- Un modelo de seguridad declarativo y un tiempo de ejecución bien diseñado permiten que el código se ejecute bajo una variedad de niveles de confianza
- JITting permite que CLR aproveche la ejecución en una máquina de 64 bits sin necesidad de una recompilación (a excepción de algunas situaciones de interoperabilidad)
- Los desarrollos futuros de los procesadores también pueden ser objetivo de JITter, proporcionando mejoras sin el trabajo del desarrollador (incluida la necesidad de reconstruir o distribuir varias versiones).
- La reflexión permite todo tipo de cosas que son imposibles o difíciles en entornos no administrados
Un marco moderno orientado a objetos:
- Genéricos con conocimiento del tiempo de ejecución (a diferencia del borrado de tipos en Java)
- Soporte de roscado razonable, con un nuevo conjunto de primitivos (extensiones paralelas) en .NET 4.0
- Internacionalización y soporte de Unicode desde el principio: solo un tipo de cadena a considerar, por un lado :)
- Windows Presentation Framework proporciona un marco de GUI moderno, que permite un diseño declarativo, buen diseño y soporte de animación, etc.
- Buen soporte para interoperar con bibliotecas nativas (P / Invoke es mucho más agradable que JNI, por ejemplo)
- Las excepciones son mucho más informativas (y más fáciles de tratar) que los códigos de error
- LINQ (en .NET 3.5) proporciona una manera encantadora de trabajar con datos en proceso, además de brindar varias opciones para trabajar con bases de datos, servicios web, LDAP, etc.
- Los delegados permiten un estilo de codificación algo funcional de VB y C #; esto es mejor en C # 3.0 y VB9 debido a expresiones lambda.
- LINQ to XML es la mejor biblioteca XML que he usado
- El uso de Silverlight como marco de RIA le permite compartir una gran cantidad de código entre su cliente liviano y otros métodos de acceso
- Una historia de versionamiento en su mayoría buena, incluida la redirección de enlace, preferencia de tiempo de ejecución, etc.
Un marco dirigido por múltiples idiomas:
- Más simple para compartir componentes que con (digamos) COM
- La elección del idioma puede ser impulsada por la experiencia de la tarea y el equipo. Esto será particularmente significativo a partir de .NET 4.0: donde un lenguaje funcional es más apropiado, use F #; donde un lenguaje dinámico es más apropiado, use IronRuby o IronPython; interoperar fácilmente entre todos los idiomas
- Francamente, creo que C # es un lenguaje mucho más limpio que VB o C ++. (No conozco a Delphi y he escuchado cosas buenas sobre eso, y bueno, ahora puedes atacar .NET con Delphi).

El resultado de la mayor parte de esto, y el sonido, supongo, es que .NET permite un desarrollo más rápido de aplicaciones más robustas .

Para abordar los dos problemas específicos que mencionó en la pregunta:

Si su cliente ejecuta Vista, ya tienen .NET 3.0. Si están ejecutando XP SP2 o SP3, probablemente tengan al menos .NET 2.0. Sí, tienes que descargar una versión más nueva del marco si quieres usarlo, pero lo veo como un problema bastante pequeño. No creo que tenga sentido comparar el tamaño de su aplicación con el tamaño del marco. ¿Compara el tamaño de su aplicación con el tamaño del sistema operativo o el tamaño de su IDE?
No veo la descompilación como casi un problema como la mayoría de las personas. Realmente necesitas pensar en lo que temes:
- Si le temes a las personas que copian tu código real, normalmente es mucho más fácil codificar desde cero si conoces el diseño básico. Tenga en cuenta que un decompilador no dará nombres de variables locales (suponiendo que no distribuya su PDB) o comentarios. Si su código fuente original es tan fácil de entender como la versión decompilada, tiene mayores problemas que la piratería.
- Si le temes a las personas eludir tus licencias y piratear tu código, debes tener en cuenta cuánto esfuerzo se ha realizado para evitar que la gente piratee aplicaciones nativas, y cuán ineficaz ha sido.
- Gran parte del uso de .NET está en el servidor o para aplicaciones internas; en ninguno de estos casos, la descompilación es un problema.
- Escribí más sobre este tema en este artículo sobre descompilación y ofuscación .

Hay una gran cantidad de supuestas ventajas citadas por los desarrolladores de .NET aquí que no deberían estar en esa comparación, simplemente porque Delphi también las tiene:

Tipo de seguridad
Comprobación de límites
Acceda a miles de clases (componentes) que no tendrá que crear

Sin embargo, hay elementos en .NET que Delphi no tiene listos, y solo algunos de ellos pueden ser agregados por bibliotecas y código propio. Para nombrar unos pocos:

Compatibilidad con varios idiomas que funcionan en la misma duración de tiempo de ejecución, lo que permite elegir el idioma correspondiente para el problema (por ejemplo, programación funcional con F #)
Generación y compilación dinámica de código fuente: esto es algo tan extraño para los programadores de Delphi que probablemente ni siquiera vean cómo podría ser útil [1]
Eventos de multidifusión
Mejor soporte multihilo (por ejemplo, clase BackgroundWorker, delegados asincrónicos)
Soporte sin interrupciones para procesos de 32 y 64 bits
Referencias débiles

[1] Si no sabe pero le interesa, consulte la página de inicio de Marc Clifton , especialmente los artículos sobre programación declarativa.

Editar: Me gustaría responder al comentario de Mason Wheeler:

Re código dinámico: sé que hay soluciones para incorporar scripts de Pascal en la aplicación. Sin embargo, existe una clara diferencia entre hacer que las partes de su jerarquía de objetos internos estén disponibles para el motor de scripting y tener el mismo compilador que se utiliza para su código disponible también en tiempo de ejecución. Siempre hay diferencias entre el compilador Delphi y el compilador del motor de scripting. De todos modos, lo que obtienes con .NET va más allá de todo lo que está disponible para Delphi. Y de todos modos, no es el punto si uno podría codificar una infraestructura similar para Delphi, el punto es que con .NET ya está ahí para usted, cuando lo necesite.
Re eventos de multidifusión: Exactamente, hay formas de codificarlo, pero no forma parte de Delphi / VCL out-of-the-box. Eso es lo que estaba diciendo arriba.
Re referencias débiles: Estás tristemente equivocado. Intente utilizar las interfaces de una manera no trivial, creando referencias circulares en el camino. Luego debe comenzar a usar typecasts y desear referencias débiles.

Por lo que puedo ver, RealBASIC no tiene mucho (si acaso) en el camino de las herramientas Object Relational y probablemente no sería una buena opción para las aplicaciones centradas en bases de datos de n niveles.

GENTE: Tenga en cuenta que esto fue escrito en febrero de 2009 , y lo que se dijo era apropiado en ese momento - gritarme a finales de 2012 (más de 3 años más tarde) no tiene sentido. :-)

Delphi tiene algunas ventajas considerables para Win32. No es que las aplicaciones .NET sean intrínsecamente malas, pero intente:

ejecutando una aplicación .NET (cualquier versión) en Win95 / ME, donde .NET no existe (AFAIK)
distribuyendo cualquier aplicación .NET pequeña (<1.5 MB) (sí, todavía existen disquetes)
proporcionar cualquier aplicación .NET en un sistema que no tiene acceso a Internet (sí, existen)
distribuyendo sus aplicaciones .NET en países sin gran ancho de banda generalizado
evitar que las personas vean su código fuente sin gastar una tonelada de masa (Reflexión, ¿alguien?)

La recolección de basura en .NET podría ser realmente agradable, pero cualquiera que sepa algo sobre programación también puede manejar la asignación manual / desasignación de memoria fácilmente con Delphi, y GC está disponible con interfaces contadas por referencia. ¿No es una de las cosas que trajo a todos los no programadores a la proliferación el pseudo-GC de VB? IMO, GC es una de las cosas que hace que .NET sea peligroso, del mismo modo que VB era peligroso: hace las cosas demasiado fáciles y permite que las personas que realmente no tienen ni idea de lo que están haciendo escriban un software que termine haciendo un desastre. (Y, antes de que me llame a la muerte aquí, es genial para las personas que sí saben lo que están haciendo, y también lo era VB; no estoy tan seguro de que la ventaja para los expertos supere los riesgos para nosotros de los no calificados)

Delphi Prism (AKA Rem Objects Oxygene, anteriormente Chrome) proporciona la versión GC de Delphi que aquellos que lo necesitan están buscando, junto con ASP.NET y WPF / Silverlight / CE, con la legibilidad (y la falta de llaves) de Delphi . Para aquellos (como yo) para los que la compatibilidad con Unicode no es un factor importante, Delphi 2007 proporciona ASP.NET y VCL.NET, así como compatibilidad con Win32 nativo. Y, en un lugar donde trabajo, cuando las estaciones de trabajo solo se actualizan (como mínimo) cada tres años, y cuando acabamos de deshacernos de la última máquina Win95 porque no era una prioridad actualizar, el .NET Framework es un problema. (Especialmente con los requisitos de proxy de la compañía que solo permiten el acceso a Internet a un puñado de personas, limitando el ancho de banda y las capacidades de descarga, y cuentas no administrativas adecuadas sin dispositivos USB permitidos, todas funcionando en una red Netware, nada similar a Windows Update, y nunca un virus hasta el momento porque no entra nada).

Trabajo en lenguajes .NET (C #, Delphi Prism), pero el pan y la mantequilla a tiempo completo y en el lateral, provienen de Win32 y Delphi.

Para la aplicación de Windows, .NET (usando C # o lo que sea) le brinda un acceso más directo a las últimas y mejores características de Windows. También está muy bien soportado por Microsoft, tiene una gran comunidad y muchos libros escritos al respecto.

REALbasic (ahora Xojo ) es para aplicaciones multiplataforma. Usarlo solo en Windows a veces puede ser útil, pero esa no sería su fortaleza (que es increíblemente fácil de usar).

No sé mucho sobre Delphi.