it-swarm-eu.dev

Proč neexistují automatizovaní překladatelé z jednoho programovacího jazyka do druhého?

Většina programovacích jazyků je Turing kompletní, což znamená, že jakýkoli úkol, který lze vyřešit v jednom jazyce, lze vyřešit v jiném, nebo dokonce na Turingově stroji. Tak proč neexistují automatické překladače, které dokážou převádět programy z jakéhokoli daného jazyka do jiného jazyka? Viděl jsem několik pokusů o dva jazyky, ale vždy fungují pouze na omezené podmnožině jazyka a je obtížné je použít pro převod skutečných projektů.

Je možné, alespoň teoreticky, napsat 100% správný překladatel mezi všemi jazyky? Jaké jsou výzvy v praxi? Existují nějaké překladatelé, kteří pracují?

37
serg

Největším problémem není skutečný překlad programového kódu, ale portování platformy API.

Zvažte a PHP do Java překladač.) Jediným proveditelným způsobem, jak toho dosáhnout, aniž byste vložili část binárního PHP binárního kódu je doplnit všechny moduly PHP a API v jazyce Java. To zahrnuje implementaci více než 10 000 funkcí. Ve srovnání s tím je úloha skutečného překladu syntaxe snadná jako koláč. A i po tom všem, co funguje, byste neměli Java kód, měli byste nějaký druh nestvůry, ke kterému dochází na platformě Java platforma, ale to bylo strukturováno jako PHP zevnitř).

To je důvod, proč jediné takové nástroje, které přicházejí na mysl, jsou všechno o překladu kódu, který jej nasadí, nikoli o jeho následném udržování. Google GWT "kompiluje" Java do JavaScriptu. Facebook hiphop kompiluje PHP do C.

32
Joeri Sebrechts

Pokud máte přechodný formát, můžete implementovat něco, co překládá program do jazyka X do tohoto formátu a také z formátu do jazyka Y. Proveďte tyto převody pro všechny jazyky, které vás zajímají a máte hotovo, že?

No víš co? Takový formát již existuje: Shromáždění. Kompilátor již provádí konverzi „Jazyk X do sestavy“ a rozebírá konverzi „Sestavení do jazyka Y“.

Shromáždění nyní není tak skvělým jazykem pro zpětnou konverzi, ale MSIL ve skutečnosti není tak špatný. Stáhněte Reflector a uvidíte, že má možnosti rozebrat .NET sestavu na spoustu různých jazyků (a pluginy poskytují ještě více). Takže je docela možné vzít program v C #, zkompilovat jej na DLL (tj. MSIL), pak jej použít k rozebrání na VB, C++/CLI, F # a celý reflektor spoustu dalších. Samozřejmě, že všechny ostatní převody fungují také. Vezměte soubor F #, zkompilujte do DLL, použijte Reflector a převeďte jej na C #.

Samozřejmě jsou zde dva velké problémy:

  1. Kód je v podstatě nečitelný. MSIL (i s ladicími informacemi) odstraní mnoho informací z původního zdroje, takže přeložená verze nemá 100% věrnost (teoreticky provedením konverze C # -> MSIL-> C # by se vám měl vrátit původní kód, ale to zvyklý).
  2. Mnoho jazyků .NET má své vlastní knihovny (např. VB runtime knihovna, knihovna F # atd.). Tyto by měly být při převodu také zahrnuty (nebo převedeny).

Ve skutečnosti není co obejít # 2, ale pravděpodobně byste se mohli obejít # 1 s některými dalšími poznámkami v MSIL (možná pomocí atributů). To by samozřejmě byla další práce.

20
Dean Harding

Je možné, alespoň teoreticky, napsat 100% správný překladatel mezi všemi jazyky? Jaké jsou výzvy v praxi?

  • Překlad z více strukturovaného jazyka do méně strukturovaného jazyka, který je stále Turingův kompletní, je vždy možný.
    • Na toto tvrzení by se mělo pohlížet v přísně technickém smyslu: To znamená, že překládaný program bude mít po provedení přesně stejný výsledek.
    • O čitelnosti přeloženého kódu ani o zachování původních programových struktur se neuvažuje.
  • Je možný překlad z méně strukturovaného jazyka do více strukturovaného jazyka, ale přeložený kód zůstane ve své méně strukturované podobě.
20
rwong

Proč byste chtěli převést program?

Oba jazyky, zdrojový i cílový jazyk jsou stejně kompilovány do (virtuálního) strojového kódu *, takže z technických důvodů není nutné mít překladač do jiného jazyka vysoké úrovně.

Jazyky jsou pro lidi. Takže, implicitní požadavek vaší otázky zní: 'Proč neexistuje překladač, který generuje čitelný kód' a odpověď by bylo (imho): protože pokud existují dva jazyky, které se dostatečně liší, způsoby psaní „čitelného kódu“ se liší způsobem, který by nejen vyžadoval překlad algoritmů, ale také různé algoritmy.

Například porovnejte typickou iteraci v C a jednu v LISP. Nebo pythony „nejlepší způsob“ s idiomatickým Rubym.

Tady se začínají objevovat stejné problémy, jaké máte v reálných jazycích, jako když překládáte „prší kočky a psy“ do něčeho, co má význam „vylévá se, jako by to vypadalo z kbelíků“ při překladu z angličtiny do němčiny, nemůžete překládat Word by Word už, ale musíte hledat význam.

A „význam“ není snadné pracovat.

*) no, existuje coffeescript ...

10
keppla

Je to teoreticky možné, ale většinou k ničemu. Je možná téměř jakákoli kombinace zdrojového a cílového jazyka, ale ve většině případů by se nikdo nikdy nechtěl podívat na výsledek nebo použít.

Cílové C má spravedlivý počet kompilátorů jednoduše proto, že kompilátory C jsou k dispozici téměř pro každou existující platformu (a existují automatické generátory kompilátorů, které vám umožní navrhnout procesor a automaticky vygenerují kompilátor C, který zacílí na váš nový procesor). Existuje samozřejmě také řada implementací, které cílí na jazyky používané různými virtuálními stroji, jako jsou .NET, JVM, C-- a LLVM.

Klíčovým bodem je však to, že je to opravdu užitečné, pouze pokud zacházíte s cílem, což je v podstatě jazyk sestavení, který se používá pouze jako krok v procesu kompilace. Obzvláště obvykle chcete ne chcete, aby normální programátor četl nebo pracoval s tímto výsledkem; obvykle to nebude moc čitelné.

6
Jerry Coffin

FWIW, existuje překladač z Java do D. Jmenuje se TioPort ) a byl použit v celkem vážném pokusu o port SWT na D. Hlavní problém, na který narazil bylo, že by bylo nutné portovat obrovské části standardní knihovny Java standardní knihovna).

5
dsimcha

I když nejde o překlad kódu jako takový, koncept jazykové pracovní stoly ukazuje, jak by bylo možné implementovat něco podobného 100% správnému překladateli mezi všemi jazyky.

V našem současném přístupu je zdrojový kód uložen v textovém formátu. Během kompilace jsou tyto textové soubory čitelné člověkem analyzovány do abstraktní reprezentace stromů syntaxe, která se zase používá ke generování bajtkódu nebo strojového kódu. Tato abstraktní reprezentace je však dočasná a interní pro kompilátor.

V přístupu jazyka workbench je podobná abstraktní stromová reprezentace syntaxe trvalým uloženým artefaktem. Strojový kód i textový „zdrojový“ kód jsou generovány na základě této abstraktní reprezentace. Jedním z důsledků takové metody je to, že abstraktní reprezentace programu je ve skutečnosti jazykově agnostická a lze ji použít ke generování textového kódu v jakémkoli implementovaném jazyce. Znamená to, že jedna osoba může volně pracovat na různých aspektech systému pomocí kteréhokoli jazyka, který považuje za nejvhodnější, nebo každý člen týmu může pracovat na sdíleném projektu v jazyce, kterému je nejvíce obeznámen.

Pokud vím, tato technologie není zdaleka použitelná při vývoji hlavního proudu, nicméně na ní pracuje několik skupin nezávisle. Těžko říct, zda někdo z nich splní své sliby, ale bylo by zajímavé vidět, že se to stane.

4
scrwtp

Tam jso některé automatické překladače. Pokud je vaším cílem vytvořit komprimovatelný kód, nikoli čitelný, je to docela možné a občas užitečné, jen ne velmi často. Je skvělé, že první kompilátor C++ nebyl ve skutečnosti kompilátor, ale přeložil C++ do (opravdu komplikovaného) zdroje C, který byl kompilován kompilátorem C. Mnoho kompilátorů může generovat kód sestavy na vyžádání - ale místo toho, aby vyplivli text sestavy a poté jej přeložili do strojového kódu, mohou normálně generovat strojový kód přímo.

Vzhledem k úplné specifikaci jazyka A ​​není v zásadě tak těžké napsat program, který vyjadřuje své směrnice v některém jazyce B. Ale obvykle ten, kdo se dostane do potíží, si pro „jazyk B“ vybere něco opravdu nízkého: Strojový kód , nebo v těchto dnech bytecode: Jython je implementace python, která generuje Java bajtový kód), který je interpretován pomocí Java = VM. Není třeba obtěžovat psaní a kompilaci Java hierarchie tříd!

4
alexis

Děje se to pořád.

Každý kompilátor překládá „primární jazyk“, jako je C++, do nativního jazyka assembleru stroje nebo bytecode nezávislého na architektuře v případě interpretovaných jazyků.

Představuji si však, že o tom nemluvíš. Pravděpodobně budete chtít překladatel, který převádí C++ na něco jako Java nebo Python.) Co je na tom, ale? V nejlepším případě bude konečný výsledek mít stejnou účinnost jako původní zdroj. ( Prakticky to bude mnohem horší.)

Pokud chcete pouze přeložit kód, abyste jej mohli číst jako jazyk, kterému rozumíte, měl by takový překladatel opak požadovaného účinku. Zůstane vám zabitý kryptický, neintuitivní a nečitelný kód.

Důvodem je, že pouze ty nejvýznamnější věci se překládají přímo z jednoho jazyka do druhého. To, co je jednoduché v jednom jazyce, často vyžaduje masivní knihovny pro další - nebo to může být úplně nemožné. Proto:

  1. Pokud je program triviální, můžete získat slušný výsledek. Ale pak, pokud je to tak jednoduché, co to vlastně má za cíl proložit překladačem?
  2. Pokud je program netriviální, bude mít kód nízkou kvalitu.

Nakonec jediný způsob, jak napsat dobrý kód, je napsat ho skutečně. Počítače prostě nemohou - alespoň ještě ne - porovnávat lidi v otázkách čitelnosti, osvědčených postupů a elegantních řešení.

Zkrátka prostě to nestojí za to.

3
Maxpm

Neexistují překladatelé jazyků pro programovací jazyky, protože programovací jazyky jsou neuvěřitelně složité. I když je to hypoteticky možné, existuje mnoho výzev.

První výzva spočívá pouze v přijatelných praktikách jazyka. Převod mezi dvěma objektově orientovanými jazyky jako Java a C++ je neuvěřitelně složitý a oba jsou založeny na C. Překladatelský program by musel mít dokonalou znalost standardních knihoven pro oba jazyky a měl by být schopen znáte rozdíly v chování. Museli byste vytvořit masivní slovník a dokonce i rozdíly v programovacích stylech od programátora k programátorovi by znamenaly, že by se muselo hádat, jak provést některé změny.

Poté, co jste dostali překlad syntaxe dolů, pak musíte přijít na to, jak převést konstrukt v prvním jazyce na konstrukt v druhém jazyce. To je v pořádku, pokud jdete objektem v C++ na objekt v Java (poměrně snadno to je)), ale co děláte se svými strukturami C++? Nebo funkce mimo třídy C++ „Rozhodování o tom, jak to zvládnout, může být složité, protože to může mít za následek další problém, jmenovitě vytvoření objektu blob. Blob je dostatečně protijedoucí.

Toto není úplný seznam problémů, ale jsou to jen dva a jsou to velké. Jeden z mých profesorů zmínil, že někdo přesvědčil svého zaměstnavatele, že v 80. letech vyrobí strojový kód do C, ale pak to nefungovalo. Pochybuji, že bude někdy fungovat úplně.

1
indyK1ng

Smyslem kompilace je získat něco užitečného pro počítač. tj. něco, co může běžet. Proč kompilovat s něčím, co může být dokonce na vyšší úrovni, než co jste napsali?

Líbí se mi strategie .NET lépe. Zkompilujte vše do společného jazyka. To poskytuje výhodu jazyků, které jsou schopny komunikovat, aniž by bylo nutné vytvářet překladače (N ^ 2) -N křížových jazyků.

Například, pokud jste měli 10 programovacích jazyků, museli byste napsat pouze 10 kompilátorů pod model .NET a všichni mohli spolu komunikovat. Pokud jste vytvořili všechny možné překladače více jazyků, budete muset napsat 90 překladačů. To je spousta práce navíc pro malý užitek.

1
mike30