Go, eli oliko muuta korjattavaa kuin CREAT



Google – tai itse asiassa C:n syyllisenä tunnettu Ken Thompson ja hyvin pieni joukko muita Googlen työntekijöitä – ovat paljastaneet maailmalle kehittäneensä uuden keskimatalan tason ohjelmointikielen.

Julkilausumassa esitellään useita perusteita teolle. Ilmeistä kuitenkin on, että haetaan C:lle tappajaa. Tätä on yritetty ennenkin, eivätkä hyvätkään kielet ole siinä onnistuneet. Mitä tällä kertaa on tehty eri tavalla?

Automaattinen muistinhallinta on katsottu välttämättömäksi. Slicet ovat siisti tapa osoittaa mielivaltaisiin osiin arrayita. (Slicejen erityislaatuisuus Gon tyyppijärjestelmässä sen sijaan ei ole ihan niin siistiä. Tästä myöhemmin lisää.) Automaattisen muistinhallinnan puute tuomitsi C++:n epäoleellisten kuriositeettien joukkoon, mikä oli ilmeistä kaikille jo muutamassa vuodessa. Tässä Go on siis valinnut oikein.

Automaattisen muistinhallinnan filosofian seuraus on luonnollisesti, ettei kielessä voi tehdä pointteriaritmetiikkaa, paitsi osuvasti nimetyn unsafe-paketin kautta.

Mielenkiintoisena valintana eksplisiittinen tyyppihierarkia on jätetty pois. Implisiittisiä tyyppejä on saatettu kokeilla ennenkin, ainakin idea on vanha. Ei tule kuitenkaan mieleen yhtään tällaista kieltä, joten siinä mielessä valintaa on pidettävä rohkeana muuten melko konservatiivisten ratkaisujen seassa.

Jostain käsittämättömästä syystä Gossa – kielessä, jossa ei ole parametrisoitavia tyyppejä – on kokonaista viisi erilaista parametrisoitua tyyppiä: arrayt, slicet, mapit, pointterit ja kanavat. Lisäksi näistä slicet, mapit ja kanavat toimivat eri tavalla kuin kielen muut objektit. Minusta kieli olisi merkittävästi siistimpi, jos tässä vaiheessa olisi luovutettu ajatuksesta, ettei parametrisoitavia tyyppejä tarvita, hyväksytty tyyppiparametrit, tehty näistä kaikista parametrisoitavia tyyppejä ja, mikä tärkeintä, unohdettu make()n ja new()n erottelu. Tästä seuraisi se hinta, että slicejä, mapeja ja kanavia pitäisi erikseen käsitellä pointterien kautta, mutta toisaalta siitä olisi se etu, ettei tarvitse muistaa, että vaikka slicet, mapit ja kanavat näyttävät arvosemantiikan mukaisesti käyttäytyviltä (kuten numerot, stringit, jne), tosiasiassa niiden sisältöä voi muuttaa, jolloin parempi käsitemalli onkin referenssisemantiikka. Kielessä on siis kolme eri muuttujasemantiikkaa: arvot, referenssit ja pointterit, joista referenssejä ei syntaktisesti merkitä erikseen, vaan ne seuraavat automaattisesti siitä kun sliceja, mapeja ja kanavia käytetään arvoina. Kaksi semantiikkaa on yleisesti koettu riittäväksi.

Itse asiassa, jos kielessä olisi parametrisoitavat tyypit, voisi referenssien määrätä aina osoittavan johonkin, eli null pointerit olisivat oletuksena kiellettyjä. Niitä käyttötapauksia varten, joissa tyhjä osoitus on haluttava, olisi erillinen Maybe[T], joka on unionityyppi T-pointterista ja yksittäisestä null-arvosta. Rohkea nosto oikeista funktionaalisista kielistä ehkä, mutta Hoaren miljardin dollarin virhe olisi iso virhe korjattavaksi. Samalla vaivalla, kun suunnittelee uuden kielen pienten vikojen korjaamiseksi, voisi korjata isotkin, sikäli kun ne ovat tunnettuja.

Nämä kaikki huomiot ovat kuitenkin luonteeltaan teknisiä. Loppujen lopuksi tekniset ominaisuudet voivat vain upottaa kielen, eivät tehdä siitä menestystä. Tärkeämpi kysymys on: onko maailmassa tällä hetkellä tilaa uudelle kielelle? Aika näyttää. Googlella on vankka historia työkalujen itse tekemisestä, vaikka vastaavia olisi markkinoilla kuinka. Se, että Google on vaivautunut rahoittamaan kielen kehittämisen, ei ole todiste oikeastaan mistään.

Parin ensimmäisen vuoden aikana nähdään lähteekö Go lentoon vai ei. Jos Windows-versiota ei ilmesty vuoden sisään, ennuste on äärimmäisen kehno. Mutta ensisijaisesti uusi kieli tarvitsee ohjelmoijilta buy-inia, ja sitä ei tule ilman hyvää markkinointia. Google on tietysti maailman suurin markkinointifirma. Markkinointikampanjaa odotellessa.

Tämän artikkelin on kirjoittanut Teemu Kalvas ja sitä ovat sittemmin muokanneet muut Codenton työntekijät.

2 kommenttia artikkeliin ”Go, eli oliko muuta korjattavaa kuin CREAT

  1. Mitä tahansa sanotaankin, niin C on kyllä edelleen vahva omalla alueellaan, eli raudan lähellä. C:n tappajaksi on moni kieli havitellut, mutta menestystä on tullut vain laiterajapinnoista kauempana.

    Minusta tuntuu, että yksi tärkeä tekijä on C:n suoraviivaisuus. Se ei yritä abstraktoida vaikeita asioita. Tavallisessa sovelluskehityksessä isot abstraktiot nopeuttavat kehitystä, mutta ehkä Joelin vuotavat abstraktiot iskevät raudan lähellä nilkkaan nopeammin ja kipeämmin kuin muualla.

Vastaa

Sähköpostiosoitettasi ei julkaista. Pakolliset kentät on merkitty *