Soy un estudiante recién graduado con el objetivo de comenzar mi Maestría en Ciencias de la Computación. Me he encontrado con múltiples proyectos de código abierto que realmente me intrigan y me alientan a contribuir a ellos (CloudStack, OpenStack, moby y Kubernetes, por nombrar algunos). Una cosa que he encontrado que la mayoría de ellos tienen en común es el uso de múltiples lenguajes de programación (como Java + Python + Go o Python + C ++ + Ruby). Ya he visto esta otra pregunta, que trata de cómo se hacen los múltiples lenguajes de programación para comunicarse entre sí: ¿Cómo interactuar dos programaciones diferentes con dos lenguajes diferentes?
Quiero comprender el requisito que incita a las empresas a usar múltiples lenguajes de programación. ¿Qué requisito o tipo de requisito hace que el arquitecto de software o el líder del proyecto diga: "Estoy proponiendo que usemos el lenguaje X para la tarea 1 y el lenguaje Y para la tarea 2"? Parece que no puedo entender la razón por la cual se usan múltiples lenguajes de programación en el mismo producto o software.
fuente
Respuestas:
Esta respuesta tiene una excelente cobertura y enlaces sobre por qué diferentes idiomas pueden proporcionar beneficios distintos a un proyecto. Sin embargo, hay algo más que la idoneidad del idioma involucrado en por qué los proyectos terminan usando múltiples idiomas.
Los proyectos terminan usando múltiples idiomas por seis razones principales:
Las razones 1-4 son razones positivas en el sentido de que abordarlas directamente puede ayudar a que un proyecto concluya más rápido, más eficientemente, con un producto de mayor calidad y con un soporte a largo plazo más fácil. Las razones 5 y 6 son negativas, síntomas de resistencia al cambio necesario, mala planificación, manejo ineficaz o alguna combinación de todos estos factores. Lamentablemente, estos factores negativos son causas comunes del uso "accidental" de varios idiomas.
La razón 1 , los beneficios de costo de la reutilización, se ha convertido en una razón cada vez más poderosa para permitir el uso de múltiples idiomas en un proyecto debido tanto al mayor papel del software de código abierto como a las capacidades mejoradas para encontrar los componentes de código correctos en la web. La filosofía de "codifiquemos todo internamente" de las últimas décadas continúa desvaneciéndose ante las realidades económicas, y esencialmente nunca es el enfoque más rentable para ningún proyecto nuevo. Esto a su vez hace que las oportunidades para la aplicación estricta del uso de un solo idioma dentro de un proyecto sean menos comunes.
Especialmente en el caso de un proyecto que reutiliza componentes de código abierto bien administrados, el uso de múltiples idiomas puede proporcionar enormes beneficios de costos generales porque los componentes reutilizados están ocultos detrás de interfaces bien diseñadas y son mantenidos de forma independiente por grupos externos de costo cero. En el mejor de los casos, mezclar idiomas a través de este tipo de reutilización no es más costoso para el proyecto que usar componentes del sistema operativo. No conozco mejor ejemplo del valor de este enfoque que la adopción a gran escala de Microsoft de software de código abierto en sus navegadores.
La razón 2 , la necesidad de acomodar el código heredado, se ignora bajo el riesgo de cualquier proyecto grande. Sin embargo, pueden causar muchos problemas el código heredado, suponiendo ingenuamente que puede reemplazarse fácilmente con un nuevo código en un nuevo idioma puede ser increíblemente arriesgado. El código heredado, incluso el mal código heredado, a menudo incluye lo que equivale a un "contrato" implícito de características que la comunidad espera que utilice el producto heredado. Esa comunidad a menudo es una fuente importante de ingresos para una empresa, o el objetivo principal de soporte para el software gubernamental. Simplemente descartar ese contrato implícito puede perseguir a clientes conscientes en masa y puede llevar a la bancarrota a una empresa de la noche a la mañana si hay otras opciones disponibles.
Al mismo tiempo, no reemplazar el código antiguo en un idioma antiguo puede ser tan peligroso como reemplazarlo al por mayor. El peor de los casos es la Administración de Veteranos de EE. UU., Que tiene una gran cantidad de sistemas vitales codificados en un lenguaje llamado MUMPS (no es broma) que fue diseñado por médicos, no por científicos de la computación. Nadie quiere aprender MUMPS, y aquellos que lo saben están literalmente muriendo. Por lo tanto, los programadores deben acomodar MUMPS incluso cuando intentan avanzar hacia el uso de otros lenguajes más comunes, más potentes y mejor mantenidos.
Este tipo de uso multilingüe requiere una planificación cuidadosa. Esa planificación debe navegar el filo de la navaja entre perder décadas de conocimiento del cliente por un lado, y perder la capacidad de soportar el software por el otro. Las técnicas que aíslan el código antiguo detrás de interfaces bien definidas y que permiten que un código nuevo y más poderoso reemplace el código antiguo después de que sus comportamientos hayan sido bien documentados, pueden ayudar. Pero este escenario heredado nunca es fácil, y ha sido (y seguirá siendo) la causa de la desaparición de muchas empresas y organizaciones en un amplio espectro de tamaños.
La razón 3 , la disponibilidad de codificadores para varios idiomas, es un factor pragmático que los proyectos ignoran a su propio riesgo. Por mucho que los organizadores del proyecto sientan (correcta o incorrectamente) que un idioma en particular es el mejor para sus objetivos, si ese idioma está en conflicto con el grupo de expertos en idiomas disponibles para ellos, tanto el horario como la calidad del producto se verán afectados por el aprendizaje. Curva de programadores que intentan aprender un nuevo idioma.
Un enfoque más racional es analizar las necesidades lingüísticas del proyecto en función de las áreas funcionales. Por ejemplo, mirar cuidadosamente el proyecto puede mostrar que solo hay un pequeño "vértice" de código de alto valor, por ejemplo, para implementar algún algoritmo patentado, que requiere experiencia en codificación en un lenguaje menos comúnmente usado. Otras partes de cualquier proyecto grande a menudo se acomodan fácilmente con lenguajes más comunes, o (aún mejor) con productos de código abierto bien administrados. Analizar un proyecto por necesidades lingüísticas puede proporcionar un enfoque mucho más realista y rentable para contratar o alquilar experiencia especial en idiomas especiales, y también puede ayudar a agudizar las interfaces entre idiomas dentro de un solo proyecto.
La razón 4 , que usa diferentes lenguajes para diferentes necesidades, sigue de manera inmediata y sin problemas la realización de ese tipo de análisis de las necesidades del proyecto. También se debe tener cuidado en esto, ya que seleccionar demasiados idiomas para soporte dentro de un solo proyecto puede causar una explosión combinatoria de complejidad tanto en soporte como en interfaces entre componentes. La ruta más segura en cuanto a costos es siempre encontrar primero las máximas oportunidades de reutilización, especialmente si existen buenos paquetes que puedan satisfacer las necesidades del proyecto a través de poco más que la personalización. A continuación, se debe tomar algún tipo de decisión sobre un pequeño número de idiomas que puedan abordar la mayoría de las necesidades identificadas. En el desarrollo intensivo de reutilización, esto a menudo será un tipo de código de pegamento.
Por lo general, no es una buena idea elegir varios idiomas con capacidades muy similares solo porque a algunos miembros del proyecto les gusta uno y a otros. Sin embargo, si hay un subconjunto de capacidades bien identificado y bien definido que se beneficiaría de habilidades lingüísticas especiales, esa puede ser una buena razón para usar múltiples idiomas para el desarrollo de nuevos códigos.
La razón 5 , la resistencia a los cambios necesarios en los idiomas utilizados, puede ser una causa de interrupción severa del proyecto y conflictos internos. Como usuario DaveoEn un comentario sobre esta respuesta, el cambio puede ser muy difícil para algunos miembros del personal del proyecto. Al mismo tiempo, la resistencia al cambio nunca es un problema simple, y es precisamente por eso que puede causar mucho conflicto. El uso de habilidades de lenguaje heredado puede ser un poderoso impulso para la productividad de un proyecto si el lenguaje heredado es lo suficientemente poderoso y puede conducir a un producto con excelente calidad en un equipo que funciona sin problemas y respeta la calidad. Sin embargo, las habilidades lingüísticas heredadas deben equilibrarse con el hecho de que muchos idiomas antiguos ya no pueden completarse con idiomas más recientes en términos de características avanzadas, disponibilidad de componentes, opciones de código abierto y compatibilidad con el kit de herramientas inteligente.
Tanto entonces como ahora, el argumento más común (e irónicamente, con mayor frecuencia correcto) para continuar usando un lenguaje heredado más débil, menos legible o menos productivo ha sido que el lenguaje más antiguo permite la producción de un código más eficiente. Este es un viejo argumento, que se remonta a la década de 1950, cuando los usuarios del lenguaje ensamblador resintieron, a menudo amargamente, la aparición de la programación en FORTRAN y LISP. Un ejemplo en el que incluso ahora el argumento de eficiencia del código puede tener validez se puede ver en el código de procesamiento intensivo, como el núcleo de un sistema operativo, donde C sigue siendo el lenguaje de elección sobre C ++ (aunque por razones que van más allá de la simple eficiencia).
Sin embargo, en los entornos de proyectos del nuevo milenio, conectados en red a nivel mundial y poderosamente respaldados por máquinas, la eficiencia del código como argumento principal para elegir un lenguaje de proyecto se ha debilitado aún más. La misma explosión de hardware informático y de redes que ha permitido el mercadeo masivo de aplicaciones de inteligencia artificial también significa que los costos de la programación humana pueden fácilmente eclipsar los de la relatividad en la ejecución de código ineficiente en hardware y cloudware espectacularmente baratos. Cuando eso se combina con la mayor disponibilidad en los idiomas más recientes de las bibliotecas de componentes, las opciones de código abierto y los kits de herramientas inteligentes avanzadas, el número de casos en los que mantener un idioma solo por razones de eficiencia se vuelve muy limitado. Incluso en los casos en que se aplica,
Una razón más convincente para que un proyecto permanezca con idiomas heredados ocurre cuando, por cualquier razón, un proyecto tiene pocas o ninguna opción para cambiar su personal. Esto puede suceder, por ejemplo, cuando una importante línea de productos heredados se codifica por completo en un idioma con el que solo el personal existente habla con fluidez. En tales casos, el proyecto debe continuar por el camino de intentar programar en el idioma antiguo o intentar capacitar al personal existente sobre cómo usar un nuevo idioma.
Capacitar al personal de idiomas heredados en un nuevo idioma puede ser un peligro en sí mismo. Todavía recuerdo un caso en el que un miembro de un proyecto que acababa de ser entrenado y en transición de C a C ++ se quejaba con toda sinceridad de que simplemente no entendía las ventajas de los métodos orientados a objetos. Cuando miré su código, había convertido sus funciones 103 C anteriores en 103 métodos para una sola clase de objeto C ++ ... y con razón no vio cómo eso ayudaba en nada.
El mensaje más profundo es que cuando las personas han programado en un solo idioma y estilo de lenguaje durante años o décadas, la dificultad para lograr que "piensen" de nuevas maneras puede volverse casi insuperable, incluso con buenos programas de capacitación. En algunos casos, puede no ser otra opción que atraer a diseñadores y programadores más jóvenes que estén más en sintonía con las tendencias y métodos actuales.
La razón 6 , mala gestión de proyectos, habla por sí misma. La selección y uso del idioma en un proyecto siempre debe considerarse y evaluarse explícitamente, y no debe permitirse que ocurra solo por accidente. Como mínimo, la selección de idioma puede marcar una gran diferencia en el destino a largo plazo y los costos de soporte de un proyecto, por lo que siempre debe tenerse en cuenta y planificarse. ¡No te conviertas en MUMPS!
fuente
Es bastante simple: no existe un lenguaje de programación único adecuado para todas las necesidades y objetivos.
Lea el libro de Michael L. Scott Programming Language Pragmatics
Algunos lenguajes de programación favorecen la expresividad y la declaratividad (muchos lenguajes de programación, pero también lenguajes de programación de alto nivel como Agda , Prolog , Lisp , Haskell, Ocaml, ...). Cuando el costo de desarrollo es importante (tiempo humano y costo de los desarrolladores), es adecuado usarlos (incluso si el rendimiento en tiempo de ejecución no es óptimo).
Otros lenguajes de programación favorecen el rendimiento en tiempo de ejecución (muchos lenguajes de bajo nivel, con implementaciones generalmente compiladas, como C ++, Rust, Go, C, ensamblador, también lenguajes especializados como OpenCL ...); a menudo su especificación permite un comportamiento indefinido . Cuando el rendimiento del código es importante, es preferible utilizar estos idiomas.
Algunas bibliotecas externas están escritas en y para un idioma particular y ABI y teniendo en cuenta las convenciones . Es posible que necesite usar ese otro idioma y seguir las convenciones de la interfaz de funciones externas , tal vez escribiendo algún código de pegamento .
En la práctica, es poco probable que tenga un lenguaje de programación que sea altamente expresivo (por lo que mejora la productividad del desarrollador, suponiendo un equipo de desarrolladores lo suficientemente calificado) y muy eficiente en el tiempo de ejecución. En la práctica, existe una compensación entre expresividad y rendimiento.
Nota: sin embargo, ha habido un progreso lento en los lenguajes de programación: Rust es más expresivo que C o tal vez incluso C ++, pero su implementación es casi igual de efectiva y probablemente mejorará para generar ejecutables igualmente rápidos. Por lo tanto, debe aprender nuevos lenguajes de programación durante su vida profesional; sin embargo no hay bala de plata
Tenga en cuenta que el costo de desarrollo es cada vez más significativo en la actualidad (ese no era el caso en la década de 1970, en ese momento, las computadoras eran muy costosas, o en algunas aplicaciones integradas, con un gran volumen de producto). La regla general (muy aproximada) es que un desarrollador experto puede escribir alrededor de 25 mil líneas de código fuente (depurado y documentado) cada año, y eso no depende mucho del lenguaje de programación utilizado.
Un enfoque común es incrustar algún lenguaje de secuencias de comandos (o algún lenguaje específico de dominio ) en una aplicación grande. Esta idea de diseño (relacionada con el lenguaje específico del dominio) se ha utilizado durante décadas (un buen ejemplo es el editor de código fuente de Emacs , que utiliza Elisp para las secuencias de comandos desde la década de 1980). Luego usará un intérprete fácilmente integrable (como Guile , Lua , Python, ...) dentro de una aplicación más grande. La decisión de incorporar un intérprete dentro de una aplicación grande debe hacerse muy temprano y tiene fuertes implicaciones arquitectónicas. Luego usará dos lenguajes: para cosas de bajo nivel que deben ejecutarse rápidamente, algún lenguaje de bajo nivel como C o C ++; para scripts de alto nivel, el otro lenguaje DSL o scripting.
Tenga en cuenta también que un software determinado puede ejecutarse, en la mayoría de los sistemas operativos actuales (incluidos Linux, Windows, Android, MacOSX, Hurd, ...), en varios procesos cooperativos utilizando algún tipo de técnicas de comunicación entre procesos . Incluso puede ejecutarse en varias computadoras (o en muchas de ellas), utilizando técnicas informáticas distribuidas (por ejemplo , computación en la nube , HPC, servidor cliente, aplicaciones web , etc.). En ambos casos, es fácil usar varios lenguajes de programación (por ejemplo, codifique cada programa que se ejecuta en un proceso o computadora en su propio lenguaje de programación). Lea Sistemas operativos: tres piezas fáciles para más. Además, las interfaces de funciones externas(por ejemplo, JNI ), ABI , convenciones de llamadas , etc., facilitan mezclar varios idiomas en el mismo programa (o ejecutable ), y encontrará generadores de código como SWIG para ayudar.
En algunos casos, debe mezclar varios lenguajes de programación: las aplicaciones web necesitan Javascript o Webassembly (los únicos lenguajes que se ejecutan dentro de la mayoría de los navegadores web) para la parte que se ejecuta en el navegador (existen marcos que los generan , por ejemplo, ocsigen ). El código del kernel necesita algunas cosas (por ejemplo, el planificador o el manejo de interrupciones de bajo nivel) para ser escrito en parte en el ensamblador, porque C o C ++ no pueden expresar lo que se necesita allí, las consultas RDBMS deben usar SQL, las GPGPU necesitan núcleos de computadora codificados en OpenCL o CUDA administrado por código de host C o C ++, etc. Algunos lenguajes están diseñados para facilitar tal mezcla (por ejemplo,
asmdeclaraciones en C,trozos de código en mi último GCC MELT , etc ...).En algunos casos, utiliza técnicas de metaprogramación : algunas partes de su gran proyecto de software tendrían código (por ejemplo, en C o C ++) generado por otras herramientas (quizás herramientas específicas del proyecto) a partir de alguna formalización ad-hoc: generadores de analizadores (llamados incorrectamente compiladores) compiladores) como bison o ANTLR vienen a la mente, pero también SWIG o RPCGEN. Y observe que GCC tiene más de una docena de generadores de código C ++ especializados (uno para cada DSL interno dentro de GCC) dentro de él. Ver también este ejemplo. Tenga en cuenta que los metabugs son difíciles de encontrar. Lea también sobre compiladores de bootstrapping y sobre homoiconicidad y reflexión(vale la pena aprender Lisp , jugar con SBCL y leer SICP ; también busque en bibliotecas que compilan JIT como GCCJIT ; en algunos programas grandes puede generar algún código en tiempo de ejecución usándolos; tenga en cuenta la décima regla de Greenspun ). Mire también la charla Circuito menos transitado en FOSDEM2018.
A veces, desea proporcionar anotaciones formales de su código (por ejemplo, para ayudar a los probadores, analizadores estáticos, compiladores), utilizando algún lenguaje de anotaciones especializado (que podría verse como algún DSL). Mire ACSL con Frama-C para anotar programas en C (programas críticos para la seguridad) u pragmas de OpenMP para HPC. Advertencia: escribir tales anotaciones puede requerir muchas habilidades y tiempo de desarrollo.
Por cierto, esto sugiere que algunas habilidades sobre compiladores e intérpretes son útiles para todos los desarrolladores (incluso sin trabajar dentro de los compiladores). Así que lee el Libro del Dragón incluso si no trabajas en compiladores. Si codifica su propio intérprete (o si diseña su DSL), lea también Lisp In Small Pieces .
Vea también esto y aquello y aquello y eso respuestas mías relacionadas con su pregunta.
Estudie también el código fuente de varios proyectos grandes de software libre (en github o desde su distribución de Linux ) para obtener inspiración e iluminación.
Además, algunos lenguajes de programación evolucionaron al agregar anotaciones (como pragmas o comentarios ) a los lenguajes existentes. Para ejemplos, pensar en ACSL (un comentario de una extensión para anotar los programas en C para permitir que sus pruebas por Frama-C ) o de OpenCL (un dialecto C para programar GPGPUs) o OpenMP o OpenACC
#pragmas o anotaciones de tipo Common Lisp .PD: también hay razones sociales, organizativas o históricas para mezclar lenguajes de programación; Los estoy ignorando aquí, pero sé que en la práctica tales razones son dominantes. Lea también El Mes del Hombre Mítico
fuente
awk(que es otro lenguaje de programación) utilizado dentro de los scripts de bash, simplemente porque se ajusta mejor a la tarea). Sin embargo, el punto de @ amon sigue en pie.<sup>pero con remordimientosMuchos proyectos no están construidos con múltiples lenguajes de programación. Sin embargo, es común usar scripts en otros idiomas para ayudar con el software.
Algunos proyectos utilizan varios idiomas dentro de la aplicación, por ejemplo, un núcleo en un lenguaje de nivel inferior que puede integrar complementos en un lenguaje de secuencias de comandos. En algunos ecosistemas (por ejemplo, JVM o .NET), el lenguaje exacto utilizado no es demasiado importante ya que varios idiomas en el mismo tiempo de ejecución tienen buena interoperabilidad. Por ejemplo, podría escribir un proyecto en Scala que use bibliotecas Java existentes e integre la funcionalidad de secuencias de comandos con Groovy.
Si un proyecto consta de varias herramientas, también se pueden desarrollar en diferentes idiomas. Si bien la coherencia sería buena, especialmente para proyectos de código abierto, el esfuerzo de desarrollo disponible puede ser un cuello de botella. Si alguien está dispuesto a desarrollar una herramienta útil pero no está familiarizado con el idioma principal, tal vez esa herramienta sea más valiosa que la coherencia.
fuente
Esto tiene dos formas, y muchas organizaciones que caen en algún punto entre las dos:
La mala forma : la organización es un desastre y nadie se asegura de que haya una sola visión tecnológica para el esfuerzo. Es muy probable que los desarrolladores usen el idioma en el que se sientan más cómodos, o que hayan experimentado recientemente con un nuevo marco o lenguaje y hayan decidido simplemente comenzar a usarlo debido al optimismo ingenuo.
La buena forma : la organización tiene una arquitectura realmente buena y limpia que se presta bien a la programación políglota; desacoplar aplicaciones en componentes independientes con un contexto de límite bien definido, y esta combinación les permite seleccionar el lenguaje de programación que simplemente les permite escribir ese componente en particular.
Realidad : normalmente es más lo primero que lo segundo. He visto a algunas compañías elegir un idioma para su dominio comercial y otro para su servidor web, y a menudo el tercero para la administración de su base de datos, que técnicamente está bien, pero muy pronto su falta de comprensión técnica (o la negativa a escuchar a su personal) significa que terminan con los tres borrosos juntos en un gran desastre, y a menudo introducen aún más idiomas que son apropiados para resolver partes particulares del desastre.
fuente
Puedo aportar un ejemplo, de un proyecto de programación que se ha estado ejecutando durante 32 años, y parece que todavía le queda mucha vida. Es comercial más que de código abierto.
El núcleo está escrito en un lenguaje específico de dominio, creado específicamente para el proyecto. Esto ha demostrado ser extremadamente útil, especialmente porque integra la reversión en la arquitectura básica, pero se compila en código C, que luego compilamos con el compilador de la plataforma. Ha admitido alrededor de veinte plataformas durante ese tiempo, sin contar las variaciones de 32 frente a 64 bits, y actualmente se distribuye en seis de ellas.
Tiene un complemento, escrito en C ++, que se inició cuando un jefe anterior del proyecto se convenció de que C ++ / MFC / Windows / x86 iba a desplazar todas las demás arquitecturas y plataformas, por lo que era necesario ofrecer trabajo de C ++ para poder contratar personal. Las cosas no salieron como él esperaba.
Además del lenguaje de dominio y C ++, los desarrolladores trabajan en LISP, que se utiliza para escribir casos de prueba, utilizando un intérprete incorporado en el arnés de prueba. Consideramos reemplazar LISP con Java en un punto, pero resultó ser afortunado que no lo hicimos.
También tiene un contenedor para su API principal, escrito en C #. Esto se hizo cuando los clientes lo exigieron, para que pudieran volver a escribir sus aplicaciones en C #. Es creado por un script Perl, que lee los archivos de encabezado C para la API, más un archivo de configuración significativo, y escribe el código C # para el contenedor. Hacer todo ese procesamiento de texto en Perl fue simplemente más fácil que hacerlo en C ++.
Tiene sistemas de compilación propios, y los necesita, porque el lenguaje de dominio no es apto para sistemas de compilación basados en creación. El de las plataformas tipo UNIX está escrito en scripts de shell, Perl y algunos pequeños programas en el lenguaje de dominio. El de las plataformas Windows está escrito en lenguaje por lotes, Perl, y los mismos pequeños programas en el idioma del dominio. El antiguo sistema de compilación VMS se escribió en DCL, pero eso no se ha utilizado durante más de una década.
Hay algo de programación de YACC / Bison en el compilador para el idioma del dominio. Hay algunos códigos de prueba para plataformas Apple escritos en Objective-C ++. Algunos de los sitios web internos del equipo (utilizados para la gestión de proyectos, que no forman parte de los entregables) están escritos en ASP, y otros como scripts CGI en Perl.
Básicamente, esto comenzó como un proyecto para abordar un problema difícil, por lo que valió la pena crear herramientas especializadas, que todavía parecen más adecuadas para este trabajo que cualquier otra cosa disponible. El equipo considera que la programación es una habilidad que es algo independiente del lenguaje utilizado, por lo que están dispuestos a usar un nuevo lenguaje si facilita la tarea. Sin embargo, la moda no ocupa un lugar destacado en su lista de prioridades, por lo que no fragmentarán una tarea al introducir un nuevo lenguaje de forma gratuita.
La función de este código es el modelado matemático, utilizado en estaciones de trabajo y servidores (puedo hablar un poco más libremente si no identifico el producto). Actualmente es de unos 25 millones de LoC, con un tamaño de equipo total de aproximadamente cincuenta.
fuente
En algunos casos, hay una herramienta que debe usar (como el kit de herramientas de la interfaz de usuario de un sistema operativo) que es más fácilmente accesible desde un idioma determinado. Por ejemplo, en iOS y macOS, si desea escribir aplicaciones GUI usando UIKit y AppKit, escribir en Swift u Objective-C es la forma más rápida y fácil de hacerlo. (Puede haber enlaces para otros idiomas, pero pueden estar detrás de la última versión del sistema operativo con el que está compilando, por lo que es posible que no ofrezca todas las funciones).
Muy a menudo, lo que sucede es cuando una aplicación es multiplataforma, la lógica central de la aplicación está escrita en un lenguaje accesible para ambos, y las piezas específicas de UI / OS están escritas en cualquier idioma en el que trabajen de forma nativa.
Entonces, si está escribiendo una aplicación de Windows y macOS, puede escribir la lógica central en C ++ y usar C # para la interfaz de usuario en Windows y Swift para la interfaz de usuario en macOS. Esto ahorra tiempo porque no necesita escribir la lógica central dos veces y lidiar con diferentes conjuntos de errores en ambas aplicaciones, etc. Pero también permite una verdadera interfaz de usuario nativa que no atiende al mínimo común denominador entre plataformas como usar una biblioteca de interfaz de usuario multiplataforma lo haría.
fuente
Además del hecho de que algunos lenguajes de programación pueden ser más adecuados para algunas tareas específicas, existe la realidad práctica.
En la realidad práctica, hay 2 puntos especialmente importantes a considerar:
Y, por supuesto, a menudo hay partes específicas de una aplicación que tienen necesidades completamente diferentes, como:
Y además, hay bastantes herramientas utilizadas por una base de código sofisticada, muchas de las cuales permiten la personalización necesaria y complementos con otro idioma.
fuente
Además de los otros puntos correctos ya hechos: por
experiencia, muchas decisiones de lenguaje o entorno se toman por 'si tienes un martillo, todo parece un clavo', lo que significa que las personas tienden a usar las herramientas con las que están familiarizados.
Además, la introducción de un nuevo entorno o incluso un idioma es una inversión importante en licencias, capacitaciones, quizás hardware, y conlleva grandes pérdidas de tiempo productivo: procura, instala, configura y capacita cada semana en una empresa más grande, y básicamente terminas con un grupo de desarrolladores principiantes.
Básicamente, nunca hay tiempo para 'invertir' en un entorno o lenguaje más moderno o mejor adaptado, por lo que se quedan con lo que tienen hasta que ya no puede funcionar.
Específicamente a su pregunta, si varias personas / equipos están participando en el desarrollo de una solución, cada grupo tiende a apegarse a lo que mejor saben, por lo que la solución general tiene potencialmente múltiples idiomas y es desarrollo en múltiples entornos.
fuente
Esta pregunta (y algunas de las respuestas) parecen suponer que las aplicaciones son bloques de código monolíticos; este no es necesariamente el caso.
Su sitio web típico como Stack Exchange es en realidad un conjunto de servicios diferentes que se ejecutan independientemente uno del otro, con algún tipo de mensaje entre ellos. Estos servicios se pueden implementar (y generalmente se implementan) en diferentes idiomas, cada uno con sus propios puntos fuertes.
Trabajo en una pequeña plataforma de banca en línea, dirigida a bancos comunitarios y cooperativas de crédito más pequeñas. Esta plataforma tiene múltiples componentes: un front-end web, una capa de base de datos, una capa de comunicaciones de terceros, etc. Estas son todas aplicaciones independientes que se ejecutan en diferentes servidores con diferentes sistemas operativos. Tiene Javascript ejecutándose en el lado del cliente en el navegador, tiene páginas de construcción Perl en el lado del servidor, tiene múltiples servicios escritos en C ++ que actúan como una capa de abstracción entre el código Perl y el procesador central del banco, otro conjunto de aplicaciones C ++ que enrutar mensajes entre las diversas capas, un puñado de aplicaciones C ++ y scripts de Perl para monitorear el estado de varios procesos e informar su estado a un monitor interno, etc., etc., etc.
Todavía existen aplicaciones monolíticas, pero incluso pueden aprovechar diferentes idiomas por diferentes razones. Puede escribir el 90% de una aplicación en Java, pero use JNI para aprovechar C o C ++ para secciones más críticas de rendimiento.
fuente
Me gustaría señalar una instancia muy específica del motivo 'diferentes idiomas tienen diferentes fortalezas': FORTRAN.
Fortran se desarrolló originalmente para facilitar a los ingenieros el trabajo de análisis numérico, y desde entonces se ha hecho un gran esfuerzo para que los compiladores de Fortran emitan un código numérico muy eficiente. Por otro lado, desde aquellos primeros días, el uso de computadoras ha explotado en miles de direcciones, ninguna de las cuales involucra análisis numérico, y el desarrollo de lenguajes de programación ha seguido su ejemplo al ignorar el mundo "real" [perdón por el juego de palabras].
SO: Es hoy, y te encuentras trabajando para una empresa con un producto bastante extenso, la mayoría escrito en (digamos) Java (hablo de mi experiencia personal aquí) . Pero encuentra que una de las características principales del producto requerirá algún tipo de análisis numérico, y todos los mejores códigos para ese análisis en particular ya están disponibles en la red, en Fortran. Entonces, ¿Qué haces? Descargue uno de esos códigos Fortran, descubra su interfaz [es decir, los argumentos de la subrutina más alta], cree un contenedor JNI para él en C y empaquételo como una clase Java. BAM! Solo tienes que desarrollar en tres idiomas a la vez. [especialmente si encuentra que su código Fortran usa bloques COMUNES, es decir, almacenamiento estático, y tiene que modificarse para seguridad de subprocesos]
fuente
Porque programar no es una tarea. Incluso crear un producto no es una tarea. Existen múltiples tipos de tareas que se expresan mejor con diferentes idiomas.
Para hacerlo más concreto, supongamos algo simple como una aplicación independiente (hay más tareas que realizar para aplicaciones distribuidas).
Un producto necesita ser
Es muy poco probable que un lenguaje que pueda ser bueno para escribir el tiempo de ejecución de un producto sea tan bueno para armar un producto. Y así.
Sin embargo, incluso el proceso de escribir un producto puede no realizarse de manera óptima en 1 idioma.
Digamos que hay una gran cantidad de datos estructurados que se manejan en el producto. ¿Se conoce la estructura de los datos en el momento de la escritura? Si es así, querrá configurar alguna base de datos en el momento de la implementación. Esto se realiza de manera óptima en un lenguaje que puede generar el lenguaje que se compilará en su tiempo de ejecución.
Ahora, ¿qué pasa si la estructura de los datos puede cambiar de vez en cuando? Entonces necesita una forma estructurada de convertir nuevas construcciones de datos en código y configuración de base de datos. Esto se hace mejor en otro idioma.
¿Puedes hacerlo todo en el mismo idioma? Seguro. Pero su eficacia está determinada por la rapidez con que puede terminar un proyecto y qué tan resistente es a los cambios. Si gran parte de su trabajo se puede automatizar con herramientas ya existentes, alguien más puede hacer lo que le toma 3 meses en 2 días. Pero que alguien estaría usando otros idiomas para automatizar lo que haría a través de la repetición.
fuente
El desarrollo de software ha progresado hasta el punto en que puede usar diferentes lenguajes de programación en el mismo proyecto, y puede hacer que funcione.
Luego está la pregunta de por qué usarías más de un idioma.
Una razón es que los idiomas se vuelven obsoletos y se reemplazan lentamente por otros más nuevos, y si tienes suerte, eso se puede hacer poco a poco. Entonces su proyecto tendrá una mezcla de lenguaje antiguo y nuevo.
Otra razón es la situación en la que el lenguaje X es muy utilizado en la plataforma A, el lenguaje Y es muy utilizado en la plataforma B, pero el lenguaje Z es compatible con ambas plataformas. Entonces, el código común se escribe en el lenguaje Z, que luego se combina con X o Y, dependiendo de la plataforma.
Y a la gente le gusta usar código escrito por otros (en otras palabras, código en el que no tuvieron que pasar tiempo para escribirlo ellos mismos). Se sienten libres de usar código escrito por otros en cualquier idioma, y luego agregar código en el idioma que prefieran.
fuente