Daniel Janus – programowanie

Jak zostałem programistą

2022-12-24T00:00:00Z

Nazywam się Daniel Janus, mam 38 lat i od 31 lat jestem programistą.

Czasem się tak przedstawiam i czasem budzi to zaciekawienie, powątpiewanie albo jedno i drugie naraz. Wracam więc myślą do samych początków.

Pamiętam, jechaliśmy z ojcem autobusem. Mogłem mieć pięć, może sześć lat. Tata ni stąd, ni zowąd zaczął opowiadać mi o komputerach. Nowe, nieznane mi wcześniej słowo. Nie mam pojęcia, jaka była treść tej opowieści, za to dokładnie pomiętam żarówki, które zapaliły mi się w oczach. I ten kawałek rozmowy:

– Jakby czarodziejski???
– Jakby czarodziejski.

Minęło kilkadziesiąt milionów sekund. Zdaje się, że łaziłem w międzyczasie i mówiłem, że chcę komputer. I w końcu, w 1991, tata przyjechał z saksów w Niemczech i mówi: kupiłem ci komputer! Nazywał się Commodore 64 i pachniał plastikiem, elektroniką i świeżością. Dzisiejsze komputery już tak nie pachną.

To nie jest dokładnie TO pudełko – zdjęcie wygrzebałem z jakiejś aukcji na Allegro – ale tak wyglądało.

Zanim go uruchomiliśmy, upłynęły jeszcze prawie dwa tygodnie. W tym czasie w domu nastał nowy, kolorowy telewizor, a ja siedziałem jak na szpilkach, czekałem na ten telewizor, fantazjowałem o tym, jak to będzie, kiedy całość już podłączymy, obmacywałem zawartość pudełek (było jeszcze drugie, ze stacją dyskietek), zgadywałem, który klawisz do czego służy, i czytałem dołączone materiały. Oczywiście po niemiecku. I oczywiście nic z tego nie rozumiałem – niemieckiego miałem się zacząć uczyć w podstawówce dopiero od piątej klasy.

Były tam też wypisane różne rzeczy, które komputer może wyświetlić na ekranie, i takie, które trzeba do niego wklepać z klawiatury, żeby jakoś zareagował.

Zdjęcie tym razem z eBaya.

W końcu nadszedł TEN dzień. Komputer podłączony, telewizor włączony, szukamy odpowiedniej częstotliwości wideo… i wreszcie z telewizyjnego białego szumu wyłonił się obraz, znany doskonale wielu ludziom z mojego pokolenia:

Ekran startowy C64. Kto go pamięta?

Nie pamiętam, co zrobiłem potem. Pewnie nacisnąłem wszystkie klawisze po kolei i nauczyłem się wyłączać i włączać całość. Jakoś intuicyjnie wykminiłem, jak działają klawisze kursora, co robi spacja, a co RETURN. Potem próbowałem przepisywać z tego niemieckiego podręcznika różne polecenia i patrzyć, co się stanie.

W którymś momencie odkryłem, że po wpisaniu LOAD "$",8 (dlaczego akurat 8? dlaczego akurat dolar? strasznie mnie to ciekawiło, ale nie wnikałem w szczegóły) i naciśnięciu RETURN komputer wypisuje na ekranie nowy, nieznany mi komunikat błędu, ale nie robi tego od razu – najpierw stacja dysków wydaje kilka dźwięków i zaczyna mrugać diodą na czerwono. Włożyłem dyskietkę do napędu (z komputerem przyjechało kilka dyskietek demonstracyjnych) i spróbowałem jeszcze raz. Tym razem zamigotało na zielono i komunikat był inny!

Wpisałem LIST, tak jak kazał podręcznik (nadal nie bardzo rozumiejąc, co właściwie się dzieje). Commodore wyświetlił długą serię komunikatów. Były tam jakieś liczby, skróty i nazwy. Wtedy po raz kolejny wpatrzyłem się w ten kawałek podręcznika:

W Internecie wbrew powiedzeniu czasem giną rzeczy, ale instrukcja do C64 na szczęście ocalała.

Zaraz… PROGRAMMNAME? NAME? Imię? Nazwa?

Napisałem LOAD "LASER FORCE",8. Instrukcji o dokładnie takim brzmieniu nie było w podręczniku! Ale "LASER FORCE" to była jedna z nazw, bodaj ostatnia, w tym długim komunikacie – i pomyślałem, że można wstawić ją zamiast owego enigmatycznego PROGRAMMNAME.

Strzał w dziesiątkę. Komputer odpowiedział komunikatem z podręcznika i zamyślił się na dłuższą chwilę, stacja dysków znowu zaśpiewała zgrzytliwą piosenkę. Czułem, że jestem na dobrym tropie.

Wreszcie wpisałem RUN. Uruchomiłem grę! Zbiegła się cała rodzina.

Dokonałem wtedy swoich dwóch pierwszych odkryć programistycznych. Być może były to najdonioślejsze odkrycia w całej mojej karierze.

Mogę wpisać inną nazwę i załaduje się inny program. A mówiąc ogólniej: różnym parametrom polecenia odpowiadają różne skutki. Inne wejście – inne wyjście.
Warto eksperymentować! Prawdopodobnie nic nie popsuję, najwyżej wyskoczy jakiś błąd i zawsze mogę spróbować jeszcze raz.

Było też odkrycie trzecie, zupełnie niezwiązane z programowaniem:

Lubię grać w gry.

W następnych tygodniach wypróbowałem wszystkie programy i gry na tych kilku dyskietkach, które miałem. Ale skąd wziąć następne dyskietki? W roku 1991 w małym miasteczku (które jeszcze wtedy było wsią) nie było łatwo o dostęp do oprogramowania. Równolegle z graniem próbowałem więc przepisywać następne programy z podręcznika.

Niedługo potem kilku innych chłopaków z sąsiedztwa też dostało C64. Byłem jednak jedyną osobą ze stacją dysków i ten fakt zaważył na mojej przyszłości – wszyscy inni mieli magnetofony. O ile łatwo było po prostu wymieniać się kasetami, o tyle w moim przypadku pozyskanie nowych gier wymagało wyprawy do kolegi i zabrania ze sobą stacji. Rodzice mi nie pozwalali. Samemu? Ruchliwą ulicą? Z drogim sprzętem?

W międzyczasie tata wytrzasnął skądś stare numery „Bajtka”. Był tego pokaźny stosik, archiwa z kilku lat. „Bajtek” odegrał ogromną rolę w mojej wczesnej edukacji informatycznej: były tam małe kawałki wiedzy podane w przystępny sposób. Nie wszystko rozumiałem, ale przynajmniej było po polsku. I rubryka „Tylko dla przedszkolaków” tłumaczyła nie tylko to, co robią pomieszczone tam programy, ale również – dlaczego tak, a nie inaczej.

Dostałem też rozmaite książki – o BASIC-u i o samym komputerze, w tym polską biblię C64, „Commodore 64” Bohdana Frelka. Różne kawałki wiedzy zaczęły składać mi się w głowie w całość. Eksperymentowałem. Próbowałem zmieniać różne rzeczy w programach z Bajtka i w końcu pisać własne. Pamiętam, że jeden z moich programików z tamtych czasów nazywał się ABC FIZYKI i wyświetlał definicje jednostek SI, które przepisałem z jednej z książek ojca.

Kiedy kilka lat później – bodaj w roku 1996 – przesiadłem się na PC, znałem już zupełnie nieźle BASIC i zaczynałem kumać, o co chodzi w asemblerze 6502. Stary komputer jednak poszedł w odstawkę. Rodzice sprzedali go niedługo potem, ale do dziś, po prawie ćwierćwieczu, potrafię bez zaglądania do internetu wyrecytować zgrubną mapę pamięci C64, powiedzieć, do których komórek pamięci trzeba wpisać jaki bajt, żeby tekst wyświetlał się na biało na czarnym tle z czarną ramką (mój ulubiony schemat kolorów z tamtych czasów), jaki jest kod znaku PETSCII odpowiedzialnego za czyszczenie ekranu oraz która procedura Kernala odpowiada za restart systemu, a która za wypisanie znaku na ekran.

Na pececie uczyłem się Pascala. Ale to już zupełnie inny rozdział tej historii.

Kod giętki

2014-05-06T00:00:00Z

Ludzie dziwnie na mnie patrzą, kiedy powiadam, że programowanie i poezja mają ze sobą wiele wspólnego. A jednak uważam, że tak właśnie jest, i to co najmniej na kilku poziomach.

Jaki jest cel poezji? Na ten temat napisano morze: parafrazując stary dowcip – gdzie dwóch poetów, tam co najmniej trzy odpowiedzi na to pytanie. Spróbuję jednak uogólnić: poezja ma za zadanie wzbudzić w odbiorcy określone emocje lub przemyślenia, używając do tego celu słów.

Warto zwrócić uwagę na tę drugą część, oczywistą przecież, poprzedniego zdania. Język, słowa, to najważniejszy i jedyny środek, jaki poezja ma do dyspozycji do osiągnięcia swojego celu. Dobór słów, kolejność słów, ułożenie słów – wszystko to ma w poezji kolosalne i fundamentalne znaczenie. Pojedyncze słowa są na wagę złota. Kilka celnie dobranych słów potrafi wyindukować mocny i poruszający obraz; i odwrotnie – jedno niepasujące słowo może ów obraz zaprzepaścić.

Kojarzycie ten wyimek z Norwida? Pewnie, że kojarzycie, w końcu zdobił pracownię języka polskiego w co drugiej szkole.

Ponad wszystkie wasze uroki,
Ty! Poezjo, i Ty, Wymowo,
Jeden – wiecznie będzie wysoki:
Odpowiednie dać rzeczy – słowo!

Zastanówmy się nad tym chwilę. Norwid próbuje tu wyrazić właśnie to: owo właściwe poetom maksymalistyczne dążenie do przekazania myśli w sposób możliwie najbardziej oddziałujący na odbiorcę przy użyciu odpowiednich słów. Tak i tylko tak.

Spójrzmy na kilka przykładów poszukiwania takich słów. Oto przykład zaczerpnięty z „Ocalonego w tłumaczeniu” Barańczaka, Gerard Manley Hopkins w liście do Roberta Bridgesa z 7 września 1888:

By the bye you misquote the same modern author in writing ‘airy between towers’: what is not so? it should be ‘branchy between towers’.

Gwoli wyjaśnienia: „the same modern author” to sam Hopkins, a wiersz, o którym mowa, to „Duns Scotus's Oxford”, którego incipit adresat listu błędnie cytuje gdzie indziej. Poeta czepia się jednego jedynego słowa, uznając jego zamianę za niefortunną i istotnie osłabiającą przekazywany obraz, w znamiennym proteście: „powietrzny pomiędzy wieżami – a cóż takie nie jest?” W domyśle: jeśli nad jakimś krajobrazem górują wieże, to jasne jest, że pomiędzy ich najwyższymi partiami jest dużo przestrzeni, nie ma sensu tego explicite mówić w wierszu; ale Oksford z jego strzelistymi drzewami i rozłożystymi konarami jest w umyśle Hopkinsa bardzo charakterystyczny.

A teraz zacytuję fragment wiersza, o którym Theodore Roosevelt powiedział, że „nie jest pewien, czy go rozumie, ale z całą pewnością go lubi”: „Luke Havergal” E. A. Robinsona. Wersy 4-5 w pierwszej redakcji tego wiersza, z roku 1896, brzmiały:

The wind will moan, the leaves will whisper some,—
Whisper of her, and strike you as they fall;

Obraz jest sugestywny: niemal czuje się przenikliwy wiatr i słyszy szelest liści układający się w szept. Ale czytając ostateczny, późniejszy o ćwierć wieku wariant wiersza, widzimy, że Robinson ten fragment nieznacznie przerobił:

The leaves will whisper there of her, and some,
Like flying words, will strike you as they fall;

W tej wersji wiatr obecny jest tylko w sposób dorozumiany: skoro mamy szept liści, to, jak uznał Robinson, wiadomo, że wieje i wspominanie o tym wprost jest redundantne; pominięte jest też powtórzenie „szeptu”, którego efekt wzmacniający przekaz był wątpliwy. Wyrzucając te dwie rzeczy, poeta robi miejsce na intrygującą i mocną metaforę „smagających słów w locie”, którą można interpretować na rozmaite sposoby i która interesująco współgra z dalszymi częściami wiersza („God slays Himself with every leaf that flies” w strofie drugiej).

Mieliśmy więc działający, mocny tekst; dzięki przeróbce i znalezieniu odpowiedniego słowa działa on lepiej, efektywniej. Punkt dla tych, którym przychodzi do głowy słowo „refactor”.

Zastanawialiście się, co by było, gdyby Mickiewicz używał gita? „Stepy akermańskie” były refaktorowane wielokrotnie w karkołomnych próbach uchwycenia balansu między wzburzonym oceanem a wysuszoną, jałową pustynią. Jesteśmy niemal w stanie zrekonstruować wynik działania git log -p na tym hipotetycznym repozytorium.

commit 90023f50e466ecf9339c1348f92bd855ccd58750
Author: Adam Mickiewicz 
Date:   Wed Mar 12 19:42:12 1828 +0100

    pierwszy wers - wersja ostateczna

diff --git a/01-stepy-akermanskie.txt b/01-stepy-akermanskie.txt
index 019e416..0c741b8 100644
--- a/01-stepy-akermanskie.txt
+++ b/01-stepy-akermanskie.txt
@@ -1 +1 @@
-Okrążyły mię stepy na kształt oceanu
+Wpłynąłem na suchego przestwór oceanu

commit 1fee11618a8373ae8b8a435c6ff0c7009e3c4554
Author: Adam Mickiewicz 
Date:   Fri Jun 2 17:15:26 1826 +0400

    poprawka do pierwszego wersu

diff --git a/01-stepy-akermanskie.txt b/01-stepy-akermanskie.txt
index 4b7d669..019e416 100644
--- a/01-stepy-akermanskie.txt
+++ b/01-stepy-akermanskie.txt
@@ -1 +1 @@
-Wjechałem na suchego stepy oceanu
+Okrążyły mię stepy na kształt oceanu

commit 416f8d15382b805def5e9e80928216bc86d56eec
Author: Adam Mickiewicz 
Date:   Fri Jun 2 11:44:52 1826 +0400

    kolejna przeróbka pierwszego wersu

diff --git a/01-stepy-akermanskie.txt b/01-stepy-akermanskie.txt
index d3b53c2..4b7d669 100644
--- a/01-stepy-akermanskie.txt
+++ b/01-stepy-akermanskie.txt
@@ -1 +1 @@
-Żeglowałem i w suchych stepach oceanu
+Wjechałem na suchego stepy oceanu

commit c196b9483f501992ed9ce887b5ab4f1279c1b946
Author: Adam Mickiewicz 
Date:   Thu Jun 1 18:03:31 1826 +0400

    przeróbka pierwszego wersu

diff --git a/01-stepy-akermanskie.txt b/01-stepy-akermanskie.txt
index d490bdf..d3b53c2 100644
--- a/01-stepy-akermanskie.txt
+++ b/01-stepy-akermanskie.txt
@@ -1 +1 @@
-Poznałem stepowego podróż oceanu
+Żeglowałem i w suchych stepach oceanu

To, co próbuję pokazać na tych przykładach, to to, że dążenie do takiego użycia języka (polskiego, angielskiego, C, Javy...), żeby możliwie klarownie wyrazić w nim to, o co chodzi, i żeby – cytując C.A.R. Hoare'a – rezultat miał „obviously no deficiencies”, jest wspólną cechą poetów i programistów.

Gdyby było inaczej, nie toczylibyśmy długich dyskusji na temat wyższości paradygmatu obiektowego nad funkcyjnym albo odwrotnie, nie wymyślalibyśmy takich rzeczy jak dependency injection albo fluent APIs, nie mielibyśmy tak bogatego katalogu wzorców projektowych, nie mielibyśmy indywidualnych upodobań stylistycznych, nie pisalibyśmy dokumentów o nazwie CodingStyle, nie rozróżnialibyśmy pomiędzy kodem obleśnym i ładnym, wreszcie – widząc ten pierwszy – nie mielibyśmy odruchu, żeby go natychmiast przepisać.

„Chodzi mi o to, aby język giętki powiedział wszystko, co pomyśli głowa”, pisał Słowacki. Kiedy o tym myślę, przychodzi mi do głowy Lisp i często powtarzane zdanie, że to programowalny język programowania. Homoikoniczność i makra sprawiają, że pisząc program w Lispie, tworzymy nie tylko kod odpowiedzialny za rozwiązanie naszego problemu w z góry istniejącym języku, ale również rozwijamy i naginamy język, używając neologizmów: nowych, powstałych ad hoc konstrukcji składniowych, o ile tylko pozwalają naturalniej, klarowniej wyrazić sens danego fragmentu kodu. Programowanie w Lispie jest jak bycie Leśmianem.

Czasem efekt estetyczny pojawia się w kodzie niejako mimochodem. Przypomina mi się wywiad, jakiego Guy Steele udzielił Peterowi Seibelowi w jego świetnej książce „Coders at Work” (polecam!) Steele wspomina tam o jednym z najbardziej satysfakcjonujących momentów w jego karierze programisty, kiedy po dwudziestu latach udało mu się skrócić napisaną przez Billa Gospera jedenastosłowową procedurę obliczającą sinusy i cosinusy liczb rzeczywistych o jedno słowo maszynowe. Osiągnąć, wydawałoby się, nieosiągalne, dzięki właściwej poezji zwięzłości i nadorganizacji języka: oto czysta radość programowania.

Warto się rozejrzeć po GitHubie. Poezja tam się czai.

O książkach technologicznych i ich tłumaczeniach

2013-02-01T00:00:00Z

Trudna rzecz jest jeden język drugim językiem dostatecznie wyrznąć.
-- Jan Leopolita (1523--1572)

Rodzaje książek informatycznych

Mam zasadę dotyczącą książek informatycznych: nie kupuję niczego, co ma w tytule nazwę konkretnej technologii. (Purystów z góry przepraszam za użycie tego słowa, mając świadomość jego pretensjonalności; ale nie znam innego polskiego określenia, które by zbiorczo obejmowało konkretne języki programowania, systemy operacyjne, platformy wykonawcze, serwery aplikacji, architektury itd.) Po pierwsze, technologie pojawiają się i znikają, wciąż ukazują się ich nowe wersje, i w efekcie czas życia książki opisującej, dajmy na to, konkretną implementację jakiegoś języka programowania na ogół bywa nie dłuższy niż kilka lat. Można wręcz mówić o „okresie półtrwania”, po którym połowa informacji zawartej w książce jest już nieaktualna. Po drugie, i może ważniejsze, tego typu publikacje często wnoszą niewielką wartość dodaną w porównaniu do dokumentacji: od książki oczekuję, że nie tylko przekaże mi suche instrukcje, ale także idee, które w jakiś sposób wzbogacą mój warsztat i zostaną ze mną na dłużej. Dlatego do poduszki wolę poczytać o uczeniu maszynowym za pomocą metod jądrowych niż o bebechach serwera aplikacyjnego.

Rzecz jasna, jak od każdej zasady, tak i od tej istnieją wyjątki. Bywa, że technologia na tyle wryła się w informatyczny krajobraz, że nie grozi jej szybkie przeterminowanie, a dana książka uznawana jest za kanoniczny opis technologii, nie zaś tylko dodatek post hoc (jak K&R do C czy Księga Wielbłądzia do Perla). Zdarza się też i tak, że książka opisuje język czy środowisko, którego akurat intensywnie używam lub przymierzam się do intensywnego używania, i wtedy mam szansę odnieść z niej dużą korzyść. Tak było z Programming Clojure Stuarta Hallowaya, której pierwsze wydanie kupiłem niedługo po jego ukazaniu się z górą trzy lata temu, a drugie, zmienione i uaktualnione (a jakże!) wkrótce ukaże się po polsku nakładem Helionu.

Po przeczytaniu darmowej próbki nasunęły mi się wątpliwości odnośnie samego tłumaczenia, a w ślad za nimi myśli dotyczące polskich tłumaczeń literatury informatycznej w ogóle. Spróbuję je poniżej zebrać.

O Clojure po polsku

Od razu powiem, że ogólny poziom przekładu Tomasza Walczaka uważam za wysoki: tekst jest spójny, nośny i pozbawiony błędów merytorycznych. Czepianie się szczegółów, które za chwilę nastąpi, ma być nie tyle krytyką, co raczej próbą uświadomienia sobie, dlaczego mimo wszystko „Programowanie w języku Clojure” czyta mi się mniej płynnie niż oryginał angielski; a także zwrócenia uwagi na problemy, z jakimi musi się zmierzyć tłumacz. Zasygnalizuję więc pewne zagadnienia, ale wcale nie mam pewności, czy potrafiłbym rozwiązać je lepiej, albo nawet – czy w ogóle się da.

Bo wydawałoby się, że tłumaczenie tekstu informatycznego jest czynnością bez porównania prostszą niż na przykład poezji, gdzie trzeba ważyć każde słowo, prawda? Tymczasem rodzi ono zupełnie nowe problemy. Tłumacz zmuszony jest często wymyślić od nowa terminologię z zakresu wąskiej dziedziny, o której po polsku się nie pisze lub pisze się rzadko lub nieformalnie; podjąć pewne nierzadko arbitralne decyzje i konsekwentnie się ich trzymać; albo – jak zobaczymy – zadecydować, co zrobić z subtelnymi różnicami odcieni znaczeniowych pewnych pojęć.

Lispa czy Lispu?

Tłumacz często używa formy Lispa jako dopełniacza od rzeczownika Lisp. A jak naprawdę powinna brzmieć ta forma? Zdania na ten temat są podzielone. Wydaje się, że tradycyjnie w środowisku utrwalona była postać Lispu (zapewne nawiązująca do odmiany nazw innych wczesnych języków programowania: Fortranu i COBOL-u), co potwierdza zarówno poradnia językowa PWN, jak i słowniki: Słownik gramatyczny języka polskiego i słownik sjp.pl. Forma Lispa (być może urobiona przez analogię do odmiany nazw nowych języków: Perla, Pythona) też jest żywa w uzusie, choć, jak się zdaje, nieznacznie ustępuje odmianie Lispu (w Narodowym Korpusie Języka Polskiego znajdujemy jej 19 wystąpień wobec 33 wystąpień Lispu).

Dla kontrastu, słowo Clojure, którego paradygmat odmiany (nieodmienne) nie budzi wątpliwości, pojawia się na ogół jako część sformułowania język Clojure. Można by analogiczny zabieg przeprowadzić z językiem Lisp. Albo pozostać przy formie Lispu, która, choć zrazu brzmiała mi dziwnie, teraz wydaje się znacznie naturalniejsza niż Lispa.

Co to jest instrukcja?

Porównajmy taki fragment oryginału:

defrecord and related functions are covered in Section 6.3, Protocols.

z odpowiadającym mu tłumaczeniem:

Instrukcję defrecord i powiązane funkcje omawiamy w podrozdziale 6.3, „Protokoły”.

Tłumacz – słusznie – uznaje, że po polsku to zdanie brzmiałoby koślawo bez wprowadzenia na początku rzeczownika określającego, cóż to jest owo defrecord. Wybiera słowo „instrukcja”, które nie budziłoby żadnych sprzeciwów, gdyby to była książka o Pythonie albo C. Tu jednak mam wątpliwości. Wiele języków programowania odróżnia wyrażenia od instrukcji, i w nich te drugie rozumiane są jako autonomiczne fragmenty wykonywalnego kodu potencjalnie zmieniającego stan programu. A przecież Clojure kładzie duży nacisk na niezmienność danych! Co więcej, w Clojure, jak we wszystkich Lispach i wielu innych językach funkcyjnych, tak rozumianych instrukcji nie ma (albo patrząc z innego punktu widzenia: termin ten jest tożsamy z terminem „wyrażenie”) -- kod programu po prostu składa się z wyrażeń.

Jeśli więc nie instrukcja, to co? W angielskim żargonie lispowym używane jest słowo form na określenie obiektu, który ma być poddany ewaluacji. Jeśli ten obiekt jest listą, której pierwszy element jest symbolem (i w takim razie składnia i semantyka listy są wyznaczone przez ten symbol, który może nazywać funkcję, makro albo wbudowaną konstrukcję języka), to nazwy tego symbolu używa się często jako przydawki. Mówi się więc o „defmacro forms”, „defvar forms”, itd. To właśnie to określenie mógł tu pominąć Halloway. A jak jest po polsku form? Znowu: nie ma powszechnej zgody. Można by to mechanicznie przełożyć na forma, ale moim zdaniem nazwą mniej przeładowaną znaczeniowo i bardziej oddającą sens jest formuła. W użyciu są obie wersje i w Google można znaleźć ich przykładowe wystąpienia.

(Na marginesie można oddać tłumaczowi sprawiedliwość, że Halloway tą elizją zdaje się sugerować, że defrecord jest funkcją, gdy w rzeczywistości jest to makro. Z drugiej strony, makra w Clojure są w istocie funkcjami, których vars (patrz niżej) mają ustawioną odpowiednią flagę, co powoduje specjalne traktowanie ich przez kompilator.)

Zmienna zmiennej nierówna

Znowu zacznę od cytatu, tym razem najpierw dwóch kawałków tłumaczenia:

Nie występują tu zmienne, modyfikowalny stan ani rozgałęzienia.

Przedrostek #' oznacza, że funkcję zapisano w zmiennej języka Clojure (...)

A tak wyglądają te fragmenty w oryginale:

It has no variables, no mutable state, and no branches.

The prefix #' indicates that the function was stored in a Clojure var (...)

W polskim tłumaczeniu w obydwu tych fragmentach pojawia się słowo zmienna. Tymczasem spojrzenie na oryginał ujawnia, że słowo to ma dwa różne odcienie znaczeniowe, z których każdy oddawany jest po angielsku inaczej: raz jest to variable, a raz var.

Co to jest variable, wiadomo z innych języków: nazwane „pudełko” przechowujące wartość. (Zauważmy, że Halloway używa tego słowa mówiąc o zmiennych w Javie.) Jest to termin ogólny i używany w kontekście wszystkich języków imperatywnych, jak C czy Perl. Natomiast var jest terminem węższym i oznacza jedną z clojurowych implementacji takiego pudełka. Dokładniej mówiąc, jest to obiekt klasy clojure.lang.Var. Obiekty takie mają dwie charakterystyczne cechy, nietypowe dla zmiennych z innych języków, a odróżniające je od atomów, również podobnych do zmiennych:

wartości var mogą być różne w różnych wątkach (przy czym istnieje koncepcja głównego wiązania, czyli wartości domyślnej, którą nowo utworzone wątki widzą dopóki jej sobie nie przesłonią własnym; takie wiązanie nie musi istnieć);
obiekty takie są pamiętane w przestrzeniach nazw: w istocie o przestrzeni nazw można myśleć jako o mapie wiążącej symbol z obiektem var.

(Taka dychotomia nazewnicza jest endemiczna dla Clojure i ma również miejsce przy funkcjach: w angielskim slangu clojurowym mówi się o fns, czytane „ef-ens”, co oznacza obiekty implementujące interfejs clojure.lang.IFn).

To dopiero dylemat dla tłumacza! Nie mam pojęcia, co mógłbym tu zaproponować. Można by pozostać przy długim, doprecyzowującym określeniu „zmienna języka Clojure” dla odróżnienia od „zmiennej” po prostu, ale ceną za to jest rozwlekłość. Nie wiem, czy można jej jakoś uniknąć.

INSERT INTO użytkownik (imię) VALUES ('Judyto')

Ach, kod wypluwający komunikaty w języku naturalnym! Błogosławieni użytkownicy angielszczyzny, albowiem oni odmianą przez przypadki martwić się nie muszą. Halloway, na nieszczęście tłumacza, wpada na pomysł uogólnienia kanonicznego „Hello, world” vel „Witaj, świecie” poprzez sparametryzowanie witanego obiektu.

Chciałoby się, żeby funkcja witająca zwracała się do użytkownika w wołaczu. Tłumacz osiąga to bez problemu:

(defn hello [name]
  (str "Witaj, " name))

I świetnie. Tylko, że trzeba wołać tę funkcję tak: (hello "Janku"), co jest trochę nienaturalne. A co, jeśli oprócz wyświetlenia powitania chcemy imię zapisać też w bazie danych? Z drugiej strony, licentia poetica tłumacza nie może sięgać tak daleko, żeby walnąć tu

(defn witaj [imię]
  (str "Witaj, " (odmień imię :wołacz)))

Warto, nie warto?

Czy warto będzie kupić „Programowanie w języku Clojure” i przeczytać po polsku? Myślę, że tak, o ile ktoś jeszcze nie czytał po angielsku lub woli ojczysty język nawet kosztem drobnych nieścisłości. Jak już mówiłem, jestem pełen uznania dla pracy tłumacza i chylę czoła. Podziwiam!

Mam za to wątpliwości, czy warto w ogóle tłumaczyć książki o technologiach. W pierwotnym zamyśle reszta niniejszej notki miała stanowić rozważania na ten temat, ale rozważania techniczne tak się rozrosły, że wpis zrobiłby się za długi. Więc o tym następnym razem.

O jaskiniach, programowaniu i poezji

2012-12-19T00:00:00Z

Emil w swojej ostatniej notce wspomina, że jego marzeniem jest napisanie przygodówki tekstowej. Moim też! Z tej okazji przypomniał mi się eseik, który wysłałem pięć lat temu na jedną z grup usenetowych; publikuję tu bez zmian, dodając tylko odnośniki i poprawiając literówki. Odnotuję też, że większość materiału historycznego jest zaczerpnięta z „Inform Designer's Manual” Nelsona (1997), a programik, który cytuję na końcu, nie kompiluje się już ostatnimi wersjami I7, choć pewnie wymaga niewielkich przeróbek z zachowaniem formy.

From: Daniel Janus 
Newsgroups: pl.hum.poezja
Subject: # o jaskiniach, programowaniu i poezji
Date: Sat, 29 Sep 2007 09:32:45 +0000 (UTC)
Message-ID:

Zaczęło się w 1838 roku.

Wtedy to właściciel Stephena Bishopa, niewolnika „szybkiego, śmiałego, entuzjastycznego”, wykupił ziemię w stanie Kentucky, na której terenie leżała Jaskinia Mamucia. Jej rzeczywisty rozmiar nie był wtedy jeszcze znany: nazwę nadali jej górnicy, wydobywający stąd ongi guano mamucie, z którego wyrabiano saletrę używaną do produkcji prochu. Stephenowi, samoukowi, człowiekowi bystremu, znającemu łacinę i grekę, powierzono opiekę nad jaskinią i w krótkim czasie stał się słynny jako władca podziemnego królestwa.

W kilka lat podwoił on znaną połać jaskini, nadał też nazwy -- półklasyczne, półamerykańskie – podziemnym korytarzom, rzekom, studniom: Rzeka Styks, Sala Lawinowa, Bezdnia, Wielka Kopuła. Wiele z tych nazw przetrwało do tej pory. Stephen oprowadzał po jaskini turystów, których zaczęło ściągać tam coraz więcej; mapa, którą naszkicował posiłkując się tylko własną pamięcią w roku 1842, była jeszcze w użyciu czterdzieści lat później. Stephen Bishop zmarł w roku 1857 jako wolny człowiek, uwolniony na mocy testamentu swojego właściciela.

Minął wiek. W czasie drugiej wojny światowej na terenach Jaskini ustanowiono park narodowy, co skutecznie odcięło napływ turystów. Coraz więcej osób jednak podejrzewało, że Jaskinia połączona jest systemem korytarzy z innymi okolicznymi jaskiniami, i poszukiwało przejścia; jednak bezskutecznie. Dopiero trzydzieści lat później, w roku 1972, Patricia Crowther, członkini ekspedycji badającej jaskinię Flint Ridge, przebrnęła przez ciasne, błotniste przejście i przedostała się do podziemnych głębi Jaskini Mamuciej; korytarz ten odkryto później ponownie na mapie Bishopa.

Trzy lata później mąż Patricii, William, programista w BBN (jednym z pionierów ARPAnetu, z którego później rozwinął się Internet), współuczestnik tamtej wyprawy, postanowił napisać program komputerowy, który jemu samemu przypominałby jaskiniowe lata, a zarazem byłby grą dla jego dzieci. Jak pisał później, miał to być program „nieodstraszający ludzi nieobeznanych z komputerem”, więc umożliwił wydawanie poleceń postaci kierowanej przez gracza w naturalnej angielszczyźnie, zamiast używania jakiegoś sztucznego zestawu komend. W grze Crowthera przemierzało się korytarze jaskini używając kierunków geograficznych; opisy pomieszczeń (z nazwami nadanymi jeszcze przez Bishopa) były zwięzłe, choć wielopoziomowe i bogate w szczegóły geologiczne. Crowther uczynił też niektóre przejścia niedostępnymi; aby się do nich dostać, należało pomyśleć nad rozwiązaniem ich zagadki i wykonać sekwencję określonych czynności.

Tak narodziła się interaktywna fikcja.

Mówię „interaktywna fikcja”, choć na początku używano terminu „gry przygodowe”, a później „przygodowe gry tekstowe” na określenie takich programów. I rzeczywiście były to gry przygodowe: pełne smoków, potworów, magii, ratowania księżniczek, dziejące się w najróżniejszych światach. (Zresztą program Crowthera został później podlany magiczno-baśniowym sosem i zorientowany raczej na zagadki niż na eksplorację, i to ta wersja jest najbardziej znana.) W latach osiemdziesiątych, wraz z upowszechnieniem się komputerów domowych, ten rodzaj rozrywki przeżył swoją świetność, głównie za sprawą firmy Infocom.

Okazało się jednak, że medium wymyślone przez Crowthera potrafi być czymś więcej, niż nośnikiem tylko dla gier przygodowych. Przykładem „Photopia” (Adam Cadre, 1998), opowiadająca historię o wolnej woli i determinizmie, w której gracz, choć znajduje się w centrum wydarzeń, nie ma na nie wielkiego wpływu (choć iluzja, że jest odwrotnie, jest silna); czy „Galatea” (Emily Short, 2000), dla której najwłaściwszym określeniem wydaje się być „studium psychologiczne”: jedno pomieszczenie, jedno światło padające z sufitu, protagonista i... ożywiona rzeźba na piedestale, z którą można rozmawiać na wiele sposobów. Interaktywna fikcja (już teraz określana właśnie tym terminem) odkryta została na nowo, jako rodzaj literatury. Jako -- Sztuka.

Po minionym boomie lat osiemdziesiątych zaczęły powstawać i rozpowszechniać się bezpłatnie systemy programistyczne ułatwiające tworzenie interaktywnej fikcji. Jednym z nich był Inform (Graham Nelson, 1993–): jego pionierska zasługa to skodyfikowanie ścisłych, choć poddających się elastycznym modyfikacjom w razie potrzeby, domyślnych reguł rządzących konstruowanym światem – modelu świata. System ten rozwijał się powoli, acz stabilnie, bez rewolucyjnych zmian, aż do wersji siódmej, kiedy Nelson postanowił radykalnie zmienić sposób tworzenia IF przy użyciu Informu. Co się zmieniło?

Aby używać wersji 1-6, trzeba było zostać programistą: nauczyć się specjalnej składni, obiektowo-imperatywnego paradygmatu programowania i sporej związanej z tym teorii. Inform 7 przyjmuje bardziej deklaratywne podejście i ukrywa sporą część pracy z tym związanej za fasadą języka, czyniąc następny krok w używaniu języka naturalnego: nie tylko w produkcie końcowym – ale też w kodzie źródłowym programu. Oto programy w Informie 7 pisze się w języku angielskim (albo do złudzenia go przypominającym), tyle tylko, że nieco bardziej skodyfikowanym.

Żeby nie być gołosłownym – oto pokój zawierający jabłko w Informie 6:

Constant Story "Hello World";
Constant Headline "^An Interactive Example^";

Include "Parser";
Include "VerbLib";

[ Initialise;
  location = Living_Room;
  "Hello World";
];

Object Room "Living Room"
with description "A comfortably furnished living room.",
has  light;

Object -> Apple "juicy apple"
with name 'juicy' 'apple' 'fruit',
     description "Looks yummy.";
has  edible;

Include "Grammar";

A oto ten sam pokój w Informie 7:

"Hello World" by Daniel Janus

The story headline is "An Interactive Example".

The Living Room is a room. "A comfortably furnished living room."
The apple is an edible thing in the Living Room. Description of
the apple is "Looks yummy." Understand "juicy", "apple" and
"fruit" as the apple.

Stąd już niedaleko do poezji. Na pewnym blogu ogłoszone zostało wyzwanie: czy da się napisać rymujący się wiersz (choćby i z rymami w stylu Nasha), który jest jednocześnie kompilującym się programem w Informie 7? Okazało się, że tak. I to nie byle jaki wiersz, bo sonet (a nawet metasonet – jego tematem są bowiem sonety!)

Oto on:

Will's Study is a room. The desk is here.
A hastily handwritten note is on it.
Description is "It's from your friend Shakespeare:
'I've gone to lunch. You'll have to write the sonnet.'"
Composing is an action applying to nothing.
The quill is a thing that is in the study.
Understand "write sonnet" as composing.
Description of the quill is "Old and cruddy".
Instead of composing when the player
has no quill, say "You have not got the quill."
Instead of composing, say "And... done. 'Heya',
says Will, returning. You say, 'Hello, Will!'
Says Shakespeare, 'Thank you for the time you've taken!
You really are a pal, Sir Francis Bacon.'"

-- Robin Johnson

(Przypis: akcje w Informie są motorem zmiany stanu świata; przebieg akcji jest podzielony na kilka etapów – dokładnie specyfikuje to model świata, o którym pisałem wcześniej. Specyfikacja, że coś ma się wykonać „zamiast” jakiejś akcji, oznacza interferencję w model na pierwszym etapie, zanim zaczną działać normalne reguły.)

I moje rudymentarne tłumaczenie:

Dębowe biurko stoi w gabinecie Willa.
Na nim kartka z notatką skreśloną starannie.
Opis: "Od przyjaciela twojego, Szekspira:
„Poszedłem na kolację, napisz sonet za mnie.”"
Pisanie jest to akcja bezargumentowa.
Gęsie pióro to przedmiot, co jest w gabinecie.
Opis pióra: "Możesz nim ubrać myśli w słowa."
Powiedz: "Nie możesz pisać, pióra nie masz przecie!"
zamiast pisania, gdy gracz nie posiada pióra.
Zamiast pisania, powiedz: "I oto - skończone.
Will powraca z kolacji z uśmiechem ponurym,
lecz wnet się rozpromienia, widząc gotów sonet.
Uśmiechasz się, Will także, chyląc głowę w skłonie:
„Dobry z Waści przyjaciel, Franciszku Baconie.”"

Oczywiście, to tylko połowa roboty, ta łatwiejsza – drugą będzie przeportowanie Informu 7 na język polski, tak aby powyższy wiersz dało się skompilować i sobie pograć :-)

Perfekcyjna niedoskonałość USOS-a

2012-09-28T00:00:00Z

Rzeczpospolita pisze o problemach z USOS-em:

– Poprawki oprogramowania nie są potrzebne, bo oprogramowania lepiej nie da się napisać – tłumaczy dr Janina Mincer-Daszkiewicz, kierownik Komisji ds. USOS z Uniwersytetu Warszawskiego. Jej zdaniem problem tkwi w liczbie logowań. – Jeśli w ciągu pierwszych pięciu minut trwania rejestracji na serwery uczelniane rzuca się 5 czy 10 tysięcy studentów, to i najlepszy komputer nie pomoże -- dodaje.

Nazwisko pani Mincer-Daszkiewicz jest doskonale znane każdemu studentowi informatyki na Wydziale MIM UW, który w ciągu ostatnich kilkunastu lat zdawał egzamin z systemów operacyjnych: jej zasługi nie tylko dydaktyczne, ale również na polu informatyzacji obsługi Wydziału, a także całego UW, są nie do przecenienia. Tym bardziej dziwi powyższa wypowiedź.

I nawet nie chodzi mi o to, że stwierdzenie, że nie da się obsłużyć dziesięciu tysięcy użytkowników naraz, jest zwyczajnie nieprawdziwe (wystarczy sobie uświadomić wielkość liczby żądań, jakimi w każdej sekundzie bombardowane są serwery wyszukiwarki Google, albo ilu użytkowników naraz jest średnio zalogowanych do Facebooka; bez kłopotu osiągalne jest 10 tys. żądań na sekundę nawet na pojedynczej maszynie). Problemem jest raczej mentalność wyczuwalna w pierwszym zdaniu.

Kto pierwszy powiedział: „dzieła sztuki nie są nigdy ukończone – są porzucane”? Nie wiem; guglanie za „never finished, only abandoned” daje najrozmaitsze wyniki i pokazuje tę frazę odnoszoną do najrozmaitszych dziedzin, w tym do oprogramowania. Każdy, kto kiedykolwiek pracował nad dostatecznie dużym systemem, wie, jak bardzo jest to prawdziwe. Zawsze można coś poprawić: zwiększyć wydajność, odchudzić, dopracować; nie ma siódmego dnia, w którym można by odpocząć i popatrzeć z dumą na ukończone dzieło. Pani Mincer-Daszkiewicz zdaje się sądzić, że USOS osiągnął stan perfekcji; nie, nie osiągnął, podobnie jak nie osiągnął go żaden inny system.

A poprawiać jest co. Świadczy o tym pomruk niezadowolenia setek studentów, niemogących „wbić się” do USOSweb. Gdyby USOS realizowany był jako przedsięwzięcie komercyjne, to ze względu na to, że realia rynkowe wymuszają takie myślenie – ktoś by w końcu przyszedł i powiedział: „tak nie może być”. Nie może, bo bywa nieużywalne w fundamentalny sposób; nie może, bo udostępnienie produktu w takiej postaci klientom narazi przedsiębiorstwo na duże straty. Tłumaczenie się ograniczeniami architekturalnymi jest nie do przyjęcia: jeśli architektura w obecnej postaci nie pozwala na sensowne działanie systemu, to znaczy, że trzeba go przeprojektować.

Bardzo starałem się nie oddzielić grubą linią „podejścia biznesowego” od „akademickiego”, bo po obu stronach są i chlubne, i mniej chlubne przykłady. W ramach promocji tych pierwszych skorzystam z okazji i polecę stronę dr Włodzimierza Bzyla z Uniwersytetu Gdańskiego; widać z niej pragmatyzm, duże zainteresowanie nowoczesnymi narzędziami i dążenie do przygotowywania studentów do późniejszej praktyki zawodowej -- słowem, autor wie o co chodzi. Oby takich więcej!

Praktyczne użycie monady state

2012-01-10T00:00:00Z

Wreszcie rozumiem monady!

Pierwszy raz zetknąłem się z nimi dobrych osiem lat temu, przy okazji nauki Haskella; wtedy jednak nie starczyło mi cierpliwości, aby zaznajomić się z podstawami teoretycznymi. Sprawy nie ułatwiał fakt, że trudno o naprawdę przystępne i zrozumiałe wprowadzenie do tego tematu: wygląda na to, że każdy adept Haskella, zrozumiawszy monady, pisze na ten temat własny tutorial. Ja się powstrzymam od tego naturalnego odruchu i po prostu odeślę do niesamowicie szczegółowego, ośmioczęściowego cyklu artykułów autorstwa Mike'a Vaniera, który -- wreszcie! – sprawił, że coś mi „zaskoczyło” w umyśle. Zamiast tego w tym wpisie wynotuję najważniejsze spostrzeżenia, jakie zapamiętałem, a potem pokażę dwie wersje pewnego kodu operującego na sekwencjach bitów: niemonadyczną i napisaną z użyciem monady state.

Mike zakłada znajomość Haskella, jak pisze we wstępie, na poziomie typów polimorficznych i klas typów; w praktyce jednak myślę, że do zrozumienia tekstu wystarczy pewne obycie z haskellową notacją (bardzo zresztą przypominającą zwykłą notację matematyczną), bo bardziej zaawansowane rzeczy są wyjaśniane w tekście na bieżąco. Bardzo polecam.

Oto więc moje notatki:

Kluczowe dla zrozumienia monad jest pojęcie funkcji monadycznych; znacznie łatwiej jest je sobie intuicyjnie wyobrazić niż monadyczne wartości, zwracane przez m-return. Mike podaje pewne intuicje także dla tych drugich, ale dla mnie ważne jest, żeby myśleć o monadach w kategoriach (wzbogaconych) funkcji, a nie wartości przez nie zwracanych.
Łatwo wydefiniować przy użyciu prostego złożenia operacji m-bind i m-return funkcję składającą ze sobą dwie funkcje monadyczne. Przy użyciu tego operatora, który Mike nazywa <=<, prawa rządzące monadami wyrażają się w elegancki i prosty do zapamiętania sposób: jest to operator łączny oraz m-return jest jego lewą i prawą jedynką.
I bodaj najistotniejsza rzecz – nie trzeba rozumieć monad, żeby ich używać. Niby oczywiste i niby tak właśnie pisałem do tej pory kod haskellowy, radośnie używając do-notacji tak jakbym pisał kod imperatywny; ale okazuje się, że w ten sam sposób można z powodzeniem używać monady stanu i wyjaśnić, co ona robi, zupełnie w oderwaniu od całej reszty teorii monad. Wiedza na temat tego, co się dzieje „pod spodem”, jest konieczna tylko (i aż!) do zrozumienia, co poszczególne monady mają ze sobą wspólnego.

Reszta tego wpisu będzie poświęcona właśnie przykładowemu użyciu monady stanu w Clojure. Pisałem wcześniej, że nie widziałem dotąd kodu, który dałby się wyrazić przejrzyściej zapisany z użyciem monad niż bez nich – i właśnie na taki kod się natknąłem.

Wyobraźmy więc sobie, że mamy strumień bitów. Dla prostoty zdefiniujmy sobie przykładowy strumień, na którym będziemy testować nasze funkcje, jako clojurowy wektor zer i jedynek.

(def v [1 1 1 0 1 0 1 0 1 0])

Chcemy naddać naszemu strumieniowi pewne uporządkowanie: zdekodować zera i jedynki, które z niego przychodzą, według jakiegoś kodu o zmiennej długości. Najbardziej oczywistym, znanym każdemu kodem jest kod binarny: czytamy ze strumienia ileś bitów, traktujemy je jako binarną (bez znaku) reprezentację pewnej liczby i zwracamy tę liczbę. Łatwo napisać w Clojure funkcję, która to robi.

(defn read-binary [n bits]
  (loop [res 0 n n [fst & rst :as bs] bits]
    (if (zero? n)
      [res bs]
      (recur (+ res res fst) (dec n) rst))))

Spróbujmy wczytać z naszego strumienia czterobitową liczbę:

(read-binary 4 v)
;=> [14 (1 0 1 0 1 0)]

Czternaście. Ale zauważmy, że zdekodowana liczba nie jest jedyną zwracaną wartością! Żeby dało się z naszego strumienia odczytywać dalsze liczby, musimy zwrócić parę (wektor dwuelementowy): wartość odczytana plus reszta strumienia, z której będziemy czytać dalej. Piszemy wszak funkcyjnie: nie zmieniamy naszych wartości w miejscu, tylko z jednych wartości produkujemy następne.

Innym rodzajem kodu jest kod unarny: czytamy po prostu ze strumienia jedynki, aż napotkamy pierwsze zero – wtedy przestajemy czytać i naszą wartością jest liczba przeczytanych bitów. W ten sposób dowolną liczbę dodatnią n da się zareprezentować na n bitach. Implementacja jest równie prosta:

(defn read-unary [bits]
  (loop [n 1 [fst & rst] bits]
    (if (zero? fst)
      [n rst]
      (recur (inc n) rst))))

Sprawdzamy:

(read-unary v)
;=> [4 (1 0 1 0 1 0)]

Trzy jedynki i zero, razem cztery skonsumowane bity, więc odczytaną liczbą jest 4. Działa.

Spróbujmy teraz skleić nasze funkcje, to znaczy odczytać ze strumienia dwie liczby: najpierw zakodowaną unarnie, a potem binarnie na sześciu bitach.

(let [[x v1] (read-unary v)
      [y v2] (read-binary 6 v1)]
  [x y])
;=> [4 42]

Wynik jest poprawny, ale kod nieelegancki: tak naprawdę nie interesują nas te wszystkie v, v1, v2, które przepychamy przez nasze funkcje; potrzebujemy tylko przeczytanych liczb, a poszczególne części strumienia są nam tylko po to, żeby mieć z czego czytać. Im więcej składanych ze sobą operacji, tym łatwiej się pomylić.

Tu wkracza monada stanu, która umożliwia ukrycie tych pośrednich wartości i bardziej eleganckie złożenie read-unary i read-binary. Monadycznie zapisalibyśmy to jakoś tak:

(domonad state-m
         [x read-unary
          y (partial read-binary 6)]
         [x y])
;=> #

Wygląda to bardzo podobnie. domonad state-m jest jak let. Tak jak chcieliśmy, nie przekazujemy naszego stanu (strumienia) explicite; zamiast tego przy x i y podajemy funkcje, które mają być zawołane na aktualnym stanie, żeby uzyskać żądaną wartość i nowy stan.

No dobrze, ale gdzie tu miejsce na nasz stan początkowy? Jak go przekazać? Proste: powyższa formuła, jak widać z mało czytelnego wyniku, zwróciła jakąś funkcję. Wystarczy ją teraz zawołać na naszym początkowym stanie, aby uzyskać wynik wraz ze stanem końcowym:

(*1 v)
;=> [[4 42] nil]

Jedyne, co wydaje się nadmiarowe w naszym złożeniu, to owo partial pojawiające się wyżej. Jest to efekt uboczny faktu, że Clojure w odróżnieniu od Haskella rozróżnia funkcje jedno- i więcejargumentowe (tak dokładniej to w Haskellu występują wyłącznie funkcje jednoargumentowe). Skoro w domonad state-m powinny na przemian pojawiać się symbole i funkcje jednoargumentowe biorące stan, to gdy nasza funkcja akceptuje coś jeszcze (tu: liczbę bitów), powinniśmy zrobić z niej funkcję jednoargumentową za pomocą partial. Alternatywnie, jeżeli chcemy trzymać się stylu monadycznego, możemy przepisać read-binary jako:

(defn read-binary [n]
  (fn [bits]
    (loop [res 0 n n [fst & rst :as bs] bits]
      (if (zero? n)
        [res bs]
        (recur (+ res res fst) (dec n) rst)))))

Teraz zamiast (partial read-binary 6) możemy napisać po prostu (read-binary 6).

Teraz, kiedy umiemy już składać operacje stanowe, zilustrujemy to przy pomocy jeszcze jednego kodu, a właściwie rodziny kodów nazywanych kodami Golomba. Po szczegółowy opis odsyłam do Wikipedii, natomiast dla potrzeb tego artykułu wystarczy nam wiedza, że te kody są parametryzowane jedną liczbą m. Liczba w kodzie Golomba jest podzielona na dwie części, z których pierwsza jest zakodowana unarnie, a druga -- nie większa niż m – binarnie. W implementacji możemy więc skorzystać z naszych gotowych już funkcji read-unary i read-binary.

Bez dłuższych już komentarzy przedstawię dwie implementacje: eksplicytną i używającą monady stanu. Obie będą używać pomocniczej funkcji read-bit, czytającej po prostu jeden bit ze strumienia i używanej tak samo jak read-unary czy read-binary.

(defn read-bit [[bit & bits]]
  [bit bits])

Najpierw wersja niemonadyczna:

(defn read-golomb [m]
  (fn [bits]
    (let [k (clog2 m)
          r (- (bit-shift-left 1 k) m)
          [a bits1] (read-unary bits)
          [b bits2] ((read-binary (dec k)) bits1)
          [ir bits] (if (< b r)
                      [b bits]
                      (let [[nb bits] (read-bit bits)]
                        [(+ b b nb (- r)) bits]))]
      [(+ (* (dec a) m) ir) bits])))

A teraz używająca monad. Żeby nie przeplatać let i domonad, można po prostu zdefiniować funkcję zwracającą pewną stałą wartość i niezmieniony stan – nazwę ją m-const:

(defn m-const [x]
  (fn [state]
    [x state]))

Używając jej, możemy zaimplementować read-golomb tak:

(defn read-golomb-monadic [m]
  (domonad state-m
           [k (m-const (clog2 m))
            r (m-const (- (bit-shift-left 1 k) m))
            a read-unary
            b (read-binary (dec k))
            nb (if (< b r) (m-const nil) read-bit)]
           (+ (* (dec a) m)
              (if (< b r) b (+ b b nb (- r))))))

Czytelniej?

ClojureScript

2011-07-21T00:00:00Z

Rich Hickey, autor Clojure, wyrasta na Steve'a Jobsa nowoczesnych języków programowania – przynajmniej jeśli idzie o sposób prezentacji swoich dzieł. Oto kilka dni temu na grupie dyskusyjnej Clojure pojawiło się ogłoszenie, że Rich wystąpi na najbliższym spotkaniu nowojorskiej grupy użytkowników Clojure, że strumień wideo z wystąpienia będzie nadawany na żywo i że zaprezentowane zostanie „coś nowego”.

Tym czymś okazał się ClojureScript: kompilator Clojure do JavaScriptu, łączący moc pierwszego języka z powszechnością drugiego.

JavaScript bywa nazywany „czarnym koniem” języków programowania, najbardziej niedocenianym językiem minionej dekady i najważniejszym obecnej. Istotnie, silniki JavaScriptu w przeglądarkach – a także wolnostojące, jak Node.js – poczyniły w ostatnich latach kolosalne postępy, jeśli chodzi o wydajność, narzędzie to jest coraz chętniej używane do programowania coraz poważniejszych aplikacji i nie mijając się z prawdą można powiedzieć, że JavaScript jest wszędzie.

A teraz te same słowa można odnieść również do Clojure. W tegorocznym sondażu, podobnie jak rok temu, społeczność Clojure najczęściej wskazywała JavaScript jako hipotetyczną alternatywną wobec JVM platformę, ale zapewne mało kto się spodziewał, że urzeczywistni się to tak szybko. Łatwo sobie uzmysłowić możliwości, jakie daje nowa implementacja. Ten sam kod na serwerze i w przeglądarce? Programowanie aplikacji iOS w Clojure? Jak najbardziej!

W ramach dodawania łyżki dziegciu do tej beczki miodu trzeba zauważyć jednak, że dialekt ClojureScript jest okrojony i ma nieco inną semantykę niż standardowy Clojure: nie ma STM, niezmienność struktur danych nie jest wymuszana, wektory są zwykłymi JavaScriptowymi tablicami. Czy to się zmieni, pokaże przyszłość.

Jaka przyszłość czeka Clojure i ClojureScript? Spróbuję pokusić się o przepowiednię:

Pojawienie się alternatywnej wobec JVM platformy wymusi ukształtowanie się bogatszej niż do tej pory biblioteki standardowej Clojure, wspólnej dla obu wersji. Ten proces trwa już teraz: tam, gdzie w czasach Clojure 1.0 pisało się (.toUpperCase "foo") (wychodząc z założenia where Java isn't broken, Clojure doesn't fix it), teraz kanoniczną formą jest (clojure.string/upper-case "foo"). W ten sposób Clojure stopniowo stanie się językiem niezabawkowym według definicji Maćka Pasternackiego.
ClojureScript otworzy dla Clojure zupełnie nową niszę: stanie się popularny wśród programistów-frontendowców, piszących do tej pory głównie w JavaScripcie lub CoffeeScripcie.
Równocześnie pojawienie się ClojureScript nie oznacza, że zatrzymają się prace nad „tradycyjnym” Clojure. JVM pozostanie główną platformą rozwoju języka i to tam będą pojawiać się kolejne innowacyjne cechy. Wersja 1.3 jest już w fazie beta i nadanie jej statusu final jest kwestią kilku tygodni.

Patrząc wstecz, aż trudno uwierzyć, jak dużą popularność zdobyło sobie Clojure. Gdyby ktoś mi cztery lata temu powiedział, że za cztery lata pojawi się nowy język z rodziny Lisp, który będzie znacznie bardziej elegancki niż Common Lisp, znacznie praktyczniejszy niż Scheme i używać go będą wielkie instytucje finansowe, wyśmiałbym go. A jednak: zaczynam wierzyć, że prawo Kopernika jednak nie stosuje się w informatyce.

Smyrna

2011-02-12T00:00:00Z

Dziś chciałbym zaprezentować kolejny stworzony przeze mnie przykład wykorzystania Clojure w praktyce – program Smyrna. To proste narzędzie do przeszukiwania korpusów: umożliwia łatwe zindeksowanie zbioru dokumentów w formacie HTML, wyszukanie wystąpień interesującego nas leksemu i stworzenie listy frekwencyjnej słów.

Program zrodził się z potrzeby chwili (potrzebowałem porównać wystąpienia pewnej grupy słów w różnych zestawach danych), ale uznałem, że jest na tyle użyteczny, że może przydać się nie tylko mnie. Zwłaszcza że nie było dotąd programu na wolnej licencji, który by umożliwiał łatwe przeszukiwanie własnych zbiorów polskich tekstów. Można wykorzystać Poliqarpa, w którym też maczałem palce (a raczej nurzałem ręce), jednak używanie go z własnymi zbiorami danych wymaga ekwilibrystyki w stylu dxces i jest trudne do przeskoczenia dla nietechnicznych użytkowników. Jest więc Smyrna swoistym uzupełnieniem dla Poliqarpa – stąd zresztą nazwa.

Z technicznego punktu widzenia interesujący może być sposób, w jaki skonstruowałem interfejs użytkownika. Mimo że Smyrna jest w zasadzie aplikacją desktopową, obsługuje się ją przez przeglądarkę WWW: uruchamiany jest lokalny serwerek HTTP na porcie 8080, a następnie przeglądarka z tym adresem; cała dalsza komunikacja między JavaScriptowym kodem klienckim a Clojurowym silnikiem przeszukującym odbywa się przez JSON-RPC.

W ramach ćwiczenia, kliencki kod napisałem w nowej, alternatywnej składni dla JavaScriptu, czyli zyskującym coraz większą popularność CoffeeScripcie. Eksperyment uważam za udany: kod wychodzi czytelniejszy i zwięźlejszy niż w "zwykłym" JS.

Clojure: czyszczenie dowiązań lokalnych

2011-01-31T00:00:00Z

O jednej z nowych cech Clojure 1.2 dowiedziałem się dopiero niedawno, bo jej wprowadzenie przeszło właściwie bez echa. Może dlatego, że to optymalizacja niewidoczna na zewnątrz; jednak rozwiązuje ważny problem i dlatego warto mieć świadomość jej istnienia. Chodzi o locals clearing, które tłumaczę na polski jako „czyszczenie lokalnych dowiązań”.

Wyobraźmy sobie taką sytuację: mamy do wykonania skomplikowane obliczenie. Możemy je podzielić na mniejsze kroki; na każdym etapie wyliczamy nowy pośredni wynik na podstawie tylko niewielu ostatnich kroków – jednego, może dwóch. Załóżmy jeszcze, że te pośrednie wyniki są dużych rozmiarów: powiedzmy setek megabajtów. To częsty przypadek, kiedy wykonuje się np. obliczenia na dużych, gęstych macierzach: najpierw normalizujemy każdy z wektorów naszej macierzy, potem ją transponujemy, następnie liczymy jej rozkład własny i odrzucamy część wektorów własnych.

W Javie wyglądałoby to tak:

void calculate(Matrix m) {
    Matrix m1 = step1(m);
    Matrix m2 = step2(m1);
    // i tak dalej, każdy krok odwołuje się do poprzedniego
}

Jest to jednak prosta droga do pojawienia się OutOfMemoryError, o ile nie dysponujemy wystarczającą ilością pamięci, aby pomieścić wszystkie kroki. Gdy m2 jest obliczone, wartość m1 jest już niepotrzebna i w zasadzie można by zwolnić zajmowaną przez nią pamięć. Odśmiecacz jednak tego nie zrobi, dopóki wywołanie funkcji calculate nie zakończy się, ponieważ do tej pamięci odwołuje się ramka na stosie wywołań.

Zilustrujmy to uruchamialnym przykładem:

public class foo {
    public static byte[] calculate(byte[] lastStep) {
        return new byte[10485760];
    }

    public static void main(String... args) {
        byte[] a, b, c, d;
        a = calculate(null);
        b = calculate(a);
        c = calculate(b);
        d = calculate(c);
        System.out.println("OK");
    }
}

Funkcja calculate emuluje skomplikowane obliczenia, alokując za każdym razem 10-megabajtowy blok pamięci. Jeśli skompilujemy ten program i uruchomimy go w środowisku z maksymalnym rozmiarem sterty ograniczonym do 30 MB (java -Xmx30M foo), zobaczymy błąd braku pamięci.

Inaczej jest w Clojure. Odpowiednik powyższego programu wygląda tak:

(defn calculate [last-step]
  (make-array Byte/TYPE 10485760))

(defn -main [& args]
  (let [a (calculate nil)
        b (calculate a)
        c (calculate b)
        d (calculate c)]
    (println "OK")))

W Clojure 1.2 i nowszych ten program wypisze OK, nawet gdy będzie miał do dyspozycji tylko 30 MB pamięci.

Dlaczego to działa? Okazuje się, że kompilator Clojure przeprowadza statyczną analizę każdego kawałka kodu, w którym wartości są dowiązane do nazw (czyli każdego użycia formuły let), i dla każdego dowiązania sprawdza, w którym miejscu jest ono ostatni raz używane, biorąc pod uwagę wszystkie możliwe ścieżki wykonania. Natychmiast po ostatnim użyciu emitowany jest bajtkod zerujący odpowiednią zmienną (ustawiający wskaźnik na null). Innymi słowy, efekt jest taki, jakbyśmy w przykładowym kodzie w Javie wstawili instrukcję a = null; zaraz po obliczeniu b i analogicznie dalej.

O jednej z sytuacji, w których takie czyszczenie się przydaje, już powiedziałem. Innym częstym przypadkiem jest branie za punkt wyjścia długiej (być może nawet nieskończonej) leniwej sekwencji, która jest realizowana w kolejnych krokach obliczeń. Dzięki automatycznemu czyszczeniu odśmiecacz może pozbyć się pierwszych, niepotrzebnych już elementów zrealizowanej sekwencji, co umożliwia pisanie klarownego kodu bez troszczenia się o jego poprawność pamięciową.

Jak jednak napisał mi Rich Hickey, sama alokacja pamięci w momencie wiązania nazwy nie jest uważana za użycie tej nazwy. Stąd jeśli nazwa nigdy nie zostanie użyta, to odpowiadająca jej wartość nie zostanie też odśmiecona aż do opuszczenia ciała bloku let. Dlatego też nie mogłem pominąć w powyższym przykładzie argumentu last-step funkcji calculate. Jednak taki przypadek nie pojawia się w praktyce: wszak jeśli wyliczamy jakiś wynik, to nie po to, by go do niczego nie użyć!

Pokoloruj sobie Europę!

2011-01-19T00:00:00Z

To jest druga część minicyklu zapoczątkowanego artykułem o zipperach. Temat ten zaprezentowałem również podczas wystąpienia na spotkaniu Warszawa JUG. Dostępne są slajdy z tej prezentacji (uwaga: slajdy mają postać oskryptowanego HTML; należy je oglądać w Firefoksie lub którejś przeglądarce WebKitowej). Można również obejrzeć nagranie wideo wystąpienia, niestety ze słabą jakością dźwięku.

Problem

Jakiś czas temu zostałem poproszony o sporządzenie kilku mapek Europy pokolorowanych w różny sposób. Dostałem kilka zestawów danych, w których każdemu krajowi UE przypisana była jakaś liczba: im większa ta wartość, tym ciemniejszym odcieniem państwo miało być zaznaczone na mapce. Przykładowa pokolorowana mapka miała wyglądać tak:

Rozpocząłem od ściągnięcia łatwo edytowalnej mapy ze stron Wikimedia Commons, obliczyłem potrzebne intensywności kolorów dla pierwszego zestawu, uruchomiłem Inkscape i zabrałem się do kolorowania. Po półgodzinie żmudnego klikania zdałem sobie sprawę, że prościej i szybciej byłoby mi napisać programik w Clojure, który wygeneruje mapkę za mnie. Okazało się to zadaniem dość prostym: reszta tego postu będzie rekonstrukcją przedsięwziętych przeze mnie kroków.

SVG

Formatem źródłowego obrazka jest SVG. Wiedziałem, że to XML-owy otwarty format grafiki wektorowej, często widywałem na Wikipedii obrazy w tym formacie – jednak jego ręczna edycja to coś, z czym nie miałem do tej pory do czynienia. Szczęśliwie okazało się, że obrazek z mapkami ma prostą strukturę. Krzywa-obwiednia każdego kraju jest opisana elementem path, wyglądającym mniej więcej tak:

<path
  id="pl"
  class="eu europe"
  d="współrzędne kolejnych węzłów krzywej (bardzo dużo)" />

Warto zwrócić uwagę na atrybut id – jest to dwuliterowy skrót ISO-3166-1-ALPHA2 nazwy kraju. Na początku kodu obrazka znajduje się zresztą komentarz, który wyjaśnia użyte konwencje nazewnicze. Dysponowanie tak porządnie przygotowanymi danymi wejściowymi znakomicie ułatwiło mi pracę.

Jak się okazuje, SVG, podobnie jak HTML, używa stylów CSS do definiowania wyglądu elementów. Wszystko, co trzeba zrobić do nadania Polsce koloru czerwonego, to nadanie odpowiedniej wartości atrybutowi stylu fill:

<path
  id="pl"
  style="fill: #ff0000;"
  class="eu europe"
  d="współrzędne kolejnych węzłów krzywej (bardzo dużo)" />

Uzbrojeni w taką wiedzę, możemy rozpocząć pracę.

XML w Clojure

Podstawowym sposobem obsługi XML w Clojure jest wykorzystanie biblioteki clojure.xml, pozwalającej na parsowanie XML-a (na zasadzie DOM, tzn. do struktury w pamięci) oraz serializację, tzn. działanie w odwrotną stronę. Uruchommy więc REPL i zacznijmy od wczytania naszej mapki i sparsowania jej:

> (use 'clojure.xml)
nil
> (def m (parse "/home/nathell/eur/Blank_map_of_Europe.svg"))
[...dłuuugie oczekiwanie...]
Unexpected end of file from server
  [Thrown class java.net.SocketException]

Zaraz! Jaki znowu SocketException? Firefox wyświetla tę mapkę poprawnie, Chromium też, WTF? W tak świetnym języku, jakim jest Clojure, wszystko powinno działać od ręki?!

Cóż, język jest tak dobry, jak dobre są jego biblioteki – a jeśli chodzi o Clojure, można to rozwinąć: biblioteki Clojure są tak dobre, jak dobre są biblioteki Javy, których używają pod spodem. W tym wypadku natrafiliśmy na cechę standardowego (z pakietu javax.xml) parsera XML w Javie. Jest on restrykcyjny i stara się odrzucać dokumenty, które nie są poprawne (w sensie valid, a nie tylko well-formed). Jeśli tylko dany plik zawiera deklarację DOCTYPE, to parser javowy, a za nim clojure.xml/parse, próbuje ściągnąć z podanego adresu schemat DTD i zwalidować dokument według tego schematu. Jest to działanie z wielu względów niepożądane, zwłaszcza z punktu widzenia World Wide Web Consortium, bo to na serwerach tej organizacji przechowywane są schematy opisujące sieciowe standardy. Łatwo sobie wyobrazić, jak duży ruch sieciowy generują nadgorliwe parsery: traktuje o tym post na blogu W3C. Zapewne wielu programistów Javy zetknęło się kiedyś z tym problemem. Jest kilka rozwiązań; użyjemy najprostszego z nich, czyli po prostu... ręcznie usuniemy przeszkadzającą deklarację DOCTYPE.

> (def m (parse "/home/nathell/eur/bm.svg"))
#'user/m
> m
[...wiele ekranów liczb...]

No, tym razem udało się wczytać. Obejrzenie sparsowanej struktury jest utrudnione z uwagi na jej wielkość (można było się tego spodziewać: plik SVG waży ponad 0,5 MB!), ale z samego początku tego, co nam wypluwa REPL, widzimy, że jest to mapa. Zobaczmy, z jakich kluczy się składa:

> (keys m)
(:tag :attrs :content)

Jest to więc mapa o trzech polach: z nazw (albo z dokumentacji) można się domyślić, co zawierają. Pole :tag to nazwa elementu XML, :attrs jest mapą atrybutów tego elementu, a :content – sekwencją jego podelementów, z których każdy jest znów reprezentowany przez mapę o takiej samej strukturze (względnie przez napis, jeśli jest to element napisowy):

> (:tag m)
:svg
> (:attrs m)
{:xmlns "http://www.w3.org/2000/svg", :width "680", :height "520", :viewBox "1754 161 9938 7945", :version "1.0", :id "svg2"}
> (count (:content m))
68

Tak dla wprawki, spróbujmy zapisać sparsowaną reprezentację z powrotem jako XML. Funkcja emit powinna być w stanie to zrobić, ale wypisujekl ona XML na standardowe wyjście. Możemy użyć makra with-out-writer z pakietu clojure.contrib.io, aby zrzucić XML-a do pliku:

> (use 'clojure.contrib.io)
nil
> (with-out-writer "/tmp/a.xml" (emit m))
nil

Próbujemy otworzyć wynikowy obrazek w Firefoksie i...

Błąd parsowania XML: nieprawidłowo sformowany
Obszar: file:///tmp/a.xml
Numer linii: 15, kolumna 44: Updated to reflect dissolution of Serbia & Montenegro: http://commons.wikimedia.org/wiki/User:Zirland
----------------------------------------------------------------------^

Argh! Wygląda na to, że znaleźliśmy błąd w clojure.xml: elementy zawierające ampersandy nie są poprawnie serializowane, przez co późniejsze parsowanie się nie powodzi. Zgłosimy ten błąd później, a teraz usuńmy znowu doraźnie wskazaną przez Firefoksa linijkę (możemy to bezpiecznie zrobić, bo to tylko komentarz). Jeśli teraz powtórzymy nasze dotychczasowe kroki, zobaczymy, że wygenerowany XML jest wreszcie poprawny.

Kolorujemy Polskę

Widzieliśmy wcześniej, że główny element XML w naszym pliku zawiera 68 podelementów. Zobaczmy, jakie one są – wystarczą nam tagi:

> (map :tag (:content m))
(:title :desc :defs :rect :path :path :path :path :path :path :path :path :path :path :path :path :path :path :path :path :path :path :path :path :path :path :path :path :path :path :path :path :path :path :path :path :path :path :path :path :path :path :path :path :path :path :path :path :path :path :path :path :path :path :path :path :path :path :path :path :path :g :path :path :g :path :path :path)

Jak dotąd jest świetnie. Wygląda na to, że wszystkie opisy krajów są bezpośrednio zawarte w głównym elemencie jako podelementy. Spróbujmy znaleźć Polskę:

> (count (filter #(and (= (:tag %) :path)
                       (= ((:attrs %) :id) "pl"))
                 (:content m)))
1

(Ten kawałek kodu wybiera z listy podelementów m takie, których tag to path, a wartość atrybutu id to "pl" i zwraca długość takiej podlisty). Spróbujmy teraz dodać do tego elementu atrybut style, zgodnie z tym, co powiedzieliśmy wcześniej. Ze względu na niezmienność struktur danych musimy zdefiniować nowy nadrzędny element, który będzie taki sam, jak m, z tym, że odpowiedniemu podelementowi ustawimy styl:

> (def m2 (assoc m
                :content
                (map #(if (and (= (:tag %) :path)
                               (= ((:attrs %) :id) "pl"))
                        (assoc % :attrs (assoc (:attrs %) :style "fill: #ff0000;"))
                        %)
                     (:content m))))
#'user/m2
> (with-out-writer "/tmp/a.svg" (emit m2))
nil

Otwieramy utworzony plik i widzimy mapkę z Polską zaznaczoną na czerwono. Hura!

Generalizacja

Uogólnimy trochę nasz kod. Napiszemy funkcję, która pokoloruje jedno państwo, dostając na wejściu element path (podelement svg):

(defn color-state
  [{:keys [tag attrs] :as element} colorize-fn]
  (let [state (:id attrs)]
    (if-let [color (colorize-fn state)]
      (assoc element :attrs (assoc attrs :style (str "fill:" color)))
      element)))

Jest to funkcja bardzo podobna do tej anonimowej, użytej powyżej w wywołaniu map, ale różni się w kilku szczegółach. Po pierwsze, bierze dwa argumenty. Jednym jest, jak powiedzieliśmy, element XML-owy (od razu rozbity na tag i attrs: więcej o takiej notacji, zwanej destructuring („dzielenie struktury”) można przeczytać w odpowiedniej części dokumentacji Clojure), a drugim... funkcja, która dostanie jako argument dwuliterowy kod państwa i zwróci HTML-owy opis jego koloru (lub nil, jeśli kolor dla tego państwa nie jest określony – color-state poradzi sobie z tym i zwróci element w stanie nienaruszonym).

Mając color-state, możemy łatwo napisać funkcję wyższego poziomu, która w jednym kroku przetworzy i zapisze XML:

(defn save-color-map
  [svg colorize-fn outfile]
  (let [colored-map (assoc svg :content (map #(color-state % colorize-fn) (:content svg)))]
    (with-out-writer out
      (emit colored-map))))

Testujemy:

> (save-color-map m {"pl" "#00ff00"} "/tmp/a.svg")
nil

Tym razem Polska jest zielona (jako argumentu color-state użyliśmy mapy kraj→kolor, bo mapy są w Clojure wołalne jak funkcje). Spróbujmy dorzucić niebieskie Niemcy:

> (save-color-map m {"pl" "#00ff00", "de" "#0000ff"} "/tmp/a.svg")
nil

Działa!

Problem z Wielką Brytanią

Zachęceni sukcesem, próbujemy kolorować różne kraje. Dla większości działa, ale Wielka Brytania jak była szara, tak jest, niezależnie od tego, czy podamy jej kod jako „uk”, czy jako „gb”. Zaglądamy jeszcze raz do źródła naszego obrazka. Komentarze na początku jak zwykle okazują się pomocne:

Certain countries are further subdivided the United Kingdom has gb-gbn for Great Britain and gb-nir for Northern Ireland. Russia is divided into ru-kgd for the Kaliningrad Oblast and ru-main for the Main body of Russia. There is the additional grouping #xb for the „British Islands” (the UK with its Crown Dependencies - Jersey, Guernsey and the Isle of Man)

Może więc trzeba podać „gb-gbn” i „gb-nir”, zamiast samego „gb”? Próbujemy i... też nie działa. Po chwili namysłu: no jasne! Nasze początkowe założenie, że wszystkie definicje krajów są bezpośrednimi podelementami path, okazuje się fałszywe. Trzeba to naprawić.

Dotychczas robiliśmy „płaską” transformację drzewa SVG: zamienialiśmy wszystkie podelementy elementu głównego i nic głębiej. Trzeba by zmienić wszystkie elementy path (i g, jeśli chcemy kolorować grupy takie jak Wielka Brytania), niezależnie od tego, jak głęboko siedzą w drzewie. Z pomocą przychodzi funkcja map-zipper z poprzedniego odcinka.

Zważywszy, że funkcja clojure.xml/zip-xml zwraca zipper działający na drzewach XML-owych, przepisujemy save-color-map jako:

(defn save-color-map
  [svg colorize-fn outfile]
  (let [colored-map (map-zipper #(color-state % colorize-fn) (fn [x] (#{:g :path} (:tag x))) (zip/xml-zip svg))]
    (with-out-writer out
      (emit colored-map))))

Tym razem Wielka Brytania już daje się pomalować.

Koloryzatory

Mamy już zautomatyzowany sam proces kolorowania, ale tłumaczenie konkretnych wartości liczbowych na RGB jest żmudne. W ostatniej części tego artykułu zobaczymy, jak je ułatwić: stworzymy funkcję zwracającą koloryzator, czyli funkcję nadającą się do przekazania jako argument do color-state i save-color-map (dotąd używaliśmy w tym celu map).

Zaczniemy od napisania funkcji tłumaczącej trójkę liczb na HTML-owy zapis RGB, będzie nam bowiem łatwiej pracować z liczbami całkowitymi niż napisami:

(defn htmlize-color
  [[r g b]]
  (format "#%02x%02x%02x" r g b))

Wstawmy jeszcze wywołanie htmlize-color w odpowiednim miejscu w color-state:

(defn color-state
  [{:keys [tag attrs] :as element} colorize-fn]
  (let [state (:id attrs)]
    (if-let [color (colorize-fn state)]
      (assoc element :attrs (assoc attrs :style (str "fill:" (htmlize-color color))))
      element)))

Wyobraźmy sobie teraz, że mamy tabelkę z wartościami liczbowymi dla państw, np. taką:

Państwo	Wartość
Polska	20
Niemcy	15
Holandia	30

Chcemy mieć funkcję, która przypisze każdemu krajowi kolor tym intensywniejszy, im większa wartość, przy czym intensywność ma być proporcjonalna do wartości. Dla większej ogólności załóżmy, że mamy daną parę kolorów, c1 i c2, i dla każdej ze składowych R, G i B danemu państwu przypisujemy taką wartość tej składowej, jaka jest odległość rozważanej wartości od najmniejszej wartości w naszym zestawie danych (oczywiście znormalizowana biorąc pod uwagę długości odpowiednich przedziałów).

Brzmi to zagmatwanie, ale mam nadzieję, że na przykładzie będzie widać lepiej. Tak wygląda implementacja clojurowa powyższej funkcji:

(defn make-colorizer
  [dataset ranges]
  (let [minv (apply min (vals dataset))
        maxv (apply max (vals dataset))
        progress (map (fn [[min-col max-col]] (/ (- max-col min-col) (- maxv minv))) ranges)]
    (into {}
          (map (fn [[k v]] [(.toLowerCase k) (map (fn [progress [min-color _]] (int (+ min-color (* (- v minv) progress)))) progress ranges)])
               dataset))))

Zobaczmy, jak działa na naszych przykładowych danych:

> (make-colorizer {"pl" 20, "de" 15, "nl" 30} [[0 255] [0 0] [0 0]])
{"pl" (85 0 0), "de" (0 0 0), "nl" (255 0 0)}

Drugi argument oznacza, że składowa czerwona koloru ma się zmieniać od 0 do 255, a zielona i niebieska mają pozostać stałe (na poziomie 0).

Tak jak żądaliśmy, Niemcy wychodzą najciemniejsze (bo mają najmniejszą wartość), Holandia najjaśniejsza (bo ma największą wartość), a Polska jest w 1/3 jasności między Niemcami a Holandią (bo 20 jest w 1/3 drogi między 15 a 30).

Podsumowanie

Aplikację stworzoną w tym artykule można dalej rozwijać w wielu kierunkach. Można stworzyć jej wersję sieciową (jak się do tego zabrać -- opowiedziałem w skrócie na spotkaniu Warszawa JUG). Można pisać różne koloryzatory, np. dyskretny (stałe wartości dla różnych podprzedziałów wejściowego przedziału danych) albo „temperaturowy” (płynnie przechodzący od błękitu do czerwieni przez biel: trzeba w tym celu przejść przez przestrzeń kolorów HSV).

A jaki Wy macie pomysł na rozwinięcie przykładu? Zapraszam do komentowania i eksperymentowania! Dla tych, którym się nie chce przeklejać kodu do REPL, kompletne źródło działające z Leiningenem umieszczam na GitHub. Forki będą bardzo mile widziane.

Pierwsze użycie: protokoły i git-bisect

2011-01-13T00:00:00Z

Lubię rozwiązywać problemy przy użyciu narzędzi, których dotychczas nie znałem albo znałem tylko teoretycznie, na zasadzie „wiem, że istnieje coś takiego i do czego z grubsza służy”. Jeszcze przyjemniej jest, kiedy uzyskane rozwiązanie okazuje się czytelniejsze, zrozumialsze, szybsze albo pod innymi względami lepsze niż wersja używająca tylko dotychczasowego „arsenału”. W tych dniach zdarzyło mi się tego doświadczyć dwukrotnie, gdy pracowałem nad Fablo.

Fablo to napisany w Clojure silnik wyszukiwarki dla polskich sklepów internetowych: zna odmianę polskich wyrazów, obsługuje literówki i błędy ortograficzne. Radzi sobie też z wyrazami wpisanymi bez polskich znaków, a więc wie, że „papryka zolta” to to samo, co „papryka żółta”. Działa to na ogół zupełnie dobrze, ale wciąż ulepszamy wyszukiwarkę i eliminujemy błędy polegające na tym, że na jakieś zapytanie nie wyszukują się niektóre produkty, choć powinny. Tym razem błąd brzmiał: zapytanie „sledzie” zwraca inne wyniki niż „śledzie”.

Analiza problemu ujawniła, że algorytm odpowiedzialny za „polszczenie” zapytania powinien być stosowany szerzej. Mamy dwie implementacje pewnej struktury danych używanej w tym algorytmie: jedna z nich jest czysto funkcyjna i zbudowana z rdzennie clojurowego tworzywa – map i wektorów; druga zaś jest ukryta za fasadą używanej przez nas biblioteki Javowej o prostym interfejsie, a więc explicite do tej pory z niej nie korzystaliśmy. Algorytm polszczenia był uruchamiany tylko na pierwszej implementacji (co wystarczy w wielu przypadkach, ale nie zawsze), a powinien być na obu.

Koncepcyjnie te dwie implementacje są podobne, ale mają zupełnie różne API – zrazu wydawało mi się więc, że będę musiał pisać drugą wersję funkcji realizującej „polszczenie”. To jednak nie byłoby optymalne: duplikacja kodu oznacza dwa razy więcej okazji do popełnienia błędu i konieczność pamiętania o wprowadzeniu zmian każdorazowo w obu miejscach. Z pomocą przyszły protokoły – nowy element języka wprowadzony w Clojure 1.2.

Protokół jest czymś bardzo zbliżonym do znanego z Javy interfejsu: to zestaw deklaracji nazwanych funkcji i ich argumentów, jednak bez implementacji. Implementacje definiuje się dla konkretnych typów. Mogą to być zarówno typy definiowane w Clojure (przy użyciu konstrukcji deftype), jak i istniejące klasy Javowe. Można więc zadeklarować w protokole jakąś operację (nazwijmy ją blabalizacją), po czym zdefiniować, co oznacza blabalizowanie liczb, a co napisów. Efekt jest taki, jak gdybyśmy w Javie jakoś zmusili klasy java.lang.Integer i java.lang.String do implementowania interfejsu Blabalize; możemy wołać odpowiednią funkcję bezpośrednio na obiektach odpowiednich klas, bez żadnych wrapperów!

Zacząłem więc od zdefiniowania protokołu, opisującego dwie operacje, jakich można dokonywać na mojej strukturze danych. Potem przerobiłem implementację algorytmu „polszczącego” zapytania tak, aby korzystała tylko z tych dwóch operacji, co uniezależniło ją od implementacji „pod spodem”. Napisanie Clojurowej implementacji protokołu było proste; trudniejsze okazało się odpowiednie skorzystanie z biblioteki Javowej, ale i to udało się zrobić w miarę szybko.

Efekt: brak duplikacji kodu i tylko nieznacznie zmodyfikowana dotychczasowa wersja. A przy tym udało się nagiąć bibliotekę Javową do robienia rzeczy, do których nie była zaprojektowana, bez ingerencji w jej kod. Clojure nie przestaje mnie zadziwiać.

Innym razem zauważyłem, że od kilku commitów przy próbie uruchomienia testów jednostkowych i regresji w logach testowania pojawia się komunikat, którego zdecydowanie nie powinno tam być. Mógłbym zabrać się do tego testując okolice pojawienia się komunikatu w REPL, ale tym razem postanowiłem zrobić to inaczej. Ponieważ używamy Git do kontroli wersji, wykorzystałem narzędzie git-bisect, aby znaleźć commit wprowadzający komunikat. Potrzebuje ono do działania trzech rzeczy: identyfikatorów commitu „dobrego” i „złego” oraz skryptu, który odpowiada na pytanie, czy dany commit jest „dobry” czy „zły” (zwracającego kod wyjścia odpowiednio 0 albo 1). Skrypt wyglądał mniej więcej następująco:

cake clean
cake deps
cake proto
sleep 10
cake release
rm *.log
make test
if grep -q "PODEJRZANY_KOMUNIKAT" fablo*log; then
  exit 1
else
  exit 0
fi

(Cake jest narzędziem, którego używamy do budowania oprogramowania; 10-sekundowa przerwa między cake proto a cake release jest remedium na błąd w cake.)

Potem wystarczyło tylko:

$ git bisect start HEAD dobry_commit --
$ git bisect run check.sh

i już wiedziałem, w którym miejscu się zepsuło, a stąd było już niedaleko do znalezienia przyczyny problemu.

Zippery w Clojure

2010-11-25T00:00:00Z

Niniejszy artykuł jest pierwszym z dwuczęściowego minicyklu, stanowiącego demonstrację wykorzystania Clojure w praktyce do prostego, acz nietrywialnego zadania, na które natknąłem się w codziennej pracy. Dzisiejsza część może wydać się mało interesująca i mocno teoretyczna, ale mam nadzieję, że następny odcinek pokaże, jak można ją ciekawie wykorzystać (na razie nie zdradzę, jakie to wykorzystanie).

Planuję, że takie artykuły lub cykle zdominują Clojurową część tego bloga – będę się tu dzielił rozwiązaniami praktycznych problemów, na jakie natrafiam. Nie będzie tu artykułów w stylu „hej, jaki fajny nowy framework XYZ, napiszmy w nim Hello World przy wykorzystaniu technologii ABC!”, chyba że XYZ lub ABC będą przydatnymi narzędziami do rozwiązania problemu z życia wziętego. Bo takie rozwiązywanie w Clojure daje dużo radości: nie przypadkiem taki właśnie jest tytuł książki M. Fogusa i C. Housera.

A dziś opowiem o ciekawej strukturze danych, jaką są zippery. (Mierzi mnie trochę używanie angielskiej nazwy, ale nie potrafię wymyślić dobrego polskiego odpowiednika tego słowa; będę szczęśliwy widząc propozycje w komentarzach!) Cóż to takiego?

Zipper jest strukturą danych, dającą iluzję imperatywności przy manipulowaniu drzewami. Pamiętamy, że Clojurowe natywne struktury danych są niezmienne (immutable): jeśli mamy listę składającą się z liczb 2 i 5, to nie możemy jej w żaden sposób zmienić (np. dodać elementu) -- możemy co najwyżej stworzyć na jej podstawie nową listę, która będzie zawierać wszystkie elementy listy wyjściowej i jeszcze jakiś.

Niezmienność jest bardzo przydatna (o filozoficznych podstawach takiego podejścia, które zadecydowały o jego wykorzystaniu w Clojure, można poczytać w artykule „On State and Identity”), ale wymusza myślenie w innych kategoriach. To jest to, co czasami nazywa się „myśleniem funkcyjnym”: zamiast zastanawiać się, w jaki sposób zmienić wartość naszej zmiennej, aby doprowadzić ją do pożądanego stanu, pytamy o to, jak z jednych wartości robić inne. Przy tym nigdzie nie jest powiedziane, że taki sposób myślenia jest koniecznie lepszy od imperatywnego, do którego przyzwyczajeni są programiści języków takich jak Java. Jest po prostu inny. Warto się go nauczyć, bo okazuje się, że wiele problemów się upraszcza, gdy już umysł się przestawi na taki modus operandi. Bywa jednak i tak, że o danym problemie imperatywnie myśli się wygodniej niż funkcyjnie. Tu właśnie wkraczają zippery.

Wyobraźmy sobie, że chcemy dodać liczbę 4 do konkretnego drzewa BST, tak jak na rysunku powyżej. Załóżmy chwilowo, że nie interesuje nas ogólna funkcja dodająca do BST, a tylko chcemy wstawić czwórkę w konkretne miejsce. Jak to zrobić imperatywnie?

Zejdź dwa razy w dół w prawo („dobierz się” do węzła 6).
Wstaw czwórkę na lewo od bieżącego węzła.

I już. A teraz funkcyjnie – pamiętamy, że z drzewa robimy nowe drzewo:

Nowym drzewem jest drzewo, którego korzeniem jest korzeń drzewa wyjściowego, lewym poddrzewem – lewe poddrzewo drzewa wyjściowego, a prawym poddrzewem drzewo, którego korzeniem jest korzeń prawego poddrzewa drzewa wyjściowego, lewym poddrzewem – drzewo składające się z tylko jednego węzła 4, a prawym poddrzewem – prawe poddrzewo prawego poddrzewa drzewa wyjściowego.

Pierwsze podejście jest łatwiejsze, prawda? Zipper pozwala nam zachować je prawie niezmienione, nie rezygnując przy tym z zalet niezmienności. Oto jak można by opisać dodawanie do drzewa z zipperem:

Stwórz zipper na podstawie drzewa wyjściowego.
Wykonaj na tym zipperze operację „zejdź w dół”, otrzymując nowy zipper.
Wykonaj na tym zipperze operację „przejdź w prawo”, otrzymując nowy zipper.
Wykonaj na tym zipperze operację „zejdź w dół”, otrzymując nowy zipper.
Wykonaj na tym zipperze operację „wstaw 4 przed bieżącym elementem”, otrzymując nowy zipper.
Wykonaj na tym zipperze operację „daj drzewo wynikowe”, otrzymując pożądane drzewo.

Clojure zawiera implementację zipperów w bibliotece standardowej (w przestrzeni nazw clojure.zip). Oto jak można by zapisać powyższy przykład w Clojure:

(def nowe-drzewo
  (let [z1 (zip drzewo)
        z2 (down z1)
        z3 (right z2)
        z4 (down z3)
        z5 (insert-left z4 4)]
    (root z5)))

(tu explicite nazywam kolejne kroki obliczeń). Albo tak, używając makra ->:

(def nowe-drzewo
  (-> drzewo
      zip
      down
      right
      down
      (insert-left 4)
      root)))

Proste i wygodne. Pod spodem zipper to po prostu oryginalne drzewo plus informacja o tym, w którym miejscu drzewa w tej chwili jesteśmy, plus lista „zmian”, jakie do tej pory zostały na nim wykonane.

Rozwiązując mój problem (na razie nie zdradzam, jaki), natknąłem się na potrzebę posiadania funkcji, która działałaby jak map, ale na drzewach, a nie listach. To znaczy, przekształcałaby każdy element, niezależnie od tego, jak głęboko w drzewie siedzi, aplikując do niego jakąś funkcję, i zwracała w wyniku nowe drzewo. Co więcej, chciałem móc dodatkowo kontrolować, które węzły są zmieniane: funkcja ma dostawać dodatkowy predykat i tylko kiedy zwróci on true na wartości danego węzła, zmieniać tę wartość. Nie ma chyba takiej funkcji w standardowej bibliotece, ale dzięki zipperom można ją łatwo napisać.

Tak się szczęśliwie składa, że Clojurowe zippery mają funkcję next, która spaceruje po drzewie „w głąb”. Mając je, mogłem pomyśleć tak o swojej implementacji:

Jeśli zipper jest na końcu drzewa, to wynikiem transformacji jest wynikowe drzewo dla tego zippera, w przeciwnym razie wynikiem jest ta sama transformacja wywołana rekurencyjnie dla zippera uzyskanego przez wykonanie operacji „edit” (edycji bieżącego węzła w razie potrzeby) i „next”.

Tłumacząc to na Clojure, dostajemy:

(defn map-zipper [f pred z]
  (if (zip/end? z)
    (zip/root z)
    (recur f pred (-> z (zip/edit #(if (pred %) (f %) %)) zip/next)))))

I testujemy:

> (map-zipper inc integer?
              (zip/vector-zip [1 [2 [3 4]] [5] [6 [[7 8 9]]]]))
[2 [3 [4 5]] [6] [7 [[8 9 10]]]]

Trzeba podać predykat integer?, bo zipper działający na zagnieżdżonych wektorach działa na poszczególnych poddrzewach, a nie tylko na liściach (które tu są liczbami). Możemy łatwo zobaczyć, jakie poddrzewa odwiedza map-zipper:

> (map-zipper #(do (println %) %)
              (constantly true)
              (zip/vector-zip [1 [2 [3 4]] [5] [6 [[7 8 9]]]]))
[1 [2 [3 4]] [5] [6 [[7 8 9]]]]
1
[2 [3 4]]
2
[3 4]
3
4
[5]
5
[6 [[7 8 9]]]
6
[[7 8 9]]
[7 8 9]
7
8
9
[1 [2 [3 4]] [5] [6 [[7 8 9]]]]

Filmujmy błędy!

2010-11-19T00:00:00Z

Każdy programista (o ile jego oprogramowanie jest używane przez kogoś jeszcze poza nim samym) dostał kiedyś zgłoszenie błędu w programie. Wielu pracuje na co dzień z systemami śledzenia błędów, wielu zgłasza błędy w programach, których sami używają.

Dobre zgłoszenie powinno pomóc programiście odtworzyć błąd. Instrukcja odtworzenia jest bodaj najważniejszym z trzech nieodzownych elementów zgłoszenia. (Pozostałe dwa, jak pisze Joel Spolsky, to odpowiedzi na pytania: co powinno było się stać oraz co naprawdę się stało.) Na ogół w systemach śledzenia błędów opisujemy po prostu prozą kroki, które wykonaliśmy, a które doprowadziły do błędnej sytuacji.

Dokładne opisanie wykonanych czynności jest jednak trudne. Znaczenie może mieć każdy, nawet najmniejszy szczegół, łatwo więc o nieścisłość. Zamiast „otworzyłem plik” lepiej napisać „nacisnąłem Alt-O” albo „kliknąłem w menu Plik i kliknąłem polecenie Otwórz”, w zależności od tego, co naprawdę zrobiliśmy. W świetnym eseju Jak efektywnie zgłaszać błędy, z którego zaczerpnąłem ten przykład, Simon Tatham podaje inną, efektywniejszą metodę zgłaszania: należy posadzić programistę przed swoim komputerem i pokazać mu, w jaki sposób doprowadzamy do błędu.

Ta metoda jest dobra, kiedy da się zastosować. Problem pojawia się w przypadku, kiedy programista jest fizycznie na drugim końcu świata. Nie może wtedy zobaczyć monitora użytkownika i patrzeć mu na ręce... albo przynajmniej do niedawna nie mógł.

Od jakiegoś czasu w Fablo dołączamy do zgłoszeń błędów krótkie filmiki – screencasty z komentarzem głosowym. Z każdym kolejnym błędem rozwiązanym dzięki wskazaniu w taki sposób coraz bardziej przekonuję się do rozlicznych zalet tej metody. Przede wszystkim film jest dokładnym zapisem sesji. Widać wszystko, co się działo krok po kroku, i nie trzeba prosić o dodatkowe szczegóły, co zabiera czas i naprawiającego, i zgłaszającego. Film można odtwarzać wielokrotnie i dowolnie po nim nawigować, a nawet spowalniać; to nawet lepsze niż patrzenie na żywo na pracę użytkownika z programem. Jeśli mamy do czynienia z heisenbugiem („wywala się mniej więcej co pięć minut i w różnych sytuacjach, za cholerę nie mam pomysłu!”), możemy po prostu włączyć nagrywanie i zapomnieć o nim, pracując normalnie do momentu wystąpienia błędu. Film można wtedy obciąć do ostatnich dwóch-trzech minut i wysłać.

Co więcej, sporządzenie filmiku bardzo mało kosztuje. Na obie używane przez nas platformy dostępne są narzędzia pozwalające łatwo nagrać film. Dzięki Snapz Pro X na Mac OS X nagranie jest tak proste jak naciśnięcie Shift-Cmd-3 na początku i na końcu filmu; Record My Desktop na Linuksa i FreeBSD jest nieco trudniejszy w obsłudze, ale wciąż łatwy.

Wypadałoby wspomnieć o minusach filmów. Przychodzą mi do głowy dwa. Jednym jest fakt, że nie każdy błąd można zgłosić w ten sposób, a mówiąc ściślej: błąd w nie każdym oprogramowaniu. Gdy pracuje się z bibliotekami zamiast z okienkowym lub przeglądarkowym oprogramowaniem, wyłapywane błędy są innej natury i polegają na ogół na nieoczekiwanym zachowaniu konkretnej funkcji lub klasy. To, nolens volens, trzeba opisać.

Druga sprawa to ilość miejsca zajmowanego przez filmiki i czasu potrzebnego na ich wrzucenie do systemu kontroli błędów. To zapewne jeszcze do niedawna był powód, dla którego rzadko widzi się takie zgłoszenia np. w oprogramowaniu open source. Jednak problem ten staje się mało znaczący wraz z upowszechnieniem się szybkich łącz. Typowa wielkość naszego filmiku to ok. 1.5-2 MB; to naprawdę nie jest dużo, a FogBugz pozwala na bardzo łatwe – jednym przeciągnięciem myszy – dodanie screencastu do raportu błędu. Większe rzeczy z łatwością można udostępnić w Dropbox.

Filmujmy więc błędy!

Leniwa wersja makra ->

2010-11-11T00:00:00Z

Jacek Laskowski podaje ciekawy przykład wykorzystania monad w Clojure -- aplikowanie kolejnych funkcji do wyrażenia, dopóki ma ono wartość nie będącą nil. Przykład mi się podoba, bo jest prosty, ale nie trywialny – wykorzystuje monadę maybe do eleganckiego rozwiązania rzeczywistego problemu. Jest to w dodatku problem, z którym borykają się czasem programiści piszący w Javie, co widać choćby w tym wątku.

Nie mogę powiedzieć, że rozumiem monady. Owszem, znam definicję i potrafię napisać program w Haskellu wykorzystujący monadę IO, ale każdy monadyczny kod, jaki dotychczas widziałem, dawał się zapisać równie zwięźle bez użycia monad w językach, które mniej religijnie podchodzą do niewpływania funkcji na stan świata zewnętrznego. Tak jest również w tym przypadku.

Jacek tak postawił oryginalny problem:

Napisać metodę, która zwraca walutę, dla pracownika z danego departamentu międzynarodowej korporacji. Pracownik jest przypisany do departamentu (np. poprzez mapę – pracownik-departament), departament do kraju, a kraj do waluty. Funkcja na wejściu dostaje nazwę, identyfikator, lub cokolwiek jednoznacznie reprezentującego pracownika, a na wyjściu symbol waluty, np. dla „Jacek” powinno być „PLN”, a dla „John” „USD”, a „Tomek” i „Mateusz” dawaliby „CHF”.

Moje pierwotne rozwiązanie jest po prostu złożeniem trzech funkcji:

(defn pracownik->waluta [p]
  (-> p pracownik->departament departament->kraj kraj->waluta))

O ile wszystkie z nich są mapami (pamiętamy, że w Clojure mapy implementują interfejs IFn, można je więc uważać za funkcje i wołać jak funkcje), to dla żadnej wartości wejściowej nie zostanie rzucony NullPointerException, ponieważ wywołanie mapy dla nieistniejącego klucza zwraca nil.

Jacek słusznie zauważa jednak, że wykonujemy w ten sposób więcej pracy niż trzeba. Jeżeli już w mapie pracownik->departament nie ma departamentu dla danego pracownika, to otrzymany nil zostanie „przepchnięty” przez pozostałe dwie mapy, zanim będzie zwrócony. Można kontrargumentować, że taka implementacja pracownik->waluta jest bardzo czytelna i mała strata wydajności jest niewielką ceną do zapłacenia za tę czytelność. Co jednak, gdy nie możemy lub nie chcemy zgodzić się na taką stratę, a jednocześnie nie chcemy stracić czytelności?

Odpowiedzią jest makro, które nazwałem and->. Działa ono tak samo, jak ->, z tą różnicą, że kolejne wartości oblicza tylko jeśli po drodze nie pojawiło się false lub nil, podobnie jak and (stąd nazwa). Oto ono:

(defmacro and->
  ([x] x)
  ([x form] `(when-let [y# ~x] (~form y#)))
  ([x form & more] `(when-let [y# (and-> ~x ~form)]
                      (and-> y# ~@more))))

Implementacja jest bardzo zbliżona do zwykłego ->, którego kod w Clojure 1.2 wygląda tak. W stosunku do -> moje makro jest dla większej poglądowości trochę uproszczone i nie obsługuje konstrukcji typu (and-> mapa (get :klucz)), które normalnie rozwijane są do (get mapa :klucz).

Warto zwrócić uwagę na to, że argument makra nigdy nie jest wyliczany w jego rozwinięciu więcej niż raz; zawsze jest wiązany do lokalnego symbolu o unikatowej nazwie za pomocą when-let. Jest to jedna z reguł pozwalających unikać błędów w makrach. Szerszy opis tego problemu, występującego też w Common Lispie, można znaleźć w rozdziale 8 książki „Practical Common Lisp”.

Aktualizacja (7.12.2010)

Jak się okazuje, clojure-contrib zawiera już takie makro! Nazywa się -?> i można je znaleźć w przestrzeni nazw clojure.contrib.core. To już któryś raz, kiedy okazuje się, że jakieś użyteczne makro lub funkcja już jest w contrib i nie trzeba jej było pisać.