Aoc2024

Solve Advent of Code in PicoLisp

I am trying to solve this year's tasks in PicoLisp. This will be a strong challenge, since this language does not support vectors, matrices, even though a significant part of AoC tasks are based on it. Since I also want to support the very modest PicoLisp literature in Hungarian with the solutions, the comments in the program will be in Hungarian. I will also write my further comments in Hungarian.

A PicoLisp már több mint egy évtizede a szemem elé került, olvasgattam is róla, de a különcsége miatt túl sok energiát nem fektettem bele, egy-két példaprogramon kívül mást nem futtattam le, saját programokat nem írtam. Aztán most november végén, mikor felmerült bennem, hogy jó lenne egy kicsit játszadozni az AoC feladataival, ugrott be a PicoLisp, mint egy számomra teljesen haszontalan nyelv, s valóban csak a játék kedvéért merülök el benne, viszont rendesen kikerülök a komfortzónámból.

Ubuntu alatt próbálgattam valaha, de most a játszós gépem egy MacBook Air. Elvileg két módon is lehetne rá telepíteni a PicoLisp-et, de elsőre nem jött össze, így kerülő úton, konténerizációval oldom meg a helyzetet, azaz még egy botot is bedugok a küllőim közé. Valamiért a konténerizált Ubuntu nem az igazi, hiába próbáltam a telepítésből kimaradt dokumentációs fájlokat telepíteni, azokat nem tudtam működésre bírni. Nem szép megoldás, hogy az ember egy konténerben kódol, ne is csinálja senki otthon, viszont nekem játszani megfelel. Mivel december már elindult, s inkább fontos számomra a feladatok megoldása, mintsem az ideális fejlesztőkörnyezet kialakítása - tudjuk, hogy a suszter cipőjének lukas a talpa - ezt a kis időt már kibírom a konténerben, aztán esetleg ha már minden feladat elkészül - és nem lesz elegem a nyelvből, és meg akarom ismerni mindazt, amit a feladatok megoldása során elkerültem, lehet, hogy normális, natív környezetet is kialakítok.

Tapasztalatok

• Számomra is fura módon a PicoLisp gyors, rendszerint pillanatok alatt megkapjuk a megoldást, annak ellenére, hogy igen aktívan kell mozognunk a listákban. Persze vacakul megválasztott algoritmussal jelentősen lehet rontani a hatékonyságán.
• Automatikusan smeri a nagy számokat (BigInt), így nem okozott gondot, ha 64 bit nem volt elég a megoldás tárolására. Emiatt nem kellett elbonyolítani kódot, nem kellett újabb típusokat bevezetni, amivel egyes nyelvekben pár embernek meggyűlt a baja, főleg a programozással még csak ismerkedőknek.
• Miután a PicoLisp igen sok tekintetben eltér a Common Lisp illetve a Scheme nyelvektől, rengeteg időt kellett guglizni, illetve a REPL-ben tölteni a példaprogramok kipróbálására, átalakítására. Maga a nyelv a Common Lisp, Prolog és Forth Bermuda-háromszögében található, és eléggé unothodox.
• Fura több évtized után újra nagybetűs változóneveket használni - itt ez az illemszabály - illetve aláhúzás helyett lehet kötőjelet is használni a változónév közepén, amihez szívesen hozzászoknék máshol is. Az viszont kicsit zavaró, hogy nincs biztonsági öv - senki/semmi nem figyelmeztet, hogy egy változónevet elírtam, s majd hosszabb debug-olás után derül ki, hogy ez volt a probléma. Úgy hiányzik ide egy linter, mint egy falat kenyér, de ilyen programmal még nem találkoztam. Ha véletlenül egy rákerül a vezérlés számlistára - akkor mivel a számokat nem ismert függvénynek tekinti - máris jön a seg-fault. S ekkor már nincs más, mint az interpreter újra indítása. Kezdőknek nem ideális nyelv. (De ettől szép a kihívás...) Viszont a REPL-ben igen hatékonyan lehet dolgozni, tesztelni elképzeléseket, s félig-meddig eljutni a megoldásig is.
• Habár a programnyelv OOP és webes képességeit még nem ismertem meg, enélkül is haladok a feladatok megoldásával. Ám még így is rengeteg függvény létezik a funkcionális megközelítésben, melyekből kiválasztani a leginkább megfelelőt nem egy egyszerű feladat. Viszont mire az összes feladatot megoldottam, kialakult egy nem olyan nagy függvény-repertoár, mellyel mindent sikerül megoldani. Igaz, folyamatosan forgatni kellett a dokumentációt, mert az argumentumok sorrendjében nem találtam rendszert. Valamint a megfelelő függvény kiválasztásában az ötletet egy google keresés adta meg. (Igen, hiányzik a gyakorlat.)
• Mivel a funkcionális megközelítés más gondolkodásmódot igényel, viszonylag lassan oldom meg a feladatokat, de leginkább a számítógéptől távol sikerül előrelépnem, ha valamikor elakadom a megoldás során. Az alapos hozzáállás, átgondolt megoldás meghozza a saját jutalmát, ha a tesztesetre működik a kód, akkor az éles adatokra is. A Reddit-en naponta tucatjával érkeztek a segítségkérések, mert a teszt adatokra jól működik a megoldásuk, ám az éles adatra már nem. Mindenesetre itt reménytelenül alátippelek a megoldáshoz szükséges időnek.
• Funkcionális nyelveknél szinte elengedhetetlen a farok-rekurzió, amivel a rekurzió lényegében iterációvá alakul. Azaz a kód marad olvasható, de nem fogy a tár a visszalépési pontok tárolása miatt. Ebben az interpreterben ilyen viszont nincs, így a természetesen adódó rekurzív megoldások helyett jöhet a fejben iteratívvá alakított variánsa. Szerencsére a nyelvben van jópár magasabb szintű megoldás, de kódméret még így is nagyobb lesz, mint például Racket-ben lenne.
• A VS Code Dev Containers kiterjesztése igen kényelmessé teszi a konténerben fejlesztést. Viszont a késői - szinte utolsó pillanatos - elhatározás miatt nem igazán volt időm a Code beállítására - PicoLisp plugin pedig még nincs hozzá - így a már korábban is ismert CotEditor-t sikerült megszelídítenem. Sok rejtett kincsre akadtam benne, így aki MacBook-ot használ, és kódol, vessen rá egy pillantást.
• A konzolt/terminált a Code-ban használtam, s eleget bosszankodtam, hogy - elindítva a PicoLisp interpretert - még az Emacs stílusú szerkesztések sincsenek benne, így csak a kurzorbillentyűkkel mozoghattam jobbra-balra. Mindezt a Code korlátjának gondoltam. Aztán pár hétre rá szembejött velem egy leírása az interpreternek, melyben ott szerepel, hogy a vi szerkesztés az alapértelmezett - apróbb módosításokkal, de majdnem az összes egybetűs parancs működik -, ami meg nekem a véremben van. Azért nem buta mondás a "RTFM!" Egyszerűen lehet azzal játszani, hogy mi kerüljön be az interpreter history-jába, melyek azok az eldobható esetek, melyeket nem akarunk megismételni, s nem akarjuk, hogy csak foglalják a helyet.
• A PicoLisp szinte egyáltalán nem támogatott nyelv a szövegszerkesztők által, s mivel igencsak unorthodox, nem érdemes azt mondani, hogy például Scheme-ben programozok, mert a kikommentezett sorokban található zárójeleket ekkor beszámolja a szövegszerkesztő, s észnél kell lenni, hogy ne fogadjuk el a szövegszerkesztő zárójel-számlálását. Amivel még sok gondom volt a változók nevének pontos leírása. A Prolog automatikusan szólt, ha pl. kisbetű-nagybetű különbségek miatt egy változó csak egy példányban szerepelt valahol. Itt hosszú debug-golás kellett, hogy egy-egy ilyen elgépelésre ráakadjon az ember. Ha valaki komolyabban játszadozna ezzel a nyelvvel, akkor használja a szerzői által biztosított vip programot, mert sok bosszúságtól megszabadul.