Esta resposta tem uma cobertura excelente e links sobre por que idiomas diferentes podem fornecer benefícios distintos para um projeto. No entanto, há muito mais do que apenas a adequação ao idioma envolvida no motivo pelo qual os projetos acabam usando vários idiomas.
Os projetos acabam usando vários idiomas por seis razões principais:
- Custo-benefício da reutilização de código escrito em outros idiomas;
- A necessidade de incluir e acomodar código legado;
- Disponibilidade de codificadores para idiomas específicos;
- A necessidade de idiomas especiais para necessidades especiais;
- Viés de idioma herdado; e
- Má gestão do projeto (uso não planejado em vários idiomas).
As razões de 1 a 4 são razões positivas no sentido de que abordá-las diretamente pode ajudar um projeto a concluir mais rapidamente, com mais eficiência, com um produto de melhor qualidade e com suporte a longo prazo mais fácil. Os motivos 5 e 6 são negativos, sintomas de resistência às mudanças necessárias, planejamento deficiente, gerenciamento ineficaz ou alguma combinação de todos esses fatores. Infelizmente, esses fatores negativos são causas comuns do uso multilíngue "acidental".
A razão 1 , os benefícios de custo da reutilização, tornou-se um motivo cada vez mais poderoso para permitir o uso de vários idiomas em um projeto devido ao maior papel do software de código aberto e aos recursos aprimorados para encontrar os componentes de código certos na web. A filosofia "vamos codificar tudo internamente" das últimas décadas continua a desaparecer diante das realidades econômicas e nunca é essencialmente a abordagem mais econômica para qualquer novo projeto. Isso, por sua vez, torna menos comuns as oportunidades de aplicação estrita do uso de um único idioma em um projeto.
Especialmente no caso de um projeto reutilizar componentes de código aberto bem gerenciados, o uso de vários idiomas pode oferecer enormes benefícios de custo geral, porque os componentes reutilizados estão ocultos por trás de interfaces bem projetadas e são mantidos independentemente por grupos externos de custo zero. Na melhor das hipóteses, misturar linguagens por esse tipo de reutilização não é mais caro para o projeto do que o uso de componentes do sistema operacional. Não conheço melhor exemplo do valor dessa abordagem do que a adoção em larga escala da Microsoft de software de código aberto em seus navegadores.
O motivo 2 , a necessidade de acomodar o código legado, é ignorado por qualquer projeto de grande porte. Por mais problemas que o código legado possa causar, ingenuamente, supor que possa ser substituído facilmente por um novo código em um novo idioma pode ser incrivelmente arriscado. Código legado, mesmo código legado ruim, geralmente inclui o que equivale a um "contrato" implícito de recursos esperados pela comunidade que usa o produto legado. Essa comunidade geralmente é uma importante fonte de receita para uma empresa ou o principal alvo de suporte para software governamental. Simplesmente descartar esse contrato implícito pode perseguir os clientes em massa, e pode levar a empresa à falência da noite para o dia, se outras opções estiverem prontamente disponíveis.
Ao mesmo tempo, não substituir o código antigo em um idioma antigo pode ser tão perigoso quanto substituí-lo por atacado. Um exemplo de pior caso é a Administração de Veteranos dos EUA, que possui um grande número de sistemas vitais codificados em uma linguagem chamada MUMPS (sem brincadeira), projetada por médicos, não cientistas da computação. Ninguém quer aprender MUMPS, e aqueles que sabem disso estão literalmente morrendo. Os programadores devem, portanto, acomodar o MUMPS, mesmo que tentem usar outras linguagens mais comuns, mais poderosas e com melhor manutenção.
Esse tipo de uso em vários idiomas requer um planejamento cuidadoso. Esse planejamento deve navegar entre a perda de décadas de conhecimento do cliente, por um lado, e a capacidade de oferecer suporte ao software, por outro. Técnicas que isolam o código antigo por trás de interfaces bem definidas e que permitem que um novo código mais poderoso substitua o código antigo depois que seus comportamentos foram bem documentados, podem ajudar. Mas esse cenário legado nunca é fácil e tem sido (e continuará sendo) a causa do desaparecimento de muitas empresas e organizações em um amplo espectro de tamanhos.
A razão 3 , disponibilidade de codificadores para vários idiomas, é um fator pragmático que os projetos ignoram por sua conta e risco. Por mais que os organizadores do projeto sintam (correta ou incorretamente) que um idioma específico é melhor para seus objetivos, se esse idioma estiver em conflito com o pool de conhecimentos linguísticos disponível, o cronograma e a qualidade do produto sofrerão com o aprendizado. curvado de programadores tentando aprender um novo idioma.
Uma abordagem mais racional é analisar as necessidades de linguagem do projeto com base em áreas funcionais. Por exemplo, olhar atentamente para o projeto pode mostrar que existe apenas um pequeno "ápice" de código de alto valor, por exemplo, para implementar algum algoritmo proprietário, que requer experiência em codificação em uma linguagem menos usada. Outras partes de qualquer projeto grande geralmente são facilmente acomodadas por idiomas mais comuns ou (ainda melhor) por produtos de código aberto bem gerenciados. Analisar um projeto de acordo com as necessidades de idiomas pode fornecer uma abordagem muito mais realista e econômica para contratar ou alugar conhecimentos especiais em idiomas especiais e também pode ajudar a aprimorar as interfaces entre os idiomas em um único projeto.
A razão 4 , usando idiomas diferentes para diferentes necessidades, segue imediatamente e sem problemas a realização desse tipo de análise das necessidades do projeto. Também deve-se ter cuidado com isso, pois a seleção de muitos idiomas para suporte em um único projeto pode causar uma explosão combinatória de complexidade, tanto no suporte quanto nas interfaces entre os componentes. A rota mais segura em termos de custo é sempre encontrar o máximo de oportunidades para reutilização primeiro, especialmente se existem bons pacotes que podem atender às necessidades do projeto por pouco mais do que personalização. Em seguida, algum tipo de decisão deve ser tomada em um pequeno número de idiomas que possa atender à maioria das necessidades identificadas. No desenvolvimento intensivo de reutilização, esse costuma ser um tipo de código de cola.
Geralmente, não é uma boa ideia escolher vários idiomas com recursos muito semelhantes apenas porque alguns membros do projeto gostam de um e outros. No entanto, se houver um subconjunto de recursos bem identificado e bem definido que se beneficiaria de habilidades especiais de idioma, esse pode ser um bom motivo para o uso de vários idiomas no desenvolvimento de novos códigos.
A razão 5 , resistência às mudanças necessárias nos idiomas usados, pode ser uma causa de grave interrupção do projeto e conflitos internos. Como usuário DaveoComo apontado em um comentário sobre esta resposta, a mudança pode ser muito difícil para alguns funcionários do projeto. Ao mesmo tempo, a resistência à mudança nunca é uma questão simples, e é exatamente por isso que pode causar muitos conflitos. O uso de habilidades linguísticas herdadas pode ser um poderoso impulso à produtividade de um projeto, se a linguagem herdada for suficientemente poderosa e pode levar a um produto com excelente qualidade em uma equipe que opera sem problemas e respeita a qualidade. No entanto, as habilidades de idioma herdadas devem ser equilibradas com o fato de que muitos idiomas mais antigos não podem mais ser concluídos com idiomas mais recentes em termos de recursos avançados, disponibilidade de componentes, opções de código aberto e suporte ao kit de ferramentas inteligente.
Tanto na época como agora, o argumento mais comum (e ironicamente, na maioria das vezes correto) de continuar usando uma linguagem legada mais fraca, menos legível ou menos produtiva é que a linguagem mais antiga permite a produção de código mais eficiente. Esse é um argumento antigo, que remonta à década de 1950, quando os usuários da linguagem assembly se ressentiram, muitas vezes amargamente, do surgimento da programação no FORTRAN e no LISP. Um exemplo em que até agora o argumento de eficiência de código pode ter validade pode ser visto no código de processamento intensivo, como um kernel de sistemas operacionais, em que C continua sendo o idioma de escolha do C ++ (embora por razões que vão além da simples eficiência).
No entanto, nos ambientes de projeto do novo milênio, com rede global e poderosamente suportados por máquinas, a eficiência do código como principal argumento para a escolha de uma linguagem de projeto ficou ainda mais fraca. A mesma explosão de hardware de computação e de rede que permitiu o marketing em massa de aplicativos de inteligência artificial também significa que os custos da programação humana podem facilmente reduzir os custos de execução ineficiente de código da relatividade em hardware e cloudware espetacularmente baratos. Quando isso é combinado com a maior disponibilidade em linguagens mais recentes de bibliotecas de componentes, opções de código aberto e kits de ferramentas inteligentes avançados, o número de casos em que a manutenção de uma linguagem apenas por razões de eficiência fica muito estreita. Mesmo nos casos em que se aplica,
Um motivo mais convincente para um projeto permanecer com idiomas herdados ocorre quando, por qualquer motivo, um projeto tem poucas ou nenhuma opção para alterar sua equipe. Isso pode acontecer, por exemplo, quando uma grande linha de produtos herdada é totalmente codificada em um idioma com o qual apenas a equipe existente é fluente. Nesses casos, o projeto deve continuar no caminho de tentar programar no idioma antigo ou tentar treinar a equipe existente em como usar um novo idioma.
Treinar a equipe de idiomas legada em um novo idioma pode ser um perigo por si só. Ainda me lembro de um caso em que um membro de um projeto que havia acabado de ser treinado e transferido de C para C ++ me queixou com toda sinceridade de que ele simplesmente não entendia as vantagens dos métodos orientados a objetos. Quando examinei seu código, ele havia convertido suas funções 103 C anteriores em 103 métodos para uma única classe de objeto C ++ ... e, por direito, não via como isso ajudava em nada.
A mensagem mais profunda é que, quando as pessoas programam em um único idioma e estilo de linguagem há anos ou décadas, a dificuldade de fazê-las "pensar" de novas maneiras pode se tornar quase intransponível, mesmo com bons programas de treinamento. Em alguns casos, pode não haver outra opção a não ser atrair designers e programadores mais jovens, que estejam mais de acordo com as tendências e métodos atuais.
Razão 6 , gerenciamento de projetos deficiente, fala por si. A seleção e o uso do idioma em um projeto devem sempre ser considerados e avaliados explicitamente, e não deve ocorrer por acidente. No mínimo, a seleção de idiomas pode fazer uma enorme diferença no destino a longo prazo e nos custos de suporte de um projeto, e portanto deve sempre ser levada em consideração e planejada. Não se torne um MUMPS!