Chciałbym podkreślić i przyjrzeć się bliżej kilku kwestiom poruszonym przez Nicka Montforta, które są – jak sądzę – niezwykle ważne dla tych z nas, którzy zajmują się tworzeniem zjawisk literackich w medium cyfrowym.

Muszę przyznać, że współpracowałem z Nickiem Montfortem przy szeregu różnych projektów obejmujących kreatywne pisanie, przy czym niektóre polegały wyłącznie na dosłownym pisaniu razem i nie zawierały programowania w informatycznym tego słowa znaczeniu. Tu przejdę do konkretów.

Owe projekty pociągały za sobą niekiedy pewne procedury i ograniczenia. Kiedyś stworzyliśmy wspólnie powieść pod tytułem Implementation, która miała być wydana i rozprowadzana w formie 240 nalepek adresowych, które następnie powinny zostać umieszczone w różnych miejscach publicznych w realnym świecie i sfotografowane. Po kilku testach ustaliliśmy, że na takiej naklejce mieści się mniej więcej tyle tekstu, co na fiszce rozmiaru 3x5 cali. Uzgodniliśmy kilka wątków, szkice niektórych postaci i harmonogram, po czym zaczęliśmy pisać. Nakreślaliśmy fragment tekstu na fiszkach, po czym się nimi wymienialiśmy. Później dokonywaliśmy edycji i korekty, dodając coś lub wykreślając; następnie przepisywaliśmy poprawioną wersję na nową kartę lub w niektórych przypadkach po prostu przekreślaliśmy cały otrzymany tekst, wyjaśniając, dlaczego był według nas zupełnie niewłaściwy, durnowaty, patetyczny, niespójny, źle sformułowany, niepoetycki, głuchy na meandry języka, dogłębnie niestosowny lub bez żadnego związku z fabułą. Po czym oddawaliśmy kartę. Niektóre z nich przechodziły wielokrotnie w tę i z powrotem. Czasami spędzaliśmy wręcz absurdalną ilość czasu, spierając się o jakąś frazę czy nawet pojedyncze słowo. Ograniczona przestrzeń naklejki wymaga szczególnej oszczędności słów, a pisząc z przyjacielem, czasem trzeba ściągnąć mu cugle; tak samo zresztą jak sobie.

Było to pisanie z pewnymi ograniczeniami [constrained writing], poddane określonym procedurom i z pewnością zbiorowe; ale to jeszcze nie programowanie.

Być może warto rozważyć i przedstawić szerzej związek pomiędzy wspólnym ograniczonym pisaniem a kolektywnym programowaniem.

Kolejnym, mniej bezpośrednim przykładem jest projekt Nicka o nazwie Wąwóz Taroko. Był to generator poezji napisany w JavaScript, stosunkowo prosty i względnie przejrzysty program, który po odpaleniu w przeglądarce produkował poemat o głównej atrakcji parku narodowego na Tajwanie, a mianowicie wąwozie z licznymi wodospadami w otoczeniu dziewiczej natury. W trakcie generowania kolejnych wersów czytelnik może pomyśleć, że to zwykły wiersz o linearnej strukturze, który pozachwyca się chwilę tym cudem świata, po czym w miarę sensownie się zakończy. Niektóre frazy powtarzają się jednak w nowych konfiguracjach, stworzonych ze słów i zwrotów, które pojawiły się już wcześniej – i wtedy nadchodzi moment objawienia. W pewnym momencie uświadamiamy sobie, że nie jest to zwykły, animowany wiersz o pięknie natury, lecz wytwór generatora poezji, kombinatoryczny schemat, tworzący za każdym razem nową wersję wiersza, która będzie płynąć w nieskończoność i zalewać ekran słowami, póki nie wyłączymy okna przeglądarki i nie wyrzucimy go raz na zawsze ze swojego życia.

Kiedy pierwszy raz zobaczyłem Wąwóz Taroko, byłem zachwycony owym „momentem objawienia” i niewyczerpalną energią tego małego poetyckiego programu. Doceniłem także pewną ironię tej inwersji – to, co wydawało się refleksyjnym poematem o naturze, było w istocie wytworem programu komputerowego, algorytmicznym cybertekstem. Niemniej jednak nigdy nie byłem miłośnikiem poezji o naturze, a prawie zawsze mam ochotę wkroczyć do akcji i nieco ulepszyć dzieła Nicka. Otwierając program w przeglądarce, jednym prostym kliknięciem w „pokaż źródło strony” zdobyłem dostęp do tekstonów Wąwozu Taroko, mogłem zatem zbadać strukturę programu oraz jego zmienne. Bez pytania Nicka o zgodę – w zasadzie to wcale go nie informując – zabrałem się do przerabiania aplikacji, zastępując najpierw jego słownik – dość ograniczony w moim mniemaniu – innym, znacznie bardziej rozbudowanym. Byłem ciekaw, czy uda mi się tak przekształcić podstawową strukturę tekstu, żeby zupełnie odwrócić jego znaczenie i zmienić minimalistyczny wiersz o harmonijnej naturze, gdzie człowiek jest dosłownie nieobecny, w rozbuchany poemat o chaotycznym mieście z ludźmi kłębiącymi się na każdym kroku bez ładu i składu. Chciałem pokierować refleksyjny, nieco podniosły ton Nicka w stronę komizmu i absurdu. Tak oto w ciągu jednej nocy Wąwóz Taroko przekształcił się w Garaż w Tokyo (Tokyo Garage). Pozmieniałem wszystkie zmienne, nadając wierszowi zupełnie inny ton, zmodyfikowałem nieco parametry programu odpowiadające za kolorystykę i szybkość odtwarzania, przekreśliłem podpis Nicka i wstawiłem powyżej własny, następnie wrzuciłem całość na swoją stronę. Wreszcie wysłałem Nickowi link do nowej wersji generatora i przez następnych kilka godzin czekałem na jego reakcję zza oceanu.

Ta ostatnia część jest szczególnie ważna. W czasie, gdy przerabiałem wiersz Nicka, miałem oczywiście świadomość, że przynajmniej jedna osoba na świecie ubawi się i doceni sam akt nadpisywania, hakowania, remiksu. Miałem na uwadze potencjalnego odbiorcę; a tym odbiorcą był Nick.

W skrócie: był to prywatny, choć niezbyt hermetyczny żart, zaistniały w przestrzeni publicznej, lecz stworzony w celu rozbawienia konkretnej osoby. Raczej żaden z nas nie zdawał sobie sprawy, co stanie się z programem w ciągu następnych miesięcy czy nawet lat. Kilka miesięcy po Garażu w Tokyo J.R. Carpenter, zaprzyjaźniona autorka literatury elektronicznej, stworzyła własną iterację o wymownym tytule Gorge – w tym przypadku program generował poemat opisujący z obsesyjnymi detalami proces konsumpcji i kolejnych etapów trawienia w ludzkim organizmie. J.R. Carpenter popełniła jeszcze kilka remiksów, do których wkrótce dołączył Toy Garbage Talana Memmotta, Yoko Engorged Erica Snodgrassa, Takei, Gorge Marka Samplesa, Alone, Engaged Marii Engberg, Fred & George Flourish Klink, Argot,Ogre,OK! Andrewa Plotkina i wiele innych. Obecnie trudno znaleźć osobę, która działając w środowisku e-literatów, nie przerobiła Wąwozu Taroko; a każda z tych przeróbek jest godna uwagi. Bez szczególnej wiedzy informatycznej oraz wielkiego wysiłku, każdy jest w stanie dokopać się do kodu źródłowego i tak pozmieniać parametry, by wygenerować wiersz o zupełnie innej tematyce i języku, co poprzedni. Ten niewielki i zrobiony po łebkach program stał się nowym gatunkiem poezji.

Odbiegłem tu chyba nieco od postulatów wysuniętych przez Nicka, aczkolwiek mam nadzieję, że powyższe przykłady obrazują nieco jego ideę programowania (czy też szerzej: kolektywnego twórczego pisania w środowisku sieciowym), które może być rozumiane jako zbiorowy akt twórczej zabawy.

Montfort streszcza najważniejsze tezy w czterech punktach. Rozważmy ich potencjalne znaczenie; tak jak rozważaliśmy możliwości zakodowane w systemie generatora poezji. W tym miejscu chciałbym również zadać kilka pytań, które mogłyby stać się punktem wyjścia do dyskusji z Nickiem.

• Programowanie to działalność o charakterze zarówno społecznym, jak i kulturowym. Prawdopodobnie. Być może jednak warto zastanowić się nad sytuacją odwrotną. Czy programowanie może być też czasem czynnością antyspołeczną i antykulturową?

• Programowanie polega na głębokim zaangażowaniu w używanie komputera, które jak żaden inny rodzaj aktywności pozwala wykorzystać możliwości tego urządzenia w twórczym celu. Pytaniem często stawianym przez badaczy i krytyków e-literatury jest: jak bardzo w programowanie powinni być zaangażowani sami krytycy? Czy krytyk musi umieć odczytać kod źródłowy generatora poezji, by wyrazić o nim opinię?

Idąc dalej – kilka lat temu Michael Mateas sformułował słynną już tezę, a mianowicie: „pisarze muszą być programistami”. Czyli: ci, którzy chcą się zajmować tworzeniem prozy lub poezji dla mediów cyfrowych, muszą najpierw sprawdzić własne umiejętności w zakresie programowania. Czy jest to w jakimś stopniu potrzebne i prawdziwe? Zawsze chciałem odpowiedzieć: „Pewnie… a programiści muszą być pisarzami”. Zaniedbywanie narzędzi poetyki i struktury opowieści albo ignorowanie rytmu, tonacji, dykcji, języka poezji może być w równym stopniu destrukcyjne dla e-literatury. Jak możemy na przykład pogodzić potrzebę wiedzy informatycznej i samo rzemiosło literackie w programach do kreatywnego pisania stworzonych dla mediów cyfrowych?

• Społeczności programistów pozostają związane z platformami obliczeniowymi, uznaną działalnością artystyczną i medialną, a także ze społecznościami, których zainteresowania wykraczają poza samo programowanie. Jakkolwiek zgadzam się z tym w stu procentach, zastanawiam się, czy owe związki są faktycznie w pełni zrozumiałe, a także – w jaki sposób można usprawnić komunikację pomiędzy np. środowiskami artystycznymi, które łączą strukturalne i kulturalne podobieństwa ze środowiskiem programistów? W jaki sposób mogą nawzajem się wspierać?

• Programowanie nie jest czynnością zarezerwowaną jedynie dla profesjonalistów, którzy odbyli wieloletnie szkolenia. Na podstawowym poziomie mogą się tym zajmować (i zajmowali się już nie raz) zwykli użytkownicy komputerów po kilku godzinach przygotowań.

Ten punkt, moim zdaniem, jest niezwykle ważny i w pełni się z nim zgadzam; choć oczywiście istnieją różne poziomy zaawansowania, jeśli chodzi o hakerskie umiejętności. Ja na przykład nie jestem specem od JavaScript, Ruby czy nawet Processing i muszę w pewnym stopniu uczyć się ich na nowo za każdym razem, gdy tworzę coś, co wymaga użycia języków programowania. To wprawdzie jest łatwe, ale nie aż tak.

Co możemy zrobić, Nick, by otworzyć tym nieprogramującym drogę do programowania? W jaki sposób jesteśmy w stanie, jako specjaliści, ułatwić im naukę, uczynić ją bardziej powtarzalną, wciągającą i zabawną?