¿Por qué C ++ sigue siendo preferido para desarrollar aplicaciones GUI pesadas en los últimos lenguajes dinámicos? [cerrado]

Soy una de esas personas que escriben aplicaciones C ++ GUI (principalmente para Windows). Con Qt, para ser precisos. Mis razones:

• Me gusta C ++. Soy un profesional independiente y, por lo general, puedo elegir mis herramientas (¡qué suerte tengo!)
• En un entorno administrado, puede tener dificultades cuando necesita usar algún código no administrado (declaraciones de WinAPI de largo aliento en C #, ¿alguien?)
• Menos dependencias que se implementan más fácilmente
• Más control sobre todo.
• RAII (vs. GC). E incluso si asigno con new , raramente alguna vez delete nada explícitamente, porque uso punteros inteligentes o la jerarquía QObject .
• C ++ es muy emocionante en estos días, no puedo esperar a que un compilador admita completamente el nuevo estándar.
• Velocidad (solo al final de la lista. Sé que no es tan importante para la GUI en sí, pero tiende a ser más veloz porque los programas C ++ no sufren la sobrecarga que los tiempos de ejecución, el código de bytes de compilación JIT y tecnologías similares se agregan al programa.)

Como puede ver, estas son en su mayoría preferencias personales. Me parece importante que mi trabajo sea agradable y C ++ me lo proporciona.

Porque la velocidad importa.

• Juegos usa C ++ para las tareas principales, donde el rendimiento es importante. Usan lenguajes dinámicos para tareas de scripting donde la flexibilidad es importante.

• Aplicaciones de la GUI de escritorio : Visual Studio, por ejemplo, está escrito en .NET y no en C ++ nativo. Parece funcionar bastante bien para un IDE, ya que el IDE en sí no necesita realizar muchas tareas de rendimiento intenso. (El compilador, el enlazador y otras herramientas no están necesariamente escritos en .NET, aunque como señala wawa en un comentario, algunas parecen ser (por ejemplo, VB.NET))

• Los navegadores también deben ser rápidos. Después de todo, son una especie de sistema operativo secundario. Por otro lado, puede argumentar que grandes partes de Firefox en realidad están "escritas en" javascript, ya que el marco de trabajo de Mozilla parece depender fuertemente de javascript.

Para resumir: no diría que C ++ es necesariamente preferido pero si tiene un cuello de botella en el rendimiento, debe acercarse al metal y luego cumplir con C ++ (bueno, o C). A veces, será más fácil hacer todo en C ++, un solo idioma.

Las aplicaciones GUI que ves escritas en C ++ generalmente se hacen debido a razones heredadas. Python (con Qt o Gtk) es muy viable para las aplicaciones GUI, como lo es C # si trabajas en una casa Windows. Al comenzar algo nuevo, cualquiera de los dos es muy muy preferido a C ++ debido a la falta de trabajo de plomería que se debe hacer.

Debido a que no importa cuántas pruebas de rendimiento .NET y otras multitudes similares muestren, no importa qué tan cerca estén en los puntos de referencia, al final, la aplicación C ++ sale a la cabeza. Es más rápido en el arranque en frío, es más ágil y tiene más formas de mejorarlo.

He escuchado numerosas pruebas en las fases de inicio del proyecto que indican que .NET es el camino a seguir, pero una vez que se eligen, siempre terminan siendo una carga pesada.

Además, hoy en día, C ++ es bastante seguro y bastante fácil de usar, especialmente con marcos como Qt o WTL.

La mayoría de los motores de juego están codificados en C ++. También muchos de los motores de navegador están codificados en C ++. Pero la GUI del navegador a menudo se codifica utilizando un script ligero (JavaScript, Python). Con la notable excepción de Source Engine, la mayoría de los motores de juegos también usan lenguajes de script (como Lua o Python). [para referencia: lista de juegos con scripts de Lua ]

También toma la biblioteca popular de C ++ GUI como Qt. En la versión actual (4.7) usa QML para la GUI. QML es básicamente JavaScript con enlaces Qt.

Entonces realmente no hay lenguajes dinámicos C ++ vs , está mezclado.

La primera razón será: (antiguo) hábito

Segunda razón: menos confiabilidad en las máquinas virtuales, los intérpretes que se deben instalar, etc.

Y todavía hay algunos IDE excelentes para desarrollar código en C ++.

La razón es que tienes mucho más control sobre todo lo que sucede. Si fuera a escribir photoshop en C #, tendría serios problemas de rendimiento para algunas tareas. En un lenguaje de nivel inferior con más control, puede tomar atajos, optimizar donde sea necesario para cosas que son más intensas. Por supuesto, esto supone que está utilizando C ++ en código no administrado, no C ++ en .NET.

Consulte aquí para ver un ejemplo rápido.

C ++ se escribe estáticamente. Esto permite optimizar la ejecución del código de antemano haciendo que un compilador ajuste sus abstracciones al proceso del sistema disponible en una plataforma determinada. Hasta ahora, los idiomas dinámicos necesitan una capa de software adicional (= el intérprete) que ralentiza el acceso a los recursos del sistema.

La mayoría de los motivos indicados son técnicos o "por encima de la tabla" ... aquí hay razones comerciales o "debajo de la tabla":

distribuyendo código compilado v.s. Distribuyendo código fuente. Al desarrollar en c / c ++ se distribuyen los binarios. Si está desarrollando en uno de los idiomas modernos, distribuye la fuente. es difícil vender la idea de los ofuscadores a la gerencia que tiene que responder a los accionistas / inversores, así que no se preocupe.

usuarios estúpidos: al menos en la mente de la gerencia. aún perciben que sus usuarios apenas pueden hacer doble clic en un "setup.exe". Si incluye la instalación de un intérprete como parte de la configuración, sacudirán sus cabezas de lado a lado.

desarrolladores antiguos: la mayoría de las personas con experiencia han existido durante mucho tiempo y no se han actualizado. programan en C ++ y no en los idiomas más nuevos, porque no conocen los idiomas más nuevos.

Extendería el alcance del problema de la GUI al software que se espera sea competitivo. C ++ no impone impuestos a la plataforma de destino, ya que se refiere a la capacidad de procesamiento, el tiempo de ejecución instalado, los marcos, etc. Por lo tanto, funcionará en un hardware de cliente más limitado que una solución similar escrita en un lenguaje gestionado / interpretado. En el caso de un software comercial exitoso, el costo de desarrollo (potencialmente mayor en el caso de C ++) se amortiza por el número de ventas.

Además, C ++ generalmente ofrece acceso directo a las apis del sistema (como GUI), lo que brinda la mejor oportunidad para optimizar la utilización y diferenciarse de soluciones similares.

Creo que mucho de esto tiene que ver con las API para los kits de herramientas GUI. Todos ellos tienen una API C / C ++, pero no todos tienen (digamos) enlaces Python. Y, a veces, los propios kits de herramientas se escribieron teniendo en cuenta C ++, por lo que incluso si tienen soporte para otros idiomas, no son totalmente compatibles con ellos (p. Ej., No admiten Python tuple as un argumento).

Estás mencionando navegadores y juegos como ejemplos. Ambas son aplicaciones bastante críticas para el rendimiento, por lo que tenerlas en un lenguaje de bajo nivel para la velocidad tiene sentido.

Muchas otras aplicaciones están menos vinculadas al rendimiento y podrían escribirse fácilmente en otros idiomas. C # en particular parece ser usado mucho. (Y Obj-C, pero realmente no califica como de alto nivel, supongo. Mejor que C ++, sin embargo).

Sin embargo, existe una cierta falta de marcos para los últimos lenguajes de programación. Por ejemplo, no hay una biblioteca de GUI nativa viable para Python, en realidad. Claro, puedes usar PyQt o PyGtk y funcionan bien, pero al final, eso solo vuelve a interactuar con el código C. Nuevamente, C # (y posiblemente Obj-C) parece ser la excepción y quizás, MacRuby o IronPython podrían cambiar ese juego.

Para que un lenguaje reemplace a C ++ o Java, tiene que hacer lo que se pierde en estos idiomas además de realizarlos en sus propios puntos fuertes. Además, se han realizado grandes inversiones en estos idiomas. Eso significa que hay una biblioteca estándar de C ++ en muchas plataformas, que los navegadores, juegos y tales programas pueden usar fácilmente. Así que es inevitable que haya alguna inercia. Los idiomas tienden a despegar lentamente a diferencia de otras piezas de software.

Si lo miras, Anaconda (el programa de instalación de RedHat) ha existido por más o menos 10 años, escrito en Python desde el principio. Python no era tan popular cuando Anaconda era nueva.

Google's Go (golang.org) está evolucionando muy rápido. El compilador aún no ha sido bootstrapped. Para que su popularidad despegue, su biblioteca tiene que estabilizarse, el compilador debe ser bootstrapped y, más gente tiene que usarlo. He oído que un programa de producción fuera de Google está escrito en Go y, según se informa, no ha tenido tiempo de inactividad en su vida de poco más de un año.