http://sange.fi/~atehwa/cgi-bin/piki.cgi/ Recent changes in haskell http://sange.fi/~atehwa/cgi-bin/piki.cgi/haskell http://sange.fi/~atehwa/cgi-bin/piki.cgi/#1291724181 <p><ins>Noin lähtökohtaisesti Haskell on paras ohjelmointikieli, joka on olemassa. Sen kuvausvoima on suuri, käyttö hauskaa ja toteutus selkein käytännön osoitus siitä, että sivuvaikutukseton ohjelmointi ("pure functional programming") voi olla käytännöllistä. On tarvittu melkoinen määrä tutkimustyötä, että asiat on saatu käytännöllisiksi Haskellin lähtökohdista; nyt, kun tuo tutkimustyö on tehty, ihmiset pystyvät kirjoittamaan ihan oikeasti käyttökelpoisia ohjelmia ympäristössä, jossa samalla voi käyttää äärettömiä tietorakenteita, automaattista tyyppitarkistusta ja kaikkea muuta kivaa. Haskelliin upotettu tutkimustyö on myös tuottanut lisää ymmärrystä ja ennen kaikkea käytännön kokemusta predikaattilogiikkaa vahvemmista logiikoista sekä kategoriateoreettisista rakenteista.</ins> <p><ins>Minun kantani Haskellin merkittävyyteen lienee tyypillinen Scheme-geekeille. Kaikki suunnitteluvalinnat, mitä Haskellissa on tehty, vaikuttavat minusta siltä, että ne lisäävät kielen (ja varsinkin sen toteutusten) arvoa. Haskellissa ei ole mitään "vikaa" - jos ei oteta huomioon joitain makumieltymyksiä syntaksista, tai joitain pieniä komplikaatioita, joita [laiska evaluaatio] aiheuttaa (lähinnä laiskuusoperaattori kuviosovituksissa?). Vahva, staattinen, implisiittinen tyypitys säästää paljon ohjelmoijien vaivaa.</ins> <p><ins>Joskus on kuitenkin hyvä muistaa, että myöskään kielen ''toteuttamisen'' ei tarvitsisi olla näin vaativaa. On olemassa ohjelmointikielten tyyppijärjestelmiä, jotka ovat yhtä turvallisia kuin Haskellin tyyppijärjestelmä, sallivat (vähintään) samat ohjelmat kuin Haskellin tyyppijärjestelmä, eivätkä tuota ohjelmoijalle tippaakaan enemmän kirjoitus- tai muutakaan vaivaa. Tällainen ratkaisu on vahva, dynaaminen, implisiittinen tyypitys. Staattinen tyypitys on monimutkainen ja jännittävä ongelma, johon jää helposti koukkuun: on houkutus todistaa oikein kirjoitettujen ohjelmien olevan oikein kirjoitettuja, koska sen ''voi'' tehdä, ja mitä kuvausvoimaisempi tyyppijärjestelmä on, sitä useammille ohjelmille sen voi tehdä. Mutta joskus on hyvä muistaa, että aina ei ohjelmien tyypittäminen staattisesti (ennen ajoa) ole vaivan arvoista; kuljettakoot tietorakenteet tyyppitietoa mukanaan, jolloin tyyppivirheet raportoidaan, kun niitä tapahtuu, ja staattisen tyypityksen sääntöjä noudattavat ohjelmat voi kuitenkin todistaa toimiviksi erillisellä (automaattisella) koodianalyysilla.</ins> <p><ins>(Seuraavassa kohdassa en ihan tarkkaan tiedä, mistä puhun. Saa tarkentaa/korjata.) On myös ongelmia, joihin todistettavasti Haskellin tyyppijärjestelmä (tai mikään staattinen tyyppijärjestelmä) ei pysty koskaan "vastaamaan" eli todistamaan niillä kirjoitettuja ohjelmia toimiviksi: sellainen on eval, eli funktio, jolle annetaan mielivaltainen ohjelma argumentiksi (jonain tietorakenteena) ja joka palauttaa sen arvon, jonka tämä ohjelma palauttaisi ajettuna. Eval ei ehkä kuulosta tärkeältä, mutta tietokoneen käyttöjärjestelmässä on olennaista, että ohjelmat voivat tehdä uusia ohjelmia ja ajaa niitä. Haskellissa tämä pitää hoitaa jotenkin muuten kuin puhtaan kielen sisällä. On vähän vaikeaa kuvitella käyttöjärjestelmää, jossa on "puhdas" Haskell-ympäristö ilman sivuvaikutuksia tarkasti tyypitettyine arvoineen, kun taas vastaavat Lisp- ja Prolog-ympäristöt ([Yggdrasil]?) ovat helppoja kuvitella.</ins> <p><ins>''Käytännössä'' yleinen fiilikseni on se, että muutenkin asiat tulevat ns. "ihan vitusti helpommiksi", jos tietorakenteisiin (kuten listoihin) saa tunkea mitä tahansa olioita/tietorakenteita ja jos esim. ohjelmaa debugattaessa saa "smashata" eli muuttaa jonkin funktion määrittelyä tai tietorakenteen sisältöä siten, että ohjelman toiminnan jatkuessa käytössä on uusi funktio / tietorakenne. Staattinen tyypitys estää ensiksi mainitun ja sivuvaikutuksettomuus jälkemmäisen. Haskellia suunniteltaessa ei toki koskaan olekaan oltu niin puristeja, ettei ghc tarjoaisi "epäpuhtaita" rajapintoja tällaiseen. Itse arvostan REPL:n olemassaoloa, reflektiota ja ajonaikaista debuggausta sen verran, että haluan mieluummin lähtökohtaisesti dynaamisesti tyypitetyn kielen ajonaikaisella nimien sidonnalla, kuin staattisesti tyypitetyn kielen kääntäjällä.</ins> <p><ins>Haluan kielen, joka on periaatteessa dynaamisesti tyypitetty ja tekee silloin tällöin staattisia optimointeja, mieluummin kuin kielen, joka on staattisesti tyypitetty, jossa ohjelman ajonaikainen muuntelu on mahdotonta tai tehdään jollain epäpuhtaalla ja epästandardilla erikoisrajapinnalla ja jossa dynaamisesti tyypitetyt tietorakenteet pitää kirjoittaa itse (alkaen esim. "symbolin" määrittelystä).</ins> <p><ins>----</ins> <p><ins>[kategoria: ohjelmointi]</ins> Tue, 07 Dec 2010 12:16:21 +0000