Eric Wastl, twórca Advent of Code zdecydował, że w tym roku AoC będzie trwało tylko 12 dni, zamiast pełnych dwudziestu pięciu, jak do tej pory. Rozumiem go, widać ogrom pracy, jaką w to wkładał co roku. Można się wypalić, można poczuć znużenie. Niemniej chwała mu za to, że znalazł formułę, która działa dla niego i dla nas wszystkich, biorących udział.

W tym roku zadania rozwiązywałem z użyciem Common Lispa. Nie jest to pierwszy raz, kiedy użyłem jakiegoś Lispa: rok temu używałem Clojure, a w 2022 – Racket. W obu pisało mi się bardzo dobrze. Mimo że niektóre algorytmy w swojej kanonicznej postaci są imperatywne, opierają się na tablicach i pętlach oraz modyfikują dane w miejscu, ich wersje funkcyjne, używające danych niezmiennych (immutable) są łatwe w implementacji i wystarczająco szybkie, by rozwiązać zadania z Advent of Code.

Podejrzewałem, że w tym roku będzie podobnie, że zaimplementuje algorytmy na funkcyjny sposób, bazując na umiejętnościach zdobytych w czasie poprzednich edycji zabawy. A jednak Common Lisp mnie zaskoczył.

Nie posługuję się płynnie tym językiem. Właściwie można powiedzieć, że uczyłem się go, implementując rozwiązania zadań. Idiomy programowania funkcyjnego – map, cond, rekurencja itd. – są tu obecne, można ich swobodnie używać. Ale odkryłem, że CL zawiera także bardzo praktyczne mechanizmy iteracyjne. Przykładowo, deep-first-search mogłem zaimplementować równie wygodnie za pomocą rekurencji, co iteracji. Mogłem dobrać pasującą implementację do konkretnego problemu i w żadnym wypadku nie miałem poczucia, co czasami mi się zdarzało w Clojure, że łapię się prawą ręką za lewe ucho.

Tegoroczne AoC zostawiło mnie z przeświadczeniem, że Common Lisp jest dużo bardziej praktycznym językiem, niż myślałem. Mam ochotę poznać go lepiej, napisać coś więcej niż proste, bądź co bądź, rozwiązania algorytmicznych zagadek.