Perché non ci sono traduttori automatici da un linguaggio di programmazione a un altro? [chiuso]

Il problema più grande non è l'effettiva traduzione del codice del programma, ma il porting dell'API della piattaforma.

Considera un traduttore da PHP a Java. L'unico modo fattibile per farlo senza incorporare parte del binario PHP è quello di reimplementare tutti i moduli e le API di PHP in Java. Ciò comporta l'implementazione di oltre 10.000 funzioni. Rispetto a questo il compito di tradurre effettivamente la sintassi è facile come una torta. E anche dopo tutto questo lavoro non avresti il codice Java, avresti una sorta di mostruosità che si verifica per funzionare sulla piattaforma Java, ma che era strutturata come PHP all'interno.

Questo è il motivo per cui gli unici strumenti che vengono in mente riguardano la traduzione del codice per implementarlo, non per mantenerlo in seguito. Google GWT "compila" Java in JavaScript. L'hiphop di Facebook compila PHP in C.

Se hai un formato intermedio, allora potresti implementare qualcosa che traduce un programma in Language X a che formatta, e anche da che formattano in Language Y. Implementare quelle conversioni per tutte le lingue che ti interessano e il gioco è fatto, giusto?

Beh, sai una cosa? Un tale formato esiste già: assemblaggio. Il compilatore esegue già la conversione "Language X to assembly" e i disassemblatori alla conversione "assembly to Language Y".

Ora, l'assemblaggio non è un gran linguaggio per fare la conversione inversa, ma MSIL non è poi così male. Scarica Reflector e vedrai che ha le opzioni per disassemblare un assembly .NET in un mucchio di lingue diverse ( e i plugin forniscono ancora di più). Quindi è abbastanza possibile prendere un programma in C #, compilarlo in una DLL (cioè MSIL), quindi usare reflector per disassemblarlo in VB, C ++ / CLI, F # e un gruppo di altri. Naturalmente, anche tutte le altre conversioni funzionano. Prendi un file F #, compila una DLL, usa Reflector per convertirlo in C #.

Ovviamente, i due grandi problemi che troverai sono:

1. Il codice è fondamentalmente illeggibile. MSIL (anche con informazioni di debug) rimuove un sacco di informazioni dalla fonte originale, quindi la versione tradotta non ha fedeltà al 100% (in teoria una conversione di C # - > MSIL- > C # dovrebbe restituire il codice originale, ma non lo farà).
2. Molti linguaggi .NET hanno le proprie librerie personalizzate (ad esempio la libreria runtime VB, la libreria F # e così via). Questi dovrebbero essere inclusi (o convertiti) anche quando fai la tua conversione.

Non c'è davvero nulla per aggirare il n. 2, ma probabilmente potresti ottenere il n. 1 con alcune annotazioni aggiuntive nel MSIL (tramite attributi, forse). Questo sarebbe un lavoro aggiuntivo, naturalmente.

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

• La traduzione da un linguaggio più strutturato a un linguaggio meno strutturato che è ancora completo di Turing, è sempre possibile.
  • Questa affermazione dovrebbe essere vista in senso strettamente tecnico: significa che il programma tradotto produrrà esattamente lo stesso risultato quando viene eseguito.
  • Nulla è implicito sulla leggibilità del codice tradotto o sulla conservazione delle strutture del programma originale.
• È possibile tradurre da un linguaggio meno strutturato a un linguaggio più strutturato, ma il codice tradotto rimarrà nella sua forma meno strutturata.

Perché vorresti convertire un programma?

Entrambe le lingue, l'origine e la lingua di destinazione sono compilate comunque (virtuale) in machinecode *, quindi per motivi tecnici non è necessario avere un compilatore in un altro linguaggio di alto livello.

Le lingue sono per gli umani. Quindi, il requisito implicito della tua domanda è: "perché non c'è un traduttore che generi codice leggibile " , e la risposta sarebbe (imho): perché se ci sono due le lingue che sono sufficientemente diverse, i modi in cui il "codice leggibile" è scritto è diverso in un modo che non richiederebbe solo di tradurre gli algoritmi, ma prendere diversi algoritmi.

Ad esempio, confronta una tipica iterazione in C e una in lisp. O pitoni 'un modo migliore' con rubino idiomatico.

Qui cominciano ad apparire gli stessi problemi che hai nelle lingue reali, come se traducessi "Piove a catinelle" a qualcosa con il significato di "Si riversa come se fosse dai secchi" quando traduci dall'inglese al tedesco, non posso più tradurre parola per parola, ma devi cercare il significato.

E 'significato' non è un concetto facile su cui lavorare.

*) beh, c'è un coffeescript ...

È teoricamente possibile, ma per lo più inutile. Quasi tutte le combinazioni di lingue di origine e di destinazione sono possibili, ma nella maggior parte dei casi nessuno vorrebbe mai guardare o utilizzare il risultato.

Un buon numero di compilatori ha come target C, semplicemente perché i compilatori C sono disponibili per quasi tutte le piattaforme esistenti (e ci sono generatori automatici di compilatori che ti consentono di progettare un processore e generare automaticamente un compilatore C che si rivolge al tuo nuovo processore ). Ci sono anche, ovviamente, un buon numero di implementazioni che hanno come target le lingue utilizzate da varie macchine virtuali come .NET, JVM, C-- e LLVM.

Il punto chiave, tuttavia, è che è davvero utile solo se si considera che il target è fondamentalmente un linguaggio assembly usato solo come fase del processo di compilazione. In particolare, generalmente non vuoi che un normale programmatore legga o lavori con quel risultato; di solito non sarà molto leggibile.

FWIW, c'è un traduttore da Java a D. Si chiama TioPort ed è stato usato in un tentativo abbastanza serio di porta da SWT a D. Il problema principale in cui si è verificato era che sarebbe stato necessario eseguire il porting di porzioni massicce della libreria standard Java.

Anche se non è la traduzione di codice in sé, il concetto di ambienti di lavoro linguistici mostra come qualcosa di simile a un È possibile implementare il traduttore al 100% corretto tra tutte le lingue.

Nel nostro approccio attuale, il codice sorgente è memorizzato in un formato testuale. Durante la compilazione, quei file di testo leggibili dall'uomo vengono analizzati in una rappresentazione ad albero della sintassi astratta, che a sua volta viene utilizzata per generare un codice bytecode o un codice macchina. Questa rappresentazione astratta tuttavia è temporanea e interna al compilatore.

Nell'approccio del linguaggio workbench, una rappresentazione di albero della sintassi astratta simile è l'artefatto permanente memorizzato. Sia il codice macchina che il codice 'sorgente' testuale sono generati in base a questa rappresentazione astratta. Una delle conseguenze di tale metodo è che la rappresentazione astratta del programma è in realtà indipendente dal linguaggio e può essere utilizzata per generare codice testuale in qualsiasi linguaggio implementato. Significa che una persona può lavorare liberamente su diversi aspetti del sistema utilizzando qualsiasi lingua che ritengono più appropriata, oppure ogni membro del team può lavorare sul progetto condiviso nella lingua con cui ha più familiarità.

Per quanto ne so, la tecnologia è ancora lontana dall'essere utilizzabile nello sviluppo tradizionale, tuttavia ci sono diversi gruppi che lavorano su di essa in modo indipendente. Difficile dire se qualcuno di loro sarà all'altezza delle loro promesse, ma sarebbe interessante vederlo accadere.

Lì sono alcuni traduttori automatici. Se il tuo obiettivo è produrre codice compilabile, piuttosto che codice leggibile, è abbastanza possibile e occasionalmente utile, ma non molto spesso. Notoriamente, il primo compilatore C ++ non era in realtà un compilatore, ma traduceva C ++ in una sorgente C (molto complicata) che è stata poi compilata dal compilatore C. Molti compilatori possono generare codice assembly su richiesta, ma invece di sputare il testo assembly e quindi tradurlo in codice macchina, normalmente possono generare direttamente il codice macchina.

Data una specifica completa del linguaggio A, non è così difficile in linea di principio scrivere un programma che esprima le sue direttive in una lingua B. Ma di solito chiunque si metta in difficoltà sceglierà qualcosa di veramente di basso livello per "lingua B" : Codice macchina o in questi giorni bytecode: Jython è un'implementazione di python che genera codice byte java, che viene interpretato dalla Java VM. Non c'è bisogno di preoccuparsi di scrivere e compilare gerarchie di classi java!

Questo è sempre fatto.

Ogni compilatore traduce la "lingua primaria", come C ++, nel linguaggio assembly nativo della macchina o nel bytecode indipendente dall'architettura nel caso di lingue interpretate.

Immagino che non sia quello di cui stai parlando, comunque. Probabilmente vorresti un traduttore che converta il C ++ in qualcosa come Java o Python. Qual è il punto di questo, però? Nella migliore delle ipotesi, il risultato finale avrà esattamente la stessa efficienza della fonte originale. (Praticamente, sarà molto peggio.)

Se vuoi solo tradurre il codice in modo da poterlo leggere come una lingua che capisci, un tale traduttore avrebbe l'opposto dell'effetto desiderato. Ti verrà lasciato un gran numero di codice criptico, non intuitivo e illeggibile.

Questo perché solo le cose più banali traducono direttamente da una lingua all'altra. Spesso, ciò che è semplice in una lingua richiede enormi librerie per un'altra - o potrebbe essere impossibile del tutto. Pertanto:

1. Se il programma è banale, potresti ottenere un risultato decente. Ma poi, se è così semplice, qual è anche il punto di eseguirlo attraverso un traduttore?
2. Se il programma non è banale, il codice sarà di bassa qualità.

Alla fine, l'unico modo per scrivere un buon codice è scriverlo. I computer semplicemente non possono - almeno non ancora - abbinare gli umani a questioni di leggibilità, best practice ed eleganza soluzioni.

In breve, non ne vale la pena.

Non ci sono traduttori di lingue per i linguaggi di programmazione perché i linguaggi di programmazione sono incredibilmente complessi. Anche se è ipoteticamente possibile, ci sono molte sfide.

La prima sfida è semplicemente nelle pratiche accettabili della lingua. La conversione tra due linguaggi orientati agli oggetti come Java e C ++ è incredibilmente complessa e sono entrambi basati su C. Il programma di traduzione dovrebbe avere una perfetta conoscenza delle librerie standard per entrambe le lingue ed essere in grado di conoscere le differenze di comportamento. Dovresti creare un dizionario enorme e anche allora, le differenze negli stili di programmazione da programmatore a programmatore significherebbe che dovrebbe indovinare su come eseguire alcuni cambiamenti.

Una volta che hai ottenuto la traduzione della sintassi, devi quindi capire come convertire un costrutto nella prima lingua in un costrutto nella seconda lingua. Questo va bene se stai andando ad un oggetto in C ++ su un oggetto in Java (relativamente facile), ma cosa fai con le tue strutture C ++? O le funzioni al di fuori delle classi C ++? Decidere come gestirlo può essere complicato in quanto può causare un altro problema, ovvero la creazione di un oggetto blob. Il blob è un antipattern che è abbastanza comune.

Questo non è un elenco completo dei problemi, ma quelli sono solo due e sono grandi. Uno dei miei professori ha affermato che qualcuno ha convinto il suo datore di lavoro che è stato in grado di crearne uno da codice macchina a C negli anni '80, ma non ha funzionato allora. Dubito che ce ne sarà mai uno che funzioni pienamente.

Il punto di compilazione è quello di ottenere qualcosa di utile per il computer. cioè qualcosa che può funzionare. Perché compilarlo in qualcosa che potrebbe anche essere più alto di quello in cui lo hai scritto?

Mi piace la strategia di .NET meglio. Compilare tutto in un linguaggio comune. Ciò dà il vantaggio che i linguaggi siano in grado di comunicare senza la necessità di creare (N ^ 2) -N compilatori di linguaggi incrociati.

Ad esempio, se avessi 10 linguaggi di programmazione, avresti solo bisogno di scrivere 10 compilatori sotto il modello .NET e tutti potrebbero comunicare tra loro. Se hai creato tutti i possibili compilatori di lingue diverse, dovrai scrivere 90 compilatori. Questo è un lavoro extra per poco beneficio.