Forestil dig, man har en data struktur S lad os kalde den D0. Ønsker man at “ændre” noget putter man den fx. i en funktion f(D0,x) => D1. D0 er helt som den var før, og D1 er frisk og ny.
Hvis du er bekendt med “immutable” data-strukturer, tænker du sikkert; ja ja, det ved enhver jo. Hvis du ikke er, så tænker du nok, det lyder dyrt at lave en kopi hver gang man skal lave en opdatering, og hvorfor skulle det overhovedet være smart?
Den første del er i teorien simpel. D0 og D1 deler det der er det samme, så man ikke behøver at lave en kopi for hver ændring. Rent praktisk er der en masse voodoo og snedige algoritmer i spil, men det overlader jeg til læseren. Det som jeg hellere vil grave i er, hvorfor betale den, ganske vist lille pris for at opnå immutability?
Lavpraktisk er multitrådede programmer pludseligt blevet trivielt og “lock free”, hvilket er en ikke uvæsentlig gevinst, og ifølge den famøse artikel “Out of the Tar Pit”, er den vigtigste kilde til unødig kompleksitet “shared-mutable-state”. Unødig kompleksitet definerer de som den kompleksitet der ikke kommer fra selve det problem man prøver at løse, men fra måden man løser det på.
Desuden er immutability konceptuelt tættere på, hvordan den virklige verden vi prøver at emulere faktisk ser ud, noget som Rich Hickey glimrende uddyber i sin GOTO Copenhagen keynote “The value of values” fra 2012. Mens jeg her til aften skriver dette blogindlæg hedder jeg Peter. Det er et faktum der ikke vil ændre sig – det kan være min numerolog finder et nyt navn til mig på mandag, men hvad jeg hedder på dette tidspunkt kommer ikke til at ændre sig. Det lyder jo oplagt og burde vel også være måden man betragter verden med software-briller på.
Af historiske grunde er det bare ikke sådan vi programmører har lært at tænke, og alle de gange jeg med begejstring over en øl skulle forklare mine software-skrivende venner hvorfor Clojure og dets immutable data strukturer er super-cool er jeg kommet til kort. Den gammeldags “mutable” måde at tænke på sidder fast i de fleste, og altså med til at gøre vores software mere komplekst end det behøver at være.
Mit gæt er at David Nolen, der taler torsdag eftermiddag på GOTO Copenhagen, netop om Immutability, også har forsøgt at forklare, hvorfor det er så smart, og derfor har valgt det emne. Det er helt klart mit håb både at få yderligere viden om anvendeligheden af immutability, og også få en håndfuld argumenter til næste gang jeg over en fredagsøl, skal forklare det geniale ved uforanderlig data.