Por que não há tradutores automatizados de uma linguagem de programação para outra? [fechadas]

O maior problema não é a tradução real do código do programa, mas a portabilidade da API da plataforma.

Considere um tradutor PHP para Java. A única maneira viável de fazer isso sem incorporar parte do binário do PHP é reimplementar todos os módulos e APIs do PHP em Java. Isso envolve a implementação de mais de 10.000 funções. Comparado a isso, a tarefa de traduzir a sintaxe é fácil. E mesmo depois de todo esse trabalho que você não teria código Java, você teria algum tipo de monstruosidade que por acaso rodasse na plataforma Java, mas que estava estruturado como o PHP por dentro.

É por isso que as únicas ferramentas que vêm à mente são a tradução do código para implantá-lo, e não para mantê-lo depois. O GWT do Google "compila" o Java para JavaScript. O hiphop do Facebook compila o PHP em C.

Se você tiver um formato intermediário, poderá implementar algo que traduza um programa no Language X para esse formato, e também de esse formato para o Idioma Y. Implementar essas conversões para todos os idiomas que você está interessado e pronto, certo?

Bem, você sabe o que? Esse formato já existe: assembly. O compilador já faz a conversão "Language X to assembly" e os desmontadores para a conversão "assembly to Language Y".

Agora, a montagem não é uma ótima linguagem para fazer a conversão inversa, mas MSIL não é tão ruim assim. Faça o download do Reflector e você verá que ele tem opções para desmontar um assembly .NET em várias linguagens diferentes ( e plugins fornecem ainda mais). Então é bem possível pegar um programa em C #, compilá-lo para uma DLL (ou seja, MSIL), então usar o refletor para desmontá-lo em VB, C ++ / CLI, F # e um monte de outros. Claro, todos os outros trabalhos de conversão também. Pegue um arquivo F #, compile para uma DLL, use o Reflector para convertê-lo em C #.

Claro, os dois grandes problemas que você encontrará são:

1. O código é basicamente ilegível. O MSIL (mesmo com informações de depuração) remove muitas informações da fonte original, portanto, a versão traduzida não tem 100% de fidelidade (teoricamente, fazer uma conversão C # - > MSIL- > C # deve retornar o código original, mas não vai).
2. Muitas linguagens .NET têm suas próprias bibliotecas personalizadas (por exemplo, a biblioteca de tempo de execução VB, a biblioteca F # e assim por diante). Estes precisam ser incluídos (ou convertidos) quando você faz sua conversão também.

Não há realmente nada para se locomover # 2, mas você provavelmente poderia ficar em # 1 com algumas anotações adicionais no MSIL (via atributos, talvez). Isso seria um trabalho adicional, é claro.

Is it possible, at least in theory, to write 100% correct translator between all languages? What are the challenges in practice?

• Traduzir de uma linguagem mais estruturada para uma linguagem menos estruturada que ainda é Turing-completa, é sempre possível.
  • Esta afirmação deve ser vista em um sentido estritamente técnico: significa que o programa traduzido produzirá exatamente o mesmo resultado quando for executado.
  • Nada está implícito sobre a legibilidade do código traduzido ou a preservação das estruturas originais do programa.
• É possível traduzir de uma linguagem menos estruturada para uma linguagem mais estruturada, mas o código traduzido permanecerá em sua forma menos estruturada.

Por que você deseja converter um programa?

Ambos os idiomas, a fonte e o idioma de destino são compilados para o machinecode (virtual) mesmo assim *, portanto, por razões técnicas, não há necessidade de ter um compilador para outra linguagem de alto nível.

As linguagens são para humanos. Portanto, o requisito implícito da sua pergunta é: 'por que não há um tradutor que gere código ' legível , e a resposta seria (imho): porque se houver dois linguagens que são suficientemente diferentes, as maneiras pelas quais o 'código legível' é escrito são diferentes de uma forma que não exigiria apenas a tradução dos algoritmos, mas sim algoritmos diferentes.

Por exemplo, compare uma iteração típica em C e uma em lisp. Ou pythons 'one best way' com ruby idiomático.

Aqui, os mesmos problemas começam a aparecer em idiomas reais, como você traduz "Está chovendo gatos e cachorros" para algo com o significado de "Está derramando como se fosse de baldes" ao traduzir de inglês para alemão, você não é possível traduzir palavra por palavra, mas você precisa procurar o significado.

E 'significado' não é um conceito fácil de se trabalhar.

*) bem, há coffeescript ...

É teoricamente possível, mas quase inútil. Quase qualquer combinação de idiomas de origem e destino é possível, mas na maioria dos casos ninguém nunca iria querer olhar ou usar o resultado.

Um número razoável de compiladores tem como alvo C, simplesmente porque os compiladores C estão disponíveis para quase todas as plataformas existentes (e há geradores automáticos de compiladores que permitem projetar um processador e gerar automaticamente um compilador C que almeje seu novo processador ). Há também, é claro, um número razoável de implementações que visam os idiomas usados por várias máquinas virtuais, como .NET, JVM, C-- e LLVM.

FWIW, existe um tradutor de Java para D. Chama-se TioPort e foi usado em uma tentativa bastante séria de transponha SWT para D. O principal problema foi que teria sido necessário portar grandes porções da biblioteca padrão Java.

Embora não seja uma tradução de código por si só, o conceito de workbenches de idiomas mostra como algo semelhante a um Um tradutor 100% correto entre todas as línguas pode ser implementado.

Em nossa abordagem atual, o código-fonte é armazenado em formato textual. Durante a compilação, esses arquivos de texto legíveis por humanos são analisados em uma representação de árvore de sintaxe abstrata, que por sua vez é usada para gerar código de bytecode ou de máquina. Essa representação abstrata, no entanto, é temporária e interna ao compilador.

Na abordagem da linguagem de trabalho de trabalho, uma representação de árvore de sintaxe abstrata semelhante é o artefato armazenado permanente. Tanto o código da máquina quanto o código de 'fonte' textual são gerados com base nesta representação abstrata. Uma das conseqüências de tal método é que a representação abstrata do programa é, na verdade, agnóstica quanto à linguagem e pode ser usada para gerar código textual em qualquer linguagem implementada. Significa que uma pessoa pode trabalhar livremente em diferentes aspectos do sistema usando qualquer idioma que julgue ser o mais adequado, ou cada membro da equipe pode trabalhar no projeto compartilhado na língua com a qual está mais familiarizado.

Até onde eu sei, a tecnologia ainda está longe de ser usada no desenvolvimento mainstream, no entanto, existem vários grupos trabalhando nela de forma independente. Difícil dizer se algum deles cumprirá suas promessas, mas seria interessante ver isso acontecer.

Existem alguns tradutores automáticos. Se o seu objetivo é produzir código compilável, ao invés de código legível, é bem possível e ocasionalmente útil, não muito frequentemente. Famosa, o primeiro compilador C ++ não era na verdade um compilador, mas traduzia C ++ para uma fonte C (realmente complicada) que era então compilada pelo compilador C. Muitos compiladores podem gerar o código assembly a pedido - mas, em vez de cuspir o texto da montagem e depois traduzi-lo para código de máquina, eles normalmente podem gerar código de máquina diretamente.

Dada uma especificação completa da linguagem A, não é tão difícil, em princípio, escrever um programa que expresse suas diretivas em alguma linguagem B. Mas geralmente qualquer um que se dê ao trabalho escolherá algo realmente baixo para o "idioma B". : Código de máquina ou bytecode nos dias de hoje: O Jython é uma implementação do python que gera o código de byte java, que é interpretado pela VM Java. Não precisa se preocupar em escrever e compilar hierarquias de classes Java!

Isso é feito o tempo todo.

Todos os compiladores traduzem o "idioma principal", como C ++, para a linguagem de montagem nativa da máquina ou bytecode independente de arquitetura no caso de linguagens interpretadas.

Eu imagino que não é sobre isso que você está falando. Você provavelmente quer um tradutor que converta C ++ para algo como Java ou Python. Qual é o objetivo disso, embora? Na melhor das hipóteses, o resultado final terá exatamente a mesma eficiência que a fonte original. (Praticamente, vai ser muito pior.)

Se você quer apenas que o código seja traduzido para que possa lê-lo como um idioma que você entende, esse tradutor teria o oposto do efeito desejado. Você ficará com um monte de códigos enigmáticos, não intuitivos e ilegíveis.

Isso ocorre porque somente as coisas mais triviais são traduzidas diretamente de um idioma para outro. Muitas vezes, o que é simples em um idioma requer bibliotecas massivas para outro - ou pode ser completamente impossível. Portanto:

1. Se o programa é trivial, você pode obter um resultado decente. Mas então, se é tão simples, o que é mesmo o ponto de executá-lo através de um tradutor?
2. Se o programa não for trivial, o código será de baixa qualidade.

No final, a única maneira de escrever um bom código é escrevê-lo. Computadores simplesmente não podem - pelo menos não ainda - combinar humanos em questões de legibilidade, melhores práticas e elegantes soluções.

Resumindo, não vale a pena.

Não há tradutores de idiomas para linguagens de programação porque as linguagens de programação são incrivelmente complexas. Embora seja hipoteticamente possível, há muitos desafios.

O primeiro desafio é apenas nas práticas aceitáveis da linguagem. A conversão entre duas linguagens orientadas a objetos, como Java e C ++, é incrivelmente complexa e ambas são baseadas em C. O programa tradutor teria que ter um conhecimento perfeito das bibliotecas padrão para ambas as línguas e ser capaz de conhecer as diferenças de comportamento. Você teria que criar um dicionário massivo e, mesmo assim, as diferenças nos estilos de programação de programador para programador significariam que ele teria que adivinhar como realizar algumas mudanças.

Depois de obter a tradução da sintaxe, você terá que descobrir como converter uma construção na primeira linguagem para uma construção na segunda linguagem. Isso é bom se você está indo um objeto em C + + para um objeto em Java (comparativamente fácil que é), mas o que você faz com suas estruturas C ++? Ou as funções fora das classes C ++? Decidir como lidar com isso pode ser complicado, pois pode resultar em outro problema, ou seja, a criação de um objeto blob. O blob é um antipadrão que é bastante comum.

Esta não é uma lista completa dos problemas, mas são apenas dois e são grandes. Um dos meus professores mencionou que alguém convenceu seu empregador de que ele poderia fazer um código de máquina para C nos anos 80, mas não funcionou na época. Eu duvido que nunca haverá um que funcione totalmente.

O ponto de compilação é obter algo útil para o computador. ou seja, algo que pode ser executado. Por que compilar para algo que pode até ser um nível mais alto do que o que você escreveu?

Eu gosto mais da estratégia do .NET. Compile tudo para uma linguagem comum. Isso dá o benefício de as linguagens serem capazes de se comunicar sem a necessidade de criar compiladores de linguagem cruzada (N ^ 2) -N.

Por exemplo, se você tivesse 10 linguagens de programação, bastaria escrever 10 compiladores no modelo .NET e todos poderiam se comunicar entre si. Se você fez todos os compiladores de cross language possíveis, você precisaria escrever 90 compiladores. Isso é muito trabalho extra para pouco benefício.