Diferența dintre un compilator și un interpret

După definițiile lor, diferența dintre un compilator și un interpret pare destul de clară:

• interpretul este un program care execută direct instrucțiuni scrise într-un limbaj de programare
• compilatorul este un program care transformă codul sursă într-un limbaj de nivel scăzut

Dacă se sapă mai adânc, totuși, se constată o oarecare confuzie între cele două.

De fapt, un interpretor ar putea traduce limbajul sursă într-o formă intermediară, pentru a grăbi execuția. Aceasta este ceea ce se întâmplă de obicei cu un limbaj care se bazează pe o mașină virtuală. Acest lucru conduce în mod natural la câteva întrebări:

Sunt toate limbajele care folosesc o mașină virtuală interpretate?

Toate sunt de fapt compilate?

Am putea spune ambele: un limbaj este mai întâi compilat într-o formă/un limbaj intermediar și apoi acest lucru intermediar este interpretat în momentul execuției. Ceea ce duce și la o altă problemă, un compilator și un interpret nu ar trebui gândite ca un singur program, ci mai degrabă ca un grup de programe, un sistem. Ceea ce dumneavoastră, în calitate de utilizator, considerați a fi un compilator poate include, de fapt, mai mult de un program. De exemplu, poate include un linker: un program care combină diferite fișiere obiect într-un singur fișier, astfel încât acesta să poată fi utilizat mai ușor. Ceva asemănător se poate spune despre un interpret.

Puteți să-mi spuneți totul despre compilatoare &Interprete?

Deci, care sunt toate piesele care compun un compilator sau un interpret? Ați putea căuta un răspuns precis și tehnic la astfel de întrebări în mediul academic. Sau puteți găsi discuții pe aceste teme pe StackOverflow.

Ceea ce contează cu adevărat pentru noi ca dezvoltatori, sau chiar pentru noi ca creatori ai unui limbaj, este care sunt diferențele în lucrul cu acestea. Ambele au avantaje și dezavantaje și, de fapt, unele limbaje pot avea atât un interpretor, cât și un compilator, sau mai multe. Asta este ceea ce vom vedea.

Principalul punct rămâne în picioare: un interpret execută codul acum, un compilator pregătește codul sursă pentru o execuție care vine mai târziu. Toate diferențele practice descind din aceste obiective diferite.

Cum distribuiți un program

În termeni practici, o diferență importantă este că un compilator generează un program de sine stătător, în timp ce un program interpretat are întotdeauna nevoie de interpretor pentru a rula.

După ce aveți un program compilat, îl puteți rula fără a fi nevoie să instalați nimic altceva. Acest lucru simplifică distribuția. Pe de altă parte, executabilul funcționează pe o platformă specifică: sisteme de operare diferite și procesoare diferite au nevoie de versiuni compilate diferite. De exemplu, un program C++ compilat poate funcționa pe un calculator cu un procesor x86, dar nu și pe unul cu un cip ARM. Sau ar putea funcționa pe un sistem Linux, dar nu și pe unul Windows.

Dacă aveți de gând să interpretați un program, puteți distribui aceeași copie utilizatorilor de pe diferite platforme. Aceștia vor avea însă nevoie de un interpretor care să funcționeze pe platforma lor specifică. Ați putea distribui fie codul sursă original, fie o formă intermediară. Un mod intuitiv de a privi un interpretor este următorul: este ca funcția eval din JavaScript. Funcționează oriunde funcționează JavaScript, dar are nevoie de un interpret JavaScript pentru acea platformă pentru a rula.

Suport pentru mai multe platforme

Aceasta este o diferență tehnică care duce la consecințe reale importante: este mai ușor să faci programe pentru mai multe platforme cu un limbaj de programare interpretat.

Aceasta pentru că, în cea mai mare parte, doar creezi un program pentru platforma interpretului. Interpretul însuși va fi cel care îl va traduce în forma adecvată pentru platforma reală (de exemplu, Windows/Linux și x86/ARM). Desigur, există totuși unele diferențe în fiecare platformă de care trebuie să fiți conștienți. Un exemplu obișnuit este caracterul separator de directoare.

În schimb, atunci când compilați un program, trebuie să vă ocupați singur de toate micile diferențe dintre fiecare platformă. Acest lucru se întâmplă în parte pentru că limbajele compilate tind să fie limbaje de nivel(e) scăzut, cum ar fi C++, deci vă oferă un acces mai redus la sistem și, prin urmare, mai multă responsabilitate. Dar un alt motiv este că toate bibliotecile pe care le folosiți trebuie să fie compatibile cu diferite platforme. Astfel, dacă ele nu suportă Windows, nu puteți suporta Windows.

Viteza are mai multe fețe

Din nou, în cazul vitezei, avem un fel de paradox: un compilator este atât mai rapid, cât și mai lent decât un interpretor. Mulți oameni știu că un program compilat este mult mai rapid decât unul interpretat, dar aceasta nu este imaginea de ansamblu. Un program compilat este mai rapid de executat decât un program interpretat, dar este nevoie de mai mult timp pentru a compila și executa un program decât doar pentru a-l interpreta.

Un compilator produce într-adevăr programe mai rapide. Acest lucru se întâmplă în mod fundamental pentru că trebuie să analizeze fiecare instrucțiune o singură dată, în timp ce un interpretor trebuie să o analizeze de fiecare dată. În plus, un compilator poate optimiza codul executabil pe care îl produce. Acest lucru se datorează atât faptului că știe exact unde va fi executat, cât și faptului că optimizarea codului necesită timp. Timp care ar face ca interpretarea să fie prea lentă.

Viteza de execuție versus viteza de dezvoltare

Ați putea crede că aceasta este o picătură: dacă compilați un program, acesta rulează mai repede, timpul de compilare nu contează. Aceasta este, de obicei, opinia vechii școli. Și, fără îndoială, programul rezultat este rulat de mai multe ori decât este compilat. Așadar, cui îi pasă dacă dezvoltarea durează mai mult timp? Ei bine, cu siguranță este nevoie de o atitudine de „bring the pain” față de dezvoltare care este oarecum admirabilă. Dar ce se întâmplă dacă câștigurile în timpul de execuție nu sunt relevante, în timp ce pierderile de productivitate în dezvoltare sunt semnificative?

Urmează una dacă creezi un sistem de operare și alta dacă faci o aplicație pentru selfie. Chiar și utilizatorii dvs. ar putea prefera o pierdere de viteză în timpul de execuție care nu este nici măcar sesizabilă, în schimbul obținerii mai rapide a funcțiilor. Nu există un răspuns universal: în unele contexte, productivitatea contează mai mult decât viteza, în altele este adevărat contrariul.

Misterele depanării

Există un alt aspect particular care ajunge să fie mai nesigur decât ceea ce s-ar părea: depanarea. Pe hârtie, depanarea este mai ușoară în timp ce se folosește un interpretor decât dacă se folosește un compilator. Acest lucru este adevărat din mai multe motive:

• cu interpretorul există o singură versiune a executabilului; nu aveți nevoie de o versiune de depanare pentru dezvoltare și una de lansare pentru utilizatorul final
• există mai puține erori specifice platformei folosind un interpretor
• din moment ce interpretorul transformă codul din mers, informațiile din codul sursă sunt în continuare disponibile
• din moment ce interpretul execută câte o instrucțiune pe rând, este mai ușor să găsești o greșeală

Diferența pe care o fac instrumentele de dezvoltare

În timp ce toate acestea sunt adevărate în practică, s-ar putea ca acest lucru să fie mai puțin relevant decât pare. De fapt, dacă vă gândiți la experiența dumneavoastră, probabil că veți descoperi că depanarea JavaScript este mai dificilă decât depanarea C++. De ce este așa? În parte este proiectarea limbajelor în sine. JavaScript folosește tipărirea dinamică, în timp ce C++ folosește tipărirea statică. Aceasta din urmă facilitează detectarea timpurie a greșelilor. Dar, în cele din urmă, totul se reduce la instrumentele de dezvoltare. Compilarea manuală a limbajului C++ este dificilă, așa că majoritatea oamenilor folosesc IDE-uri pentru a dezvolta cu acesta. Pe de altă parte, puteți folosi cu ușurință un editor de text și instrumente de linie de comandă pentru a dezvolta în JavaScript.

Acest lucru înseamnă că, în termeni practici, dacă dezvoltați cu C++, puteți depana și C++. În schimb, puteți dezvolta cu JavaScript fără să știți cum să faceți depanarea corectă în JavaScript.

Dispus acest lucru, dacă le punem în același context, fiecare cu un IDE excelent și instrumente de suport, situația revine la normal. Într-adevăr, multe medii interpretate sunt folosite de persoane care vor să învețe să folosească un nou limbaj. Este mai ușor să testezi și să găsești ce este corect și ce este greșit, uitându-te la ceea ce se întâmplă linie cu linie și în timp real.

Rezumat

Am văzut principalele diferențe care contează între un compilator și un interpretor. Mai important, am văzut că consecințele diferitelor filosofii sunt mai importante decât cele tehnice. Pe scurt, există culturi care vin la pachet cu anumite alegeri tehnice care ajung să fie relevante prin ele însele. Dacă doriți viteză și ușurință în dezvoltare, veți alege toate tehnologiile pentru viteză și nu doar una singură. Iar utilizatorii dvs. vă vor urma exemplul.

Este un aspect crucial la care trebuie să vă gândiți, mai ales dacă doriți să vă creați propriul limbaj de programare. Rasmus Lerdorf a creat PHP pentru a fi ușor de utilizat. Și, într-adevăr, a fost incredibil de ușor de utilizat în comparație cu alternativele, cel puțin la momentul creării sale. Dar a început mai mult ca o bibliotecă decât ca un limbaj. Și, deși s-a îmbunătățit foarte mult, încă suferă din cauza începuturilor sale. Încă se poate crea cod PHP bun, dar mai puțini dintre utilizatorii săi decât de obicei o fac. Pentru că dacă aveți nevoie doar de ceva care să funcționeze, de securitate, de mentenanță etc., toate celelalte vin mai târziu.

Dacă vreți să știți cum puteți construi practic un interpretor sau un compilator pentru limbajul dumneavoastră, ar fi bine să aruncați o privire la resursele pentru crearea unui limbaj de programare. Dacă doriți să învățați acest lucru și tot ceea ce aveți nevoie pentru a vă crea propriul limbaj, trebuie doar să alegeți o carte excelentă, îndrăgită de copii și adulți deopotrivă, despre cum să creați limbaje pragmatice și ușoare.

5 lucruri pe care trebuie să le faci bine atunci când construiești un limbaj

Recibeți lista de verificare prin e-mail și primiți mai multe sfaturi despre construirea de limbaje

.