1. Introdução

Desde os anos 70, o inglês simplificado vem se desenvolvendo, cujo objetivo é determinar um subconjunto do idioma que seja compreensível para uma ampla variedade de falantes não nativos do idioma. Recomendado, por exemplo, para documentação técnica. Tradutores automáticos nesse subconjunto funcionarão obviamente mais corretamente, gerando idealmente texto que não exija revisão manual.
Se você aplicar essa abordagem ao C # para a tarefa de converter código automaticamente para outras linguagens de programação, poderá selecionar um subconjunto de construções de idiomas, bibliotecas de sistemas e tecnologias que possam ser potencialmente traduzidas em uma ampla variedade de outros idiomas. Além disso, a conversão não é única (migração), mas constante para expandir os recursos de integração do projeto em C # - para que a qualquer momento você possa obter um código de trabalho em outro idioma sem a necessidade de edição.

Deixe-me apresentar: UniSharping

A restrição do C # .NET para resolver esse problema foi denominada U # (Universal Sharp), e o processo de conversão e sua ferramenta foram denominados UniSharping . Módulos executáveis, configurações e documentação estão disponíveis no GitHub , o sistema é gratuito para uso não comercial (Freeware não comercial).

Para a plataforma cruzada, a Microsoft já fez uma limitação do .NET Framework em termos de bibliotecas e tecnologias: .NET Core. É como o primeiro passo na direção certa, o U # dá o segundo passo para a "programação cruzada".

Havia poucas limitações de U # nas construções de linguagem - estas são goto e case goto atavismos, bem como rendimento, que não é modelado adequadamente no modo automático. Não é recomendado (embora seja possível) usar struct, existem nuances com nomes - tudo isso é descrito em detalhes em um documento separado. O analisador U # fornece erros e avisos e, para garantir a geração correta, você deve ajustar o código-fonte C # para que eles idealmente desapareçam completamente. Se você ainda precisar manter a versão original, poderá usar as diretivas de pré-processador #if JAVA || PHP ... #else ... #endif. Essas restrições se aplicam ao nível do mecanismo U # e não estão sujeitas a correção externa, bem como a lista de idiomas suportados.

Mas as restrições no nível das bibliotecas do sistema não são definidas rigidamente e são configuradas externamente através de arquivos de texto especiais que determinam como traduzir uma classe específica e seus membros para o idioma correspondente. Se houver um analógico direto, será indicado que, se a situação for mais complicada, será escrito um pedaço de código da linguagem final ou, em geral, uma classe especial (de serviço) que resolverá o problema desejado. Em casos muito difíceis, é necessário "codificar" no nível do mecanismo, mas essas situações são bastante raras (cerca de uma dúzia). O procedimento para configurar as classes do sistema e seus membros é descrito em um documento separado. Aqui está uma lista de classes C # suportadas e seus membros com análogos em Java e Python na versão atual no site, também há uma demonstração online .

Quanto à tecnologia, agora a lista está limitada aos aplicativos de console e testes de unidade (UnitTest). Bem, projetos Lib individuais, como um caso especial, são traduzidos para as construções correspondentes do idioma desejado.

Para uma tradução bem-sucedida, o projeto C # de origem (solução) deve ter uma parte de inicialização que verifique a funcionalidade no C # de origem. É bom que se trate de um extenso sistema de autotestes (UnitTest padrão em diferentes implementações ou escritas automaticamente), mas pelo menos deve haver pelo menos um aplicativo de console que funcione corretamente quando iniciado sem nenhuma intervenção do usuário. A necessidade disso é óbvia - após a geração para o idioma final, você pode verificar imediatamente o desempenho. Idealmente, todos os testes devem funcionar de maneira semelhante ao C #.

Histórico do projeto

A idéia de um conversor desse tipo existe há muito tempo. Meu principal projeto SDK Pullenti de processamento de linguagem natural é um candidato ideal para conversão: uma grande quantidade de código complexo e em constante aprimoramento. Para integrar com Java, tive que envolvê-lo em serviços da web, servidores tcp, etc.
No verão passado, encontrei tempo e energia para criar a primeira opção. Ele traduziu o projeto Pullenti para Java e também para ele.
Nos seis meses seguintes, o conversor se desenvolveu em vários projetos internos que estavam na empresa, principalmente por meio da expansão de classes de sistema.
Na primavera de 2018, surgiu a ideia de apoiar o Python, implementado no verão. Mas a inclusão de um segundo idioma não foi fornecida na versão inicial e acabou desajeitada. No verão, tive que refazer completamente o mecanismo para o potencial de vários idiomas finais. Além disso, as configurações de classes do sistema a partir do código rígido foram movidas para arquivos de texto externos. Espero que este conjunto não se expanda sem a sua ajuda.

Outros planos são os seguintes:

• puxe o Python para o nível Java. O Python agora é suportado no nível Pullenti, mas o Java foi muito além em outros projetos em comparação a ele.
• suporte PHP pelo menos no nível do projeto Pullenti.
• suporte C ++. Sim, eu sei que isso é muito difícil, pois não é claro ao liberar memória qual ponteiro é um link e para qual exclusão deve ser feita. Mas existem idéias ...

Quem pode ser útil

Principalmente aqueles que desenvolvem SDKs potencialmente multiplataforma em C #. Graças ao conversor UniSharping, o SDK também pode se tornar um "software cruzado", o que expandirá o círculo de usuários em potencial.
Recentemente, as posições STR se fortaleceram na Rússia, que se tornaram obrigatórias na maioria das agências governamentais e em algumas grandes empresas. Explique que o .NET Core também nem sempre funciona, porque é "Microsoft". Deixe alguma empresa desenvolver seu sistema de informação em C #. Para introduzir o produto na "empresa de código aberto", você pode selecionar a parte lógica do projeto (back-end), convertê-lo automaticamente em versões conforme necessário e transformar a parte visual (front-end) em software de código aberto. Ou seja, para continuar o desenvolvimento em C # e em Java apenas front-end.

Não excluo que, em princípio, a conversão de projetos da Web seja possível (com limitações, é claro), mas não tenho as habilidades e informações necessárias para isso. Se alguém vê essa oportunidade, é bem possível implementá-la no UniSharping.

Observo que, para um projeto C # complexo real, o suporte a Java ou outra linguagem exigirá algum esforço para modificar o código, destacar a parte portátil do projeto e envolvê-la com testes de unidade. Além disso, a configuração de classes e métodos ainda não suportados e a correção de erros do próprio UniSharping (com a minha ajuda) ainda é o trabalho. Mas o processo está convergindo, no final do qual o projeto espera um bônus entre programadores.