Nörttitytön perehdytys funktionaaliseen ohjelmointiin

 N.M. Niskanen

Mainitsin viimeksi ohjelmointikielistä kirjoittaessani, että Scala on tätä nykyä ehdoton suosikkini kaikista koskaan oppimistani ohjelmointikielistä. Tämä johtuu luultavasti siitä, että opetellessani Scalaa sain samalla myös oivalluksen funktionaalisesta ohjelmoinnista. Wikipedia määrittelee lyhyesti sen seuraavasti:

Funktionaalinen ohjelmointi eli funktio-ohjelmointi on ohjelmointiparadigma, joka perustuu matemaattisten funktioiden käyttöön ja tarkemmin lambdakalkyyliin.

Image via XKCD.

 Jep. Sama suomeksi kiitos. Neil deGrasse Tyson sanoo omasta alastaan (astrofysiikka) jotakuinkin seuraavaa; tämä on tarpeeksi vaikeaa ilman, että haastetta tarvitsee lisätä turhan vaikeilla sanoilla. Olen täysin valmis allekirjoittamaan saman ohjelmoinnista.


Joten, funktionaalinen ohjelmointi on tapa ohjelmoida, jossa dataa syötetään matematiikan tunneilta tuttuun tapaan funktioihin, jotka palauttavat samalla datalla aina saman tuloksen. Tämä saattaa vaikuttaa itsestäänselvältä, mutta pitkään ohjelmointi on käytännön elämässä pyörinyt lähinnä vuokaaviomaisten tilamuutosten ympärillä. Näin ollen metodi ei aina palauta samaa tulosta samalla datalla. Tai tarkemmin sanottuna, samalla oliolla. Funktiolla ei myöskään ole sivuvaikutuksia ympäristöönsä, koska se ei muuta käyttämänsä datan tilaa.

Funktionaalinen ohjelmointi eli pitkään ainoastaan akateemisessa maailmassa huolimatta siitä, että Grace Hopper kirjoitti ensimmäisen kääntäjän nimenomaan funktionaalisen ohjelmoinnin mahdollistamiseen. Nainen kun oli matemaatikko ja halusi vain laskea. Ohjelmien monimutkaistuessa samanaikainen suorittaminen (concurrency näin tutummin) on muodostunut ongelmaksi, johon funktionaalinen ohjelmointi on osoittautunut loistavaksi parannuskeinoksi.

Samanaikaisuus on todellinen ongelma, kun yhtäaikaisten käyttäjien määrä kasvaa kasvamistaan ja kaikilla on omat tietonsa, joihin muilla ei ole asiaa. Viimeisin tunnettu, erityisen vakava esimerkki lienee erään verkkopankin uudistuksen yhteydessä tapahtuneet käyttäjä-istuntojen sotkeutumiset. Useissa tapauksissa asiakkaat saivat aivan tuntemattomien asiakkaiden tietoja näkyviin omaan käyttöliittymäänsä, joka on selkein samanaikaisuusongelmien ilmentymä. Vastaavasti esimerkiksi verkkokauppa, jossa ostoskoriin ilmestyy tuotteita, joita sinne ei ole lisännyt tai poistuu tuotteita, joita sieltä ei ole poistanut. Nykyään useat sovelluskehikot hoitavat suuren osan näistä ongelmista automaattisesti (tai käytännössä pienellä konfiguraatiolla).

Funktionaalinen ohjelmointi tarjoaa vaihtoehdon raskaille sovelluskehikoiden tarjoamille samanaikaisuusratkaisuille muuttamalla arvot muuttumattomiksi. Kun tämä yhdistetään funktioiden läpinäkyvyyteen, poistuvat samanaikaisuusongelmat ikään kuin automaattisesti. Suurin ongelma monisäikeisten ohjelmien tekemisessä kun on nimenomaan muuttuvan, jaetun datan synkronointi. Kun data ei muutu, ei tätä ongelmaa enää ole.

Jotta tämä nyt ei menisi liian korkealentoiseksi, jatketaan esimerkeillä.
Alla on esimerkki Javalla (selkeän imperatiivinen kieli) kirjoitetusta Fibonacci-lukujen erottelusta:

// Fibonacci sarja, Java tyyliin
public void fibonacci(int iterations){
    int first = 0; 
    int second = 1;
 
    system.out.println(first + ", " + second);
    for (int i = 0; i < iterations; ++i) {
        system.out.println(", ");
        int sum = first + second;
        first = second;
        second = sum;
        system.out.println(sum);
    }

}
 
public void main(String[] args)
{
    fibonacci(10);
}

Vertailun vuoksi vastaava toiminto Scalalla (Scalalla on mahdollista ohjelmoida sekä imperatiivisesti, että funktionaalisesti, mutta alla oleva esimerkki on funktionaalisesta näkökulmasta):

lazy val fib: Stream[Int] = Stream cons(0, Stream.cons(1, fib.zip(fib.tail).map(p => p._1 + p._2)))

fib.take(10).print

 Molemmat esimerkit tulostavat kymmenen ensimmäistä lukua Fibonacci sarjassa, molemmissa määritellään ensimmäiset kaksi lukua sarjassa, mutta siihen yhtäläisyydet loppuvatkin. Java-esimerkki kierrättää for-loopissa kunkin iteraation ja tulostaa tuloksen. Scala-esimerkki puolestaan käyttää hyväkseen zip-funktiota, joka yhdistää kaksi listaa toisiinsa, tässä tapauksessa 0 ja 1 summat kymmenen sarjassa. Eli siis 0,1; 1,1; 1,2; 2,3; 3,5... jne. Map-funktio puolestaan soveltaa p => p._1 + p._2 funktion jokaiseen zipin tuottamaan lukuun. Lopuksi vielä take(10) hakee kymmenen ensimmäistä sarjan lukua.

Scalan esimerkissä tuolla funktiosarjalla voisi edelleen toteuttaa uusia funktioita tai sen voi rikkoa osasiinsa, joita on helppo muokata ja testata, pitäen kuitenkin toiminnallisuuden samana. Tuo funktiosarja, fib, on myös itsessään yksi arvo/muuttuja ja siten uniikki, kun taas Java-versio määrittelee neljä eri muuttujaa, joista kaikki aiheuttavat mahdollisen ongelmatilanteen samanaikaisessa suorittamisessa. Jos fibonacci-metodi olisi vain osa luokkaa, jota kutsuttaisiin jostain muualta, voisi kahden yhtäaikaisen kutsun tapahtuessa yksi käyttäjä saada esimerkiksi 10 ensimmäistä lukua, haluttuaan vain 5 ja päinvastoin.

Funktionaalisen ohjelmoinnin kauneus on mielestäni siinä, että funktiot ovat luotettavia. Ne tekevät aina täsmälleen samoin ja aina täysin loogisesti. Ne voi pilkkoa pienimpiin osasiinsa, jossa ne on helppo testata. Päivätyössäni kirjoitan pääasiassa imperatiivista koodia, joka toimii välillä epäloogisen tuntuisesti, koska olion tila on muuttunut jossain huomaamattomassa kohdassa. Metodit kasvavat usein mittaviksi ja niitä on vaikea pilkkoa hallittavan kokoisiksi ja testaaminen on ajoittain vaikeaa ja hiuksia repivän turhauttavaa. Jos palaan Neil deGrasse Tysonin ajatukseen, funktionaalinen ohjelmointi tekee vaikeasta kokonaisuudesta sen verran helpompaa meidän yksinkertaisille aivoillemme.