Språket vi använder påverkar sättet vi tänker. De ord och fraser vi använder påverkar vårt förhållningssätt. Detta är något politiker är väldigt bra på, att använda ord för att påverka hur vi uppfattar problem i samhället och påverka debatten.

Detsamma gäller mjukvaruutveckling.

På 50-talet hände något fantastiskt när paradigmen strukturerad programmering uppstod. Tidigare hade man skrivit kod primärt för att maskinen skulle förstå den. Man programmerade maskininstruktioner som datorn skulle exekvera en efter en. Med strukturerad programmering ville man uppnå ett språk som skulle vara för människorna som läser och skriver koden. Man införde IF-THEN-ELSE, WHILE, FOR, subrutiner och kodblock. Detta är element som är fullt integrerade i den kod vi skriver idag, men som ändrade sättet man tänkte på 50-talet.

Denna nya sortens kod som med all fördel skrevs i programspråket Algol, behövde kompileras till maskinkod för att kunna köras av datorn. Givetvis hade också 50-talet sina nej-sägare som menade att en dator aldrig kan skriva lika optimerad maskinkod som en människa. Det är inte många som skulle föra det resonemanget idag.

Den mest populära paradigmen inom programmering är den imperativa objektorienterade programmeringen. Med imperativ menas att program beskriver vad datorn skall göra i den ordning det skall utföras, ungefär som man läser ett recept.

Vispa ägg och socker, blanda med mjöl och bakpulver, in i ugnen 175 grader i 30 minuter. Nu är kakan färdig.

Objektorienterad programmering blev populärt på 90-talet. Den identifierar ett problem med de system som vi bygger, nämligen att vi försöker översätta en komplex domän med noder som på olika sätt relaterar till varandra, till en kod som är helt och hållet imperativ, där en sak händer efter en annan.

I bästa fall kan den endimensionella koden motsvara en dimension av den komplexa domänen.

Med objektorienterad programmering skapar vi klasser och objekt i vår kod som skall efterlikna verklighetens komplexitet för att minska gapet mellan verkligheten och systemets implementation.

Detta nya sätt att tänka förändrade helt och hållet sättet vi bygger system och löser problem med programmering. Man kan säga att det är en revolution som har skett och verktygen har öppnat upp våra hjärnor för en ny sorts problemlösning.

Idag är det objektorienterad programmering som lärs ut på våra universitet och som varje systemutvecklare utgår från när de skall lösa ett problem. Den objektorienterade paradigmen sätter ramarna, men också begränsningar för hur vi löser problem.

Objektorienterad programmering är inte den enda paradigmen. Det finns fler sätt att lösa problem. Ett exempel är deklarativ funktionell programmering. Där utgår man ifrån att vi har data som vi passar in i funktion och får ut annan data, eller förändrad data.

Funktioner kan kombineras, nästlas, köras sekvensiellt eller parallelt, anropa sig själva eller vad som behövs för att uppnå önskat resultat.

Denna paradigm har funnits sedan sent 50-tal men fått ett uppsving de senaste åren som en motreaktion på att objektorienterad programmering helt och hållet tagit över våra programmeringsspråk. Det är inte en dålig modell för att beskriva system på heller. Mycket av det vi gör handlar om att mappa någon form av data till en annan. Det kan vara data i en databas till ett användargränssnitt eller varor i en kundvagn till en order.

Ett exempel på skillnader i paradigmer

Det lättaste sättet att beskriva skillnaden mellan dessa två programmeringsparadigmer skulle vara att göra det i kod.

FizzBuzz är nog den vanligaste programmeringsövningen som används vid anställningsintervjuer av programmerare. Målet är att skriva ett program som skriver ut siffrorna 1..n men där var tredje siffra ersätts med ”fizz”, var femte siffra med ”buzz” och för tal som både ersätts med ”fizz” och ”buzz” exempelvis 15 istället ersätts med ”fizzbuzz”.

En implementation i imperativ objektorienterad C#-kod skulle kunna se ut såhär.

Programmet beskriver imperativt i en följd hur man går till väga för att skapa resultatet. Vi lägger hela resultatet i en resultatlista och returnerar det.

Men bara för att man kan imperativ objektorienterad programmering så skall man inte tro att det är det enda sättet att lösa detta problem på.

En deklarativ funktionell lösning i F# skulle kunna se ut såhär.

Ser ni skillnaden? Detta är inte en imperativ beskrivning av hur FizzBuzz-listan skall skapas. Istället är det deklarerat vad fizzes är, sen vad buzzes är. Följande vad words är och vad numbers är och slutligen att fizzbuzz är en kombination av words och numbers där vi väljer words om det finns, annars numbers.

Hade jag inte kunnat funktionell programmering så hade jag inte vetat att man kan lösa FizzBuzz på detta sätt. Om man kan många paradigmer kan man också välja problemlösningsmetod utifrån problemet man har framför sig. Om man enbart kan objektorienterad programmering, då kommer alla lösningar bli till klasser och objekt.

When all you have is a hammer, every problem will look like a nail.