Tag monads
Ik loste het op met een monad
Een soort van monad. Denk ik.
Imperatieve Options?
Ik gebruik Options graag, ze voorkomen een hoop foutmeldingen. Maar, belangrijker nog, ze maken mijn code expressiever en eleganter. Of liever: ze hebben de potentie dat te doen. Laatst kwam ik tijdens een codereview een functie tegen, waarop mijn primaire reactie was: dit moet anders. – Maar waarom?
Callback hell
In mijn werk als C#-ontwikkelaar maak ik veelvuldig gebruik van functionele programmeerconcepten. Als een functie me een object T teruggeeft of niet, dan codeer ik dat netjes in de signatuur van die functie door een Option<T> terug te geven. Dat dwingt de aanroepende partij om beide scenario’s expliciet af te handelen. Hartstikke handig! – Maar: niet zonder zijn eigen set problemen. Want wat gebeurt er als je meerdere functies achter elkaar aanroept die allemaal een Option<T> teruggeven? Dan komen we terecht in wat men callback hell noemt.
Eerlijke domeinmodellen
Options en Eithers vormen nog maar de eerste aanzetten voor het idee van eerlijke functies. Het zijn constructen die, op het oog althans, redelijk beperkt blijven tot het technische domein. Maar het idee van eerlijke functies past ook uitstekend bij de praktijk van het modelleren van een domein, zoals gebruikelijk in Domain-Driven Design. Dat is een les die ik leerde van Scott Wlaschin op DevTernity.
Wat is een monad?
Wat is een monad, vraag je? Simpel: monaden zijn de meest fundamentele zijnden in het universum - ondeelbaar, onafhankelijk, zowel geestelijk als lichamelijk - de bouwblokken van de werkelijkheid, die tezamen een door God geschapen harmonieus geheel vormen - overigens zonder elkaar te beïnvloeden; het zijn perfect op elkaar afgestemde atomen die in autonoom opereren maar in hun zijn het voltallige universum spiegelen. Althans, dat is wat Gottfried Wilhelm Leibniz onder “monaden” verstond. Maar dit is nu eenmaal een blog over softwareontwikkeling, dus je zal wel dat functionele spul bedoelen.