Systemudvikling og systemer

Hvorfor prøver du ikke et funktionelt sprog?

Funktionelle programmeringssprog er matematiknære. Derfor mener systemudvikler og teknisk chef Ramón Soto Mathiesen, at flere bør prøve at udvikle i funktionelle sprog.

– Når du udstikker tekniske retningslinjer for et projekt, er det rart at vide, at det valgte programmeringssprog gør produktet mere robust.
Ramón Soto Mathiesen er ikke i tvivl om fordelen ved at anvende funktionelle sprog. Han anvender selv det funktionelle programmeringssprog F# til daglig, og som CTO hos Delegate har han lidt mere ro i maven, når selskabets CRM-installations- og deployment-værktøj, DAXIF#, hovedsageligt er kodet i F#.

– Funktionelle programmeringssprog er tættere på matematikken, så det er nemmere at teste og bevise, at koden virker, argumenterer Ramón.

Han har en lang baggrund inden for it og har kodet i mainstream-sprog som C#, C++ og Javascript, men det er funktionelle sprog som F#, der tænder passionen i den dansk-spanske datalog. Ifølge Ramóns erfaringer bliver kodebasen mindre og mere overskuelig, ligesom det er nemmere at udnytte multikerneprocessorer, da funktionelle sprog er velegnede til parallelprogrammering og håndtering af samtidighed. Samtidig speedes udviklingstiden også op.

– Udvikling i C# og Java og lignende objektorienterede sprog tager længere tid end med funktionelle sprog, mener Ramon.

Fra objektorientering til funktionel

Udviklingstiden afhænger selvfølgelig af, hvor godt udviklerne kender det pågældende programmeringssprog og det bagvedliggende programmeringsparadigme. Langt de fleste udviklere i dag er fortrolige med den objektorienterede tankegang, mens det er færre, der er fortrolige med den funktionelle tilgang. Ramón har selv erfaret, at det ikke altid er nemt at få udviklere, som er fortrolige med det objektorienterede paradigme, til uden videre at skifte til et funktionelt sprog.

– Medarbejderne var i starten ikke så glade for det, siger Ramón om tiden for tre år siden, da han forsøgte at indføre F# som udviklingssproget for DAXIF#.

Derfor blev værktøjerne, der gør installation og udrulning af Microsofts Dynamics CRM nemmere, i første omgang udviklet i C# og først senere skrevet i F#. Ved at skrive små kompakte F#-moduler i stedet for at anvende C#-klasser blev antallet af kodelinjer reduceret til omkring en trediedel af den oprindelige kodebase.

Ramón fremhæver blandt andet F#'s REPL (Read, Evaluate, Print Loop), der er med til at gøre udviklingen hurtigere.

– Med F# kan en funktion evalueres 'on the fly', og du kan se, at den lille komponent virker efter hensigten, uden at du skal rekompilere hele dit projekt. Det er en stor fordel, da en lille kodeændring ikke kræver en ny timelang build af hele projektet efterfulgt af unit-tests, som jeg har oplevet på andre projekter.
 

Funktionel afsmitning

I dag har C# også REPL, men den er ifølge Ramón ikke på niveau med F#'s, der var født med REPL. Det er dog et eksempel på, hvordan funktionelle sprogs features og værktøjer langsomt trænger ind på imperative sprog. Et andet eksempel er LINQ (Language-integrated Query), der  blev del af C# 3.0 i slutningen af 2007. Det lille forespørgselssprog med rødder i funktionelle sprog har gjort mange C#-udviklere verden over meget glade.

– Spørger du folk, hvorfor de kan lide C#, siger de tit, at det er på grund af LINQ. Når man så spørger, om de vil prøve F#, siger de nej. Hvorfor skulle jeg gøre det? Men hvis de godt kan lide LINQ, hvorfor så ikke kode i et funktionsorienteret sprog som F# hele tiden?, lyder det retorisk fra Ramón.

Ramón er da også selv meget involveret i at udbrede kendskabet til de funktionelle sprogs kvaliteter. Han var med til at starte gruppen Funktionelle Københavnere, der mødes minimum en gang om måneden til præsentationer og efterfølgende diskussioner om funktionelle sprog. Han arbejder også sammen med kursushuset Skills House om at undervise udviklere i F#.

Ramón understreger dog, at han ikke er blind for andre programmeringsparadigmers fordele. Som enhver god udvikler ved, handler det om at anvende de værktøjer, som er bedst egnede til en given opgave.

– Eksempelvis anvender vi i stor stil TypeScript, som slog FunScript (F# til klientsiden, red.) ud af vores palet af teknologier. Så vi laver ikke kun funktionsprogrammering for pedanteriets skyld. Nej, vi anvender de værktøjer, som giver mest mening uanset paradigme.
 

Let for matematikere

Det var på Datalogisk Institut på Københavns Universitet, at Ramón fik øjnene op for mulighederne med funktionelle sprog. Danmark har generelt gode undervisere i funktionelle sprog på universitetsuddannelserne, men det kniber for erhvervslivet at tage funktionel programmering i anvendelse. Efter universitetet oplevede Ramón, at det nærmest var forbudt at anvende funktionelle programmeringssprog, fordi folk i ledende positioner, efter Ramóns mening, ikke forstår det så godt.

Der er dog virksomheder, især inden for den finansielle sektor, som kan se idéen med funktionelle sprog. Eksempelvis anvender PFA's aktuarer F# ligesom virksomheden Simcorp, der leverer finansielle værktøjer, anvender oCaml og F#.

– Folk med en matematisk baggrund kan godt se pointen med F# og andre funktionelle sprog; det minder meget om dengang, de definerede matematiske funktioner, siger Ramón og nævner aktuaren Kristian Schmidt hos PFA, der tog F# til sig og begyndte at undervise de andre aktuarer i at anvende programmeringssproget.

Selvom man ikke har en matematisk baggrund, kan man godt lære F#, men det kan tage lidt tid at vænne sig til det funktionelle paradigme.

– Jeg har prøvet at undervise udviklere uden akademisk baggrund i F# et par gange. En dags undervisning var ikke helt nok. Det skal dog ikke afskrække folk. Det er absolut værd at bruge lidt tid på at lære funktionelle sprog, slår Ramón fast.