Kääntäjän ja tulkin ero

Kääntäjän ja tulkin ero näyttää niiden määritelmien mukaan riittävän selvältä:

• Tulkki on ohjelma, joka suorittaa suoraan ohjelmointikielellä kirjoitettuja ohjeita
• Kääntäjä on ohjelma, joka muuntaa lähdekoodin matalan(er)tason kielellä

Jos kaivaa syvemmälle, näiden kahden välillä on kuitenkin jonkin verran epäselvyyttä.

Tulkki voisi itse asiassa kääntää lähdekielen välimuotoon suorituksen nopeuttamiseksi. Näin tapahtuu yleensä kielen kanssa, joka tukeutuu virtuaalikoneeseen. Tämä johtaa luonnollisesti joihinkin kysymyksiin:

Ovatko kaikki kielet, jotka käyttävät virtuaalikonetta, tulkattuja?

Ovatko ne kaikki itse asiassa käännettyjä?

Voidaan sanoa molempia: kieli käännetään ensin välimuotoon/kieleksi ja sitten tämä välimuoto tulkataan suoritusaikana. Mikä johtaa myös toiseen kysymykseen, kääntäjää ja tulkkia ei pitäisi ajatella yhtenä ohjelmana, vaan enemmänkin ohjelmaryhmänä, järjestelmänä. Se, mitä sinä käyttäjänä pidät kääntäjänä, voi itse asiassa sisältää useamman kuin yhden ohjelman. Siihen voi kuulua esimerkiksi linkittäjä: ohjelma, joka yhdistää eri objektitiedostot yhdeksi tiedostoksi, jotta sitä voidaan käyttää helpommin. Jotain vastaavaa voidaan sanoa myös tulkista.

Voitko kertoa minulle kaiken kääntäjistä & tulkeista?

Mitä kaikkia osia on siis kääntäjän tai tulkin osat? Tarkkaa ja teknistä vastausta tällaisiin kysymyksiin voisi hakea akateemisesta maailmasta. Tai voit löytää keskusteluja näistä kysymyksistä StackOverflowsta.

Meille kehittäjille, tai jopa meille kielen luojille, on todella tärkeää, mitä eroja niiden kanssa työskentelyssä on. Molemmilla on etuja ja haittoja, ja itse asiassa joissakin kielissä voi olla sekä tulkki että kääntäjä, tai useampi kuin yksi. Tämä on se, mitä tulemme näkemään.

Pääpointti on edelleen sama: tulkki suorittaa koodin nyt, kääntäjä valmistelee lähdekoodin myöhemmin tapahtuvaa suoritusta varten. Kaikki käytännön erot juontuvat näistä erilaisista tavoitteista.

Miten ohjelmaa levitetään

Käytännössä yksi tärkeä ero on se, että kääntäjä tuottaa itsenäisen ohjelman, kun taas tulkattu ohjelma tarvitsee aina tulkin suorittaakseen.

Kun sinulla on käännetty ohjelma, voit suorittaa sen ilman, että sinun tarvitsee asentaa mitään muuta. Tämä yksinkertaistaa jakelua. Toisaalta suoritettava toimii yhdellä tietyllä alustalla: eri käyttöjärjestelmät ja eri prosessorit tarvitsevat eri käännettyjä versioita. Esimerkiksi käännetty C++-ohjelma saattaa toimia tietokoneessa, jossa on x86-prosessori, mutta ei tietokoneessa, jossa on ARM-siru. Tai se voi toimia Linux-järjestelmässä, mutta ei Windows-järjestelmässä.

Jos aiot tulkata ohjelman, voit jakaa saman kopion käyttäjille eri alustoilla. He tarvitsevat kuitenkin tulkin, joka toimii heidän omalla alustallaan. Voit jakaa joko alkuperäisen lähdekoodin tai välimuodon. Intuitiivinen tapa tarkastella tulkkia on tämä: se on kuin JavaScriptin eval-funktio. Se toimii kaikkialla, missä JavaScript toimii, mutta se tarvitsee JavaScript-tulkin kyseiselle alustalle toimiakseen.

Alustarajat ylittävä tuki

Tämä on tekninen ero, joka johtaa tärkeisiin todellisiin seurauksiin: tulkatulla ohjelmointikielellä on helpompi tehdä alustarajat ylittäviä ohjelmia.

Tämä johtuu siitä, että suurimmaksi osaksi luodaan vain ohjelma tulkin alustalle. Tulkki itse kääntää sen oikeaan muotoon oikealle alustalle (esim. Windows/Linux ja x86/ARM). Kussakin alustassa on tietysti vielä joitakin eroja, joista sinun on oltava tietoinen. Yleinen esimerkki on hakemistojen erotinmerkki.

Kun sen sijaan käännät ohjelmaa, sinun on itse huolehdittava kaikista pienistä eroista kunkin alustan välillä. Tämä tapahtuu osittain siksi, että käännetyt kielet ovat yleensä matalan(kin) tason kieliä, kuten C++, joten ne antavat sinulle pienemmän pääsyn järjestelmään ja siten enemmän vastuuta. Toinen syy on kuitenkin se, että kaikkien käyttämiesi kirjastojen on itse tuettava eri alustoja. Jos ne eivät siis tue Windowsia, et voi tukea Windowsia.

Nopeudella on useita kasvoja

Nopeuden kohdalla on taas eräänlainen paradoksi: kääntäjä on sekä nopeampi että hitaampi kuin tulkki. Monet tietävät, että käännetty ohjelma on paljon nopeampi kuin tulkattu, mutta tämä ei ole koko kuva. Käännetty ohjelma on nopeampi ajaa kuin tulkattu ohjelma, mutta ohjelman kääntämiseen ja ajamiseen kuluu enemmän aikaa kuin pelkkään tulkintaan.

Kääntäjä todellakin tuottaa nopeampia ohjelmia. Se tapahtuu pohjimmiltaan siksi, että sen täytyy analysoida jokainen lauseke vain kerran, kun taas tulkin täytyy analysoida se joka kerta. Lisäksi kääntäjä voi optimoida tuottamaansa suoritettavaa koodia. Tämä johtuu sekä siitä, että se tietää tarkalleen, missä se suoritetaan, että koodin optimointi vie aikaa. Aikaa, joka tekisi tulkkauksesta liian hidasta.

Latausajan nopeus vs. kehitysnopeus

Saatat ajatella, että tämä on pikkutarkkuutta: jos käännät ohjelman, se pyörii nopeammin, kääntämiseen kuluvalla ajalla ei ole merkitystä. Tämä on yleensä vanhan koulukunnan mielipide. Ja epäilemättä tuloksena syntyvä ohjelma ajetaan useammin kuin se käännetään. Joten ketä kiinnostaa, jos kehittämiseen kuluu enemmän aikaa? No, varmasti se vaatii ”tuo tuska” -asennetta kehittämiseen, joka on jossain määrin ihailtavaa. Mutta entä jos ajoaikavoitot eivät ole merkityksellisiä, kun taas kehitystyön tuottavuuden menetykset ovat merkittäviä?

On yksi asia, jos luot käyttöjärjestelmän ja toinen, jos teet selfie-sovelluksen. Jopa käyttäjät saattavat pitää parempana jopa huomaamatonta tappiota suoritusajan nopeudessa vastineeksi siitä, että he saavat ominaisuuksia nopeammin. Ei ole olemassa yksiselitteistä vastausta: joissakin yhteyksissä tuottavuus on tärkeämpää kuin nopeus, toisissa taas päinvastoin.

Virheenkorjauksen mysteerit

On eräs toinenkin erityinen näkökohta, joka päätyy epävarmemmaksi kuin mitä yksi näkökohta olisi: virheenkorjaus. Paperilla virheenkorjaus on helpompaa tulkkia käytettäessä kuin kääntäjää käytettäessä. Tämä on totta useista syistä:

• Tulkilla on yksi versio suoritettavasta tiedostosta; et tarvitse debug-versiota kehitystyötä varten ja release-versiota loppukäyttäjälle
• tulkkia käytettäessä on vähemmän alustakohtaisia virheitä
• , koska tulkki muuttaa koodia lennossa, lähdekoodin tiedot ovat edelleen käytettävissä
• kuten tulkki suorittaa yhden lausekkeen kerrallaan, virheet on helpompi löytää

Kehitystyökalujen merkitys

Mikäli tämä kaikki pitää käytännössä paikkansa, tämä saattaa olla vähemmän merkityksellistä kuin miltä näyttää. Itse asiassa jos ajattelet kokemuksiasi, huomaat todennäköisesti, että JavaScriptin virheenkorjaus on vaikeampaa kuin C++:n virheenkorjaus. Miksi näin on? Osittain johtuu kielten suunnittelusta. JavaScript käyttää dynaamista tyypitystä, kun taas C++ käyttää staattista tyypitystä. Jälkimmäinen helpottaa virheiden havaitsemista varhaisessa vaiheessa. Loppujen lopuksi kyse on kuitenkin kehitystyökaluista. C++:n kääntäminen käsin on vaikeaa, joten useimmat ihmiset kehittävät sitä IDE-ohjelmilla. Toisaalta JavaScript-kehitykseen voi helposti käyttää tekstieditoria ja komentorivityökaluja.

Tämä tarkoittaa käytännössä sitä, että jos kehität C++:lla, voit myös debugata C++:lla. Sen sijaan voit kehittää JavaScriptillä osaamatta tehdä kunnollista debuggausta JavaScriptillä.

Tämän sanottuamme, jos asetamme ne samaan kontekstiin, jossa kummallakin on loistava IDE ja sitä tukevat työkalut, tilanne palautuu normaaliksi. Monia tulkattuja ympäristöjä käyttävät todellakin ihmiset, jotka haluavat oppia käyttämään uutta kieltä. On helpompi testata ja löytää, mikä on oikein ja mikä väärin, katsomalla, mitä tapahtuu rivi riviltä ja reaaliajassa.

Yhteenveto

Olemme nähneet tärkeimmät erot, joilla on merkitystä kääntäjän ja tulkin välillä. Vielä tärkeämpää on, että olemme nähneet, että erilaisten filosofioiden seuraukset ovat tärkeämpiä kuin tekniset seuraukset. Lyhyesti sanottuna tiettyihin teknisiin valintoihin liittyy kulttuureja, jotka lopulta ovat merkityksellisiä yksinään. Jos halutaan nopeutta ja kehityksen helppoutta, valitaan kaikki nopeuteen liittyvät tekniikat eikä vain yhtä. Ja käyttäjät tulevat seuraamaan esimerkkiäsi.

Tämä on ratkaisevan tärkeä näkökohta, jota kannattaa miettiä, varsinkin jos haluaa luoda oman ohjelmointikielen. Rasmus Lerdorf loi PHP:n helppokäyttöiseksi. Ja todellakin se oli uskomattoman helppokäyttöinen vaihtoehtoihin verrattuna, ainakin sen luomisen aikaan. Mutta se alkoi enemmänkin kirjastona kuin kielenä. Ja vaikka se on parantunut paljon, se kärsii edelleen alkuajoistaan. Hyvää PHP-koodia voi edelleen luoda, mutta tavallista harvempi sen käyttäjä tekee niin. Koska jos tarvitset vain jotain, joka toimii, tietoturva, ylläpito ja niin edelleen, kaikki muu tulee myöhemmin.

Jos haluat tietää, miten voit käytännössä rakentaa tulkitsijan tai kääntäjän kielellesi, kannattaa vilkaista resursseja ohjelmointikielen luomiseen. Jos haluat oppia sen ja kaiken, mitä tarvitset oman kielen luomiseen, sinun tarvitsee vain valita loistava, niin lasten kuin aikuistenkin rakastama kirja siitä, miten luoda käytännöllisiä, kevyitä kieliä.

5 asiaa, jotka pitää tehdä oikein kieltä rakentaessa

Vastaanota tarkistuslista sähköpostitse ja saat lisää vinkkejä kielten rakentamiseen