Voor de mensen die niet weten wat de website "Advent of Code" is, dat is een website waarbij je bepaalde problemen voorgeschoteld krijgt, 12 dagen lang, dus iets minder lang dan Advent duurt. Het zijn een soort puzzels die je op verschillende manieren op kunt lossen. "Hoe", dat maakt niet uit. Het gaat erom dat je het juiste antwoord invoert, want dan kun je door naar de volgende opdracht. Vaak bestaat een opdracht van 1 dag uit 2 delen, dus als je het eerste antwoord gegeven hebt kun je vervolgens een aanvullend probleem oplossen en dat als het antwoord voor het 2e deel invullen.
In theorie zou je dit op papier kunnen doen, maar dan heb je in sommige gevallen pas het antwoord na 100 jaar (bij een bepaalde opdracht moet je bepaalde routes tellen, waarbij je ruim boven de 1.000 zit - handmatig dus niet te doen), dus je zou dingen in Excel kunnen doen (als je daar handig in bent), in script (Python, Ruby, PHP) of met een andere programmeertaal. Omdat ik .NET developer ben, doe ik de opdrachten in C#.
Ik kende de website adventofcode.com al, onder andere door mijn bezoek in april 2025 aan DEVCAMPNOORD, één van de presentaties werd gegeven door Michaël Hompus. Hij maakt er een sport van dat hij niet alleen het juiste antwoord met zijn code kan geven, maar ook dat de hoeveelheid tijd minimaal is én dat zo weinig mogelijk geheugen gebruikt wordt. Voor mij is dat "een stap te ver", want ik heb het "druk" met andere dingen, dus ik bouw de code en als ik het juiste antwoord krijg: dan ga ik door.
Dus ja, in 2025 deed ik voor het eerst ook mee. Collega Leks dropte bij ons in Slack de vraag "of er meer mensen mee deden aan Advent of Code". Dat was voor mij de trigger om ook eens mee te gaan doen. En tot en met dag 7, het eerste deel ging het prima. Alleen daarna... liep de boel vast. Bij het aanmelden voor Advent of Code moet je volgens mij aangeven dat je "geen zaken deelt". Dat ga ik hier dus ook niet doen, het is niet leuk om online "de juiste antwoorden te vinden", de uitdaging ligt er namelijk in dat je net zolang doorgaat tot je zelf het juiste antwoord gevonden hebt. En volgens mij kun je ook nog alle "oude opdrachten doen", dus als je developer bent, ga ook eens met zo'n vraagstuk aan de slag.
De mensen die mij volgen hebben waarschijnlijk gedacht dat ik in de week van Kerst van 2025 "lekker vrij" had en daarom geen artikelen gedeeld heb. Dat was het niet. Ik heb die dagen gewerkt en tijdens de dagen dat ik wel vrij had (Kerst) zat ik mijn hersens te kraken op het tweede deel van de opdracht van de 7e dag. Ik zal even in "algemene termen" het probleem beschrijven, mijn niet werkende oplossingen hier delen en jou misschien motiveren om te denken "dat gaat mij wel lukken" ;)
Het voorbeeld wat gegeven wordt is een raster van 16 regels, 15 kolommen. Je begint boven bij een startpunt. Als je een punt tegen komt, ga je verder naar beneden. Kom je een dakje tegen ( ^ ) , dan is dat een splitsing. Je gaat dan dus 1 naar links naar beneden en 1 naar rechts naar beneden. En zo kom je nog een paar splitsingen tegen. Uiteindelijk kom je onderaan bij de 16e rij. Het eerste deel wat gevraagd werd was hoe vaak de lijn gesplitst werd. Je kreeg dan de input voor de opdracht, dat was een raster van 142 regels, 141 kolommen. Dat was voor mij prima te doen.
Het tweede deel van de opdracht was de vraag "hoeveel routes" er mogelijk zijn. Want je kunt de route volgen waar je bij elke splitsing "linksaf gaat", of "rechtsaf gaat". Maar je hebt meerdere splitsingen naar beneden, dus de hoeveelheid "routes" neemt elke keer toe.
Ik denk dat veel developers dit lezen en denken "dat is toch wel te doen?". Dat was namelijk ook mijn insteek. Je gaat "gewoon" elke splitsing als een soort punt in je code in een lijst opslaan en je gaat alle routes langslopen. Die code implementeer je en start de boel op. Dan zie je dat het wel lang duurt, laat je de computer een avond aan staan en als je de volgende ochtend weer bij je computer kijkt "hoe ver ie is", dan is je code nog steeds aan het stampen. Je hebt geen idee wanneer dit gaat eindigen en sluit het script af, dit gaat misschien de hele week of maand nog wel draaien, wie zal het zeggen...
Het probleem is volgens mij dat zaken exponentieel toenemen, daar is ons brein niet zo geschikt voor.
Tijdens een podcast werd het graankorrel vraagstuk genoemd. De koning wilde de uitvinder van het schaakbord belonen en vroeg de uitvinder wat hij wilde hebben. Zijn antwoord: op het eerste veld 1 graankorrel, op het tweede veld 2 graankorrels, op het derde veld 4 graankorrels en zo verdubbelen tot alle velden gevuld zijn. Dat leek de koning een "goede deal", dus hij ging akkoord... maar kwam tot de conclusie dat het onmogelijk was om die te vervullen. Een schaakbord heeft 64 velden, door elke verdubbeling kom je uiteindelijk op 18.446.744.073.709.551.615 stuks (wikipedia). Als ik het zelf in Excel gooi krijg ik trouwens 18.446.744.073.709.600.000.
Met zulk soort getallen begin ik te vrezen dat ook deze opdracht niet op te lossen is op de manier waarop ik dit aanpak. Dus vrees niet: als je deze opdracht nog moet doen, zul je hier niet lezen hoe je dat moet doen. Misschien wel "hoe je het niet moet doen" :)
Met zulk soort opdrachten begint weer wat "kennis opgedaan vanuit de Hogere Informatica-tijd aan de Noordelijke Hogeschool Leeuwarden" boven te komen. Want zo fluistert er een stemmetje in mijn hoofd "back-tracking". Ik ben gaan kijken of ik "vanuit de eindpunten" terug kan gaan naar het beginpunt en zo het totaal aantal mogelijkheden kan berekenen. Maar ook hier geldt, als het naar beneden exponentieel is, is dat ook zo "als je naar boven gaat".
Bij mijn laatste poging ben ik gaan werken met zaken parallel uitvoeren. Iets wat ik bijna nog nooit gebruikt heb, maar hier een "versneller" zou kunnen zijn. Het laat zien dat zulk soort opdrachten je "dwingen" bepaalde zaken te gebruiken, die je misschien later bij je werk ook weer kunt gebruiken (want we hebben genoeg processen die we misschien ook parallel uit kunnen voeren: als je computer / server meerdere cores heeft, dan is het zonde dat je er maar één gebruikt).
Waarom ik geen CoPilot / ChatGPT / Claude gebruikt heb? Deze opdrachten zijn bedoeld om je "hersenen te laten kraken". Als je AI je opdrachten laat oplossen... dan leer je er zelf weinig van. Tevens geeft het oplossen van een probleem na een tijd puzzelen en pielen je een mooie dosis endorfine, "yes, I did it!".
Het is ook een goede wake-up call. Ik zit met mijn podcasts van .NET Rocks in de afleveringen van 2008 en 2009 en hier komen de functionele programmeertalen voorbij, zoals Haskell en F#. Voor zo'n "mathematisch probleem" wat we hier hebben, had ik veel beter F# kunnen gebruiken. Alleen... daar is nog even het gebrek aan kennis wat ervoor zorgt dat ik dit nog niet doe, F# staat al een tijd op mijn lijst om mij daarin te verdiepen.
Final note
Ik had (vond ik zelf) in C# een mooie oplossing gebouwd die het totaal zou gaan tellen. Nieuwjaar, 2 januari vrij genomen, weekend, dus de applicatie mag wel even draaien. Na 3 volle dagen "te stampen", waarbij al 9.741.550 routes gecheckt zijn, zijn er nog 42.833.898 te gaan. Maar elke keer als er wat verwerkt wordt, wordt de voorraad "te doen" ook nog steeds groter, dus ik breek de verwerking af. Ik vond dat ik er zelf nu wel genoeg tijd aan had besteed (hoewel ik de code die ik had, had kunnen (en ook moeten!) omzetten naar Python). Want volgens mij had ik dan heel snel het antwoord gehad.
In ieder geval, ik heb het AI-model Claude Sonnet 4.5 de omschrijving van de opdracht gegeven en gevraagd of hij het antwoord voor mij kon regelen. Claude ging aan de slag, kwam met een Python-script, vroeg me of hij dat mocht uitvoeren en kwam binnen 2 tellen met een heel hoog getal. Gecheckt, maar niet het juiste antwoord. Dus het voorbeeld aangeleverd en gezegd "je moet op 40 uitkomen". Claude kwam eerst op 6 uit, ging wat pielen, toen bleek het Python-script bestand niet goed UTF-8 te zijn waardoor de positie van het startpunt niet bepaald kon worden. Na wat aanpassen, testen en corrigeren kwam Claude met een redelijk simpel stukje Python-script wat inderdaad binnen 2 seconden het juiste antwoord geeft.
Dus ja, eerst zelf goed je best doen, maar als je "ook heel veel andere dingen moet doen", is het oké om AI als "pair-programmer" in te zetten. Want het heeft mij in ieder geval geleerd dat dit probleem in C# oplossen "niet de manier is". En in de podcasts van .NET Rocks had ik al gehoord dat je met IronRuby en IronPython met .NET kon werken, in dit geval lijkt het de moeite waard om daar eens wat dieper in te duiken.
Voor de volledigheid de input die ik gegeven heb, waarmee Claude het vervolgens kon fixen:
The file data.txt contains a matrix. You start at the top, at the position of the S. You go down. When you meet a dot you can continue to go down. When you reach a ^ you still go down, but you go down one left from the ^ and one right from the ^. The question is, how many routes can you go down? If you have only one ^ below the S, you have 2 options: 1 route to the left and 1 to the right. Can you give the answer how many routes are possible?