Nye studerende på datalogistudiet på Københavns Universitet er fra dette studieår blevet introduceret til programmeringsfaget med sproget F#.
Tidligere bestod pensum af to kurser baseret på henholdsvis ML og Java. Tanken er, at F# både kan bruges til funktionel og objektorienteret programmering, og dermed bliver det nemmere at slå en vigtig pointe fast.
»De starter med funktionel programmering, så imperativ og så objektorienteret. Med F# kan man bedre vise forskellene mellem tilgangsvinklerne. Det kunne ellers drukne i forskellig syntaks og typesystemer mellem sprogene,« forklarer lektor og studieleder Torben Mogensen fra Datalogisk Institut på Københavns Universitet til Version2.
Det er nemlig en væsentlig del af datalogifaget at kende til de forskellige tilgange til programmering, og specielt funktionel programmering har fået en genopblomstring, efter der i mange år hovedsageligt har været fokus på objektorienterede sprog som C++ og Java.
Det er imidlertid problematisk at fokusere på sprog, der i praksis udelukker nogle af de forskellige grundlæggende programmeringsparadigmer, og eksempelvis på forhånd definere, at en applikation til en smartphone skal skrives i Java.
»Noget af det, vi fortæller de studerende, er, at først skal de identificere problemet, og derefter skal de vælge den passende løsning,« siger professor Olivier Danvy fra Institut for Datalogi ved Aarhus Universitet til Version2.
Netop smartphone-platformene har åbnet for flere programmeringssprog, ligesom flere af de traditionelt objektorienterede sprog har fået udvidelser, der gør det muligt at programmere funktionelt.
Som udvikler bør man altså altid være opmærksom på lektionen fra datalogistudiet om, at selvom man er vant til at programmere i Java, så er det ikke sikkert, at objektorienteret er den bedste måde at løse det næste problem på.
»Det er stort problem, hvis programmøren ikke har frihed til at vælge,« siger Olivier Danvy.
Objektorienteret er overbrugt
Med objektorienterede sprog som en de facto-standard, så løber man ind i, at objektorienteret ikke altid er den bedste fremgangsmåde.
»Objektorienteret programmering er efter min mening blevet overbrugt og oversolgt. Hvis man eksempelvis laver et API til en grafisk brugerflade, så er det ikke nødvendigvis det mest fornuftige, at et museklik skal være et objekt,« siger Torben Mogensen.
Den objektorienterede tilgang har sin berettigelse, når objekter er den bedste måde at løse problemet på.
Men det er en udfordring, at mange problemer kan beskrives ud fra objekter, men det er i sig selv ikke ensbetydende med, at objektorienteret programmering er det bedste svar.
Et klassisk eksempel er banksystemet, hvor man kan betragte hver konto som et objekt, der indeholder en saldo og har metoder til at lægge et beløb til saldoen eller få oplyst saldoen.
Tilsvarende vil en transaktion kunne være et objekt, som indeholder to kontonumre, et beløb og oplysningen om, hvorvidt transaktionen er gennemført.
Det er eksempel på stateful programmering og kan være en god løsning. Men man kunne også designe banksystemet som stateless.
Eksempelvis kunne der være en funktion til renteberegning, som modtager et beløb og en rentesats. Selve funktionen indeholder kun metoden til at beregne et nyt beløb og er ikke knyttet til en bestemt konto.
En af fordelene ved at vælge sådan en stateless tilgang er, at den er forholdsvis let at skalere til mange parallelle processer for store datamængder.
»Objektorienteret programmering er er elegant til at løse modulære problemer. Funktionel programmering kan let køre parallelt, og det er én af grundene til, at det blevet populært,« siger Olivier Danvy.
Udnytter ikke nedarvning
Mange nyere sprog som C# giver mulighed for at programmere funktionelt, selvom sproget primært er objektorienteret. Man skal dog stadig som udvikler vælge den rigtige model til sin applikation.
»Især nybegyndere kan svært ved objektorienteret programmering. Mange programmerer i Java, men forstår ikke, hvad der sker, og udnytter for eksempel ikke nedarvning,« siger Torben Mogensen.
Noget af det vigtigste i objektorienteret programmering er ikke, hvorvidt man kan opdele sit problem i objekter, men lige så meget muligheden for nedarvning.
I banksystemet kan man således have en overordnet klasse kaldet Konto, og så kan nye kontotyper oprettes som nedarvende klasser, der tilføjer særlige egenskaber til kontoen.
En opsparingskonto kunne eksempelvis have en rente, der er variabel, snarere end en fast rente, eller en lønkonto kunne have en kassekredit.
Både opsparingen og lønkontoen ville arve egenskaber som saldo og muligheden for at få oplyst saldoen.
Nedarvning kan derfor være med til at gøre et stort system mindre komplekst, fordi hierarkiet med klasser giver en vis struktur i sig selv.
Tilsvarende kan der også være fordele ved at programmere efter et stateful paradigme, hvor de enkelte objekter husker på deres tilstand.
Svært at teste
Omvendt kan det også give problemer. Eksempelvis kræver parallelisering, at man holder nøje øje med, hvilke processer der afsluttes hvornår, og hvilke der stadig kører eller venter. Ellers risikerer man race conditions.
Derudover er stateful-programmer sværere at teste ved hjælp af eksempelvis unit tests, påpeger Torben Mogensen.
»Data i et objekt kan være svært at genskabe i en test. I funktionsprogrammering afhænger det udelukkende af de argumenter, du giver funktionen. Det kan du ikke være sikker på i objektorienteret programmering,« siger han.
Mange nyere programmeringssprog er vanskelige at kategorisere som tilhørende enten det ene eller det andet programmeringsparadigme.
Et sprog som Apples Swift er ligesom F# et sprog, der kan lidt af både objektorienteret og funktionelt.
Det samme gælder Javascript, som har udviklet sig fra primært at være til webbrug til både at blive brugt i mobilapplikationer og på serverdelen af webapplikationer.
