Funktionell programmering

Håller jag inte med om överhuvudtaget.

Jag anser att "funktionell programmering" har två distinkt olika betydelser, där såväl språk som enskilda program något förenklat kan anses tillhöra den ena, båda två eller ingen av dem:

• Funktioner är värden.

  • För språk: Funktioner kan skickas som argument, returneras, tilldelas osv precis som heltal, strängar eller vilka andra värden som helst. Exempel: Haskell, JavaScript, Python, Kotlin.

  • För program: Ovanstående görs och dras nytta av i stor utsträckning. Går att göra i språk som tillåter det.

• Funktioner är rena (pure).

  • För språk: Det går bara att skriva rena funktioner. Exempel: Haskell, Agda.

  • För program: Rena funktioner skrivs och dras nytta av i stor utsträckning. Går att göra, åtminstone i viss grad, i så gott som alla språk.

C är definitivt inte funktionellt i den andra betydelsen, och jag tycker verkligen det är att ta i att kalla det funktionellt i den första betydelsen, trots funktionspekare.

C är INTE funktionell programmering, utan procedurell.

För att lyckas med funktionell programmering behöver du bryta dig loss ur tankesättet "Hur?" och istället tänka "Vad?". Istället för att tänka i sidoeffekter behöver du tänka i värden.

I ett imperativt språk tänker man kanske ofta:

"Jag vill loopa igenom den här listan och göra något med varje element."

Och så skriver man en for-loop:

for (const x of xs) {
    doSomething(x);
}

I ett sådant exempel kommer doSomething absolut att ha sidoeffekter, annars vore det helt meningslöst att skriva loopen överhuvudtaget.

I en helt funktionell kontext (se mitt inlägg ovan) kan man inte tänka så, utan då måste man tänka:

"Jag vill beskriva resultatet av att applicera en funktion på varje element i den här listan."

Detta kallas att mappa en funktion över en lista och är ett typexempel på funktionell programmering. Här handlar det inte om att "beordra datorn att göra saker", utan att "berätta för den vad saker är". I Haskell skulle man kunna göra så:

mapMyFunction [] = []
mapMyFunction (x:xs) = something x : mapMyFunction xs

I detta exempel är something en funktion (garanterat ren eftersom Haskell bara har rena funktioner) som returnerar ett värde. Vi berättar först att mapMyFunction av den tomma listan är den tomma listan. Sedan berättar vi att mapMyFunction av en lista som börjar med x och fortsätter med xs är listan som börjar med something x och fortsätter med mapMyFunction xs.

(Notera alltså att funktioner i Haskell är funktioner i matematisk bemärkelse: Det enda de kan "göra" är att beräkna ett returvärde, och det returvärdet är alltid samma varje gång funktionen anropas med samma argument: f x är alltid lika med f x för alla f och x, hur många gånger man än evaluerar det. Det finns till exempel ingen motsvarighet till JavaScripts Math.random i Haskell; det går knappt att komma längre från matematiska funktioner än så.)

I verkligheten skulle man inte skriva mapMyFunction, utan man skulle använda den mer generella map ur standardbiblioteket, som på ett mycket bra sätt åskådliggör även den andra aspekten av funktionell programmering, nämligen att funktioner är värden. map kan definieras så här:

map :: (a -> b) -> [a] -> [b]
map _ [] = []
map f (x:xs) = f x : map f xs

Först berättar vi att resultatet av att mappa vilken funktion som helst över den tomma listan är den tomma listan. Sedan berättar vi att resultatet av att mappa funktionen f över listan som börjar med x och fortsätter med xs är listan som börjar med f x och fortsätter med map f xs.

(Den första raden är typsignaturen för map, som talar om att funktionen som mappas måste kunna ta in som argument element av den typ (a) som finns i listan som mappas över, och att resultatet kommer vara en lista av den typ (b) som funktionen som mappas returnerar.)

I JavaScript, som inte lämpar sig så väl för den helt funktionella stil som är idiomatisk i Haskell, skulle map kunna skrivas så här:

function map(f, xs) {
    const ys = [];
    for (const x of xs) {
        ys.push(f(x));
    }
    return ys;
}

I verkligheten skulle man dock använda Array.prototype.map:

const ys = xs.map(f);

Det jag tycker är viktigt är att inse att man har otroligt stor nytta av funktionell programmering även i imperativa språk. Man behöver inte ens – och bör ofta inte – skriva rent funktionella implementationer, men man kan ändå skriva rena funktioner, som absolut kan använda imperativa implementationsdetaljer för att komma fram till sina returvärden (se JavaScript-exemplet ovan!). Här är ett bra exempel på hur jag brukar skriva rena funktioner i TypeScript.

"Varför ska man använda funktionell programmering?"

För att sidoeffekter är ruskigt svåra att arbeta med, särskilt när kodbaser växer. En ren funktion är mycket lättare att tänka på i isolering, refaktorera, flytta, testa osv, än kod som modifierar och/eller beror på (mer eller mindre) globalt tillstånd hit och dit.

"Men arbetsmarknaden använder inte Haskell; varför ska jag?"

Det ska du nog inte, mer än kanske för att lära dig funktionell programmering, vartill Haskell är alldeles utmärkt. Min förhoppning är endast att fler ska få upp ögonen för att dra nytta av funktionella principer i imperativa språk som JavaScript, Java, Python osv. Jag upplever själv att min egen kod blivit otroligt mycket lättare att förstå och hantera sedan jag gick över från i stort sett enbart sidoeffekter till i hög grad värden som den grundläggande byggstenen i mina program.

Ja. Tröskeln är hög; det minns jag själv mycket väl från när jag plötsligt, i första kursen på högskolan, skulle skriva Haskell efter flera år med JavaScript, där jag hade missbrukat sidoeffekter in absurdum.

Det är när du kan sluta tänka på vad koden ska göra och börja tänka på hur du kan räkna ut värden baserat på andra värden som du kan internalisera det funktionella tänket.

Rent funktionella språk: knappt alls.
Funktionella principer: i så gott som alla välskrivna kodbaser.

Som flera redan skrivit i tråden: att lära sig att programmera rent funktionellt är väldigt nyttigt då de flesta av de "stora" språken idag har stöd för att använda högre ordningens funktioner och liknande.

I "verkligheten" här det inte på något sätt negativt att använda imperativa språk med "mutable state". CPUer har optimerats för att så effektivt så möjligt jobba med "mutable state" och i grunden är alla välanvända CPU-arkitekturer imperativa. "Mutable state" är i sig bara ett problem om samtidigt delas av mer ett kontext.

Är just den insikten Rust bygger på. Initialt hade Rust saker som "pure functions", men de försvann rätt snabbt då målet var att skapa ett modernt systemspråk med hårdfokus på att kunna skriva högpresterande applikationer. Funktionell programmering fungerar bra i det lilla, i praktiken ungefär så länge som man kan hålla de funktionella bitarna i register eller i värsta fall som automatiska variabler ("stacken"). Därför är det vettigt att tvinga sig lära något rent funktionellt språk, det är väldigt användbart som bas i moderna program just då de flesta "stora" språk stödjer detta och det finns massor med fördelar.

Tidigare hade man rätt stora förhoppningar att funktionella språk skulle "automagiskt" lösa de stora utmaningarna att skriva korrekta multitrådade program. I teorin fungerar det lysande, i praktiken fungerar det långt sämre och den insikt man kommit till är att gå till rent funktionell programmering är att gå längre än vad man behöver.

"Mutable state" är faktiskt rätt enkelt och logiskt att jobba med förutsatt att man inte blandar in "magiska" saker (global state) samt endera säkerställer att ingen ändrar ett delat tillstånd alt. att det för tillfället bara finns max en tråd som kan skriva till en potentiellt delat tillstånd. Är ju exakt detta Rust såg till att hantera redan vid kompilering. Rust är inte ett funktionellt språk, det är ett imperativt språk som garanterar att deltat tillstånd endera är "read only" eller att maximalt en tråd har en referens till data (blir kompileringsfel om det är möjglit för fler än ett kontext att referera "mutable" data samtidigt).

Rent funktionella språk ger samma garanti som Rust, men då de inte tillåter "mutable state" blir prestanda rätt lidande då saker trots allt måste köra på de CPUer vi har. Och de har som sagt optimerats för "mutable state" och imperativa program under väldigt lång tid.

En annan sak man ska ta med sig från funktionella språk är att ha en hård separering av data (dina "värden") och sätt att transformera data (dina funktioner). Just den delen är vad OOP fått totalt fel: enda sättet att effektivt och korrekt hantera data i multicore miljöer är att låta data vara synligt och explicit, inte inkapslat!