Literatura jako kod – teksty pisane dla maszyny i przez maszynę

How do I wri­te? Not with paper or pen, But with the lan­gu­age of the digi­tal air[1] – czy­ta­my w wier­szu „Arti­fi­cial Poetry”, któ­re­go autor­stwo moż­na przy­pi­sać mode­lo­wi GPT‑3.5 code-davin­ci-002 prze­szko­lo­ne­mu do wyra­ża­nia się w spo­sób nie­odróż­nial­ny od ludz­kie­go. Aż do wkro­cze­nia w pole lite­ra­tu­ry gene­ra­tyw­nej sztucz­nej inte­li­gen­cji twór­czość powsta­ła przy udzia­le sys­te­mów obli­cze­nio­wych koja­rzy­ła się głów­nie z mało­ska­lo­wy­mi, zazwy­czaj inte­rak­tyw­ny­mi gene­ra­to­ra­mi tek­sto­wy­mi (pisa­ny­mi np. przez takich arty­stów jak Nick Mont­fort czy Leszek Onak), któ­re nie mia­ły na celu „symu­lo­wa­nia cze­go­kol­wiek i kogo­kol­wiek, lecz nie­ustan­ne odświe­ża­nie funk­cji poetyc­kiej w obrę­bie ogra­ni­czo­nych, czy­li tek­sto­wo bądź syn­tak­tycz­nie zde­ter­mi­no­wa­nych, zaso­bów tekstowych”[2]. W prze­ci­wień­stwie do obszer­nych utwo­rów hiper­tek­sto­wych cha­rak­te­ry­stycz­nych dla pierw­szej gene­ra­cji lite­ra­tu­ry elek­tro­nicz­nej, w lite­ra­tu­rze pro­gra­mo­wa­nej (com­pu­ta­tio­nal lite­ra­tu­re) wła­ści­wej dru­giej gene­ra­cji nie tyl­ko liczy­ło się pozna­nie efek­tu koń­co­we­go (out­put), ale też zna­jo­mość zasad dzia­ła­nia algo­ryt­mu i umie­jęt­ność ana­li­zy dostar­cza­nych danych wej­ścio­wych (input)[3] ini­cju­ją­cych dzia­ła­nie kodu.

Arty­ści-pro­gra­mi­ści odpo­wie­dzial­ni za wcze­sne gene­ra­to­ry tek­stu świa­do­mie wybie­ra­li inną dro­gę, bliż­szą awan­gar­do­wej tra­dy­cji lite­ra­tu­ry eks­pe­ry­men­tal­nej w duchu OULIPO i ALAMO. W eks­plo­ro­wa­niu lite­rac­kich pre­ce­den­sów nie wyka­zy­wa­li zain­te­re­so­wa­nia „ludz­ko brzmią­cym” języ­kiem. W „dzie­cin­nie pro­stym” algo­ryt­mie Love Let­ters Chri­sto­phe­ra Stra­cheya (1953) to, co może wyglą­dać jak paro­dia seman­tycz­nie pustych wzor­ców miło­snych wyznać, jest zbio­rem goto­wych figur, któ­re brzmią aż nazbyt popraw­nie, nie­mal kary­ka­tu­ral­nie reali­zu­jąc ocze­ki­wa­nia gatun­ku. Podob­nie w Sto­cha­stic Texts Theo Lut­za (1959) język został odar­ty z inten­cji komu­ni­ka­cyj­nej, a w mecha­nicz­nych zda­niach zbu­do­wa­nych z wydo­by­tej z Zam­ku Fran­za Kaf­ki lek­sy­ki arbi­tral­ność ope­ra­cji logicz­nej prze­nie­sio­na na poziom tre­ści prze­sta­je być gwa­ran­tem sensu[4]. Musi­my też pamię­tać, że w obrę­bie infra­struk­tu­ry sie­cio­wej znacz­na część języ­ka nie musi upo­dab­niać się do „ludz­kich” spo­so­bów komu­ni­ka­cji, ponie­waż funk­cjo­nu­je jako tekst prze­zna­czo­ny przede wszyst­kim do odczy­tu przez maszy­nę. War­stwa ta nie tyle zna­czy, ile wyko­nu­je pew­ną pra­cę: uru­cha­mia pro­ce­du­ry, porząd­ku­je obieg infor­ma­cji i współ­de­cy­du­je o widzial­no­ści tre­ści. Ten ope­ra­cyj­ny spo­sób pisa­nia obej­mu­je mię­dzy inny­mi meta­da­ne, znacz­ni­ki struk­tu­ral­ne oraz instruk­cje indek­so­wa­nia takie jak dyrek­ty­wy robots.txt, noin­dex.

W swo­jej prak­ty­ce teo­re­tycz­no-arty­stycz­nej Nick Mont­fort, śle­dząc pro­ce­sy powo­du­ją­ce, że świat został zdo­mi­no­wa­ny przez umo­co­wy­wa­ne w glo­so­la­lii duże mode­le języ­ko­we, kon­se­kwent­nie opo­wia­da się za pisa­niem przej­rzy­stych pro­gra­mów, któ­rych dzia­ła­nia moż­na w cało­ści prze­śle­dzić i zro­zu­mieć, udo­stęp­nio­nych na zasa­dzie open sour­ce[5]. Dzię­ki otwar­to­ści kodu źró­dło­we­go i repo­zy­to­riom w rodza­ju GitHu­ba kod może być dalej bada­ny w kole­żeń­skich warun­kach i kolek­tyw­nie prze­pi­sy­wa­ny przez inne oso­by prak­ty­ku­ją­ce. Korzy­sta­nie z goto­wych narzę­dzi, tak samo jak świa­do­me eks­po­no­wa­nie ich nie­do­sko­na­ło­ści oraz pro­ce­du­ral­ne­go cha­rak­te­ru, stoi w kontrze do nie­tran­spa­rent­nych, narzu­ca­nych przez kor­po­ra­cyj­nych gigan­tów mode­li bazu­ją­cych na ogrom­nych zaso­bach danych.

Dla Mont­for­ta klu­czo­we zna­cze­nie ma fakt, że opro­gra­mo­wa­nie nie jest narzę­dziem asy­stenc­kim wspie­ra­ją­cym auto­ra, lecz peł­ni rolę auto­no­micz­ne­go wyko­naw­cy aktu wytwór­cze­go. Uzy­ska­ny efekt sytu­uje się na sty­ku pro­gra­mi­stycz­nej inten­cji i wymy­ka­ją­cym się jej kon­tro­li pro­ce­som obli­cze­nio­wym maszy­ny. Mar­cin Skła­da­nek pod­kre­śla, że pod­sta­wo­wym wymia­rem kodu jest jego zorien­to­wa­nie na dzia­ła­nie, gdyż – jak pod­kre­śla – „kod […] sta­no­wi nota­cję pro­ce­du­ry dzia­ła­nia, w ramach któ­rej spa­ra­me­try­zo­wa­ne zmien­ne, meto­dy, funk­cje, obiek­ty zysku­ją zde­fi­nio­wa­ne przez pro­gra­mi­stę zna­cze­nia, któ­re inter­pre­to­wa­ne są przez nie­go same­go oraz przez maszy­nę (rzecz jasna w odmien­ny sposób)”[6].

Być może dzi­siaj for­mu­ła poetyc­kie­go gene­ra­to­ra opar­te­go o small data nie robi takie­go wra­że­nia co w cza­sach naj­więk­szej świet­no­ści e‑literatury, ale nadal pozwa­la usta­wić umow­ne róż­ni­ce mię­dzy dzie­ła­mi kom­pu­te­ro­wo wyge­ne­ro­wa­ny­mi (com­pu­ter-gene­ra­ted) a wspo­ma­ga­ny­mi (com­pu­ter-assi­sted), jak rów­nież poka­zać pew­ną nie­ade­kwat­ność tych­że roz­gra­ni­czeń.

Out­put wyła­nia się w odpo­wie­dzi na okre­ślo­ne uwa­run­ko­wa­nia. Gene­ra­tor moż­na postrze­gać jako samo­wy­star­czal­ny pro­gram napi­sa­ny tak, aby tech­nicz­ne pro­ce­du­ry odpo­wie­dzial­ne za jego out­put były moż­li­wie w cało­ści zawar­te w kodzie. Kie­dy zaś posłu­ży jako „pro­te­za wyobraź­ni”, w prak­ty­ce autor sta­je się dostar­czy­cie­lem danych wej­ścio­wych (spe­cja­li­stycz­nych słow­ni­ków, nie­ty­po­wych fraz, wstęp­nych tema­tów do opra­co­wa­nia, pró­bek cudzych sty­lów czy wła­snych nota­tek), po czym pozwa­la pro­gra­mo­wi „pisać” na tej pod­sta­wie, trak­tu­jąc ów pro­ces jako meto­dę wydo­by­wa­nia nie­ocze­ki­wa­nych zesta­wień i impul­sów do dal­szej pra­cy.

Pro­ce­du­ral­ne gry języ­ko­we sta­ra­ły się oswa­jać z nie­po­żą­da­ny­mi efek­ta­mi i uwraż­li­wiać na uster­ki, zakłó­ce­nia, awa­rie, przy­po­mi­na­jąc o tym, że język zawsze dzia­ła w ramach pew­nych pro­to­ko­łów, reguł i ogra­ni­czeń, nawet jeśli w codzien­nym użyt­ku pozo­sta­ją one nie­uświa­do­mio­ne. Odno­sząc się do pio­nier­skich cyber­tek­stów, Mariusz Pisar­ski zauwa­żył, że „w tych wła­śnie momen­tach, kie­dy cyber­ne­tycz­na lite­ra­tu­ra – z punk­tu widze­nia zało­żeń ludz­kie­go kon­struk­to­ra – prze­sta­je »dzia­łać« i zaczy­na zwra­cać uwa­gę na swo­ją mecha­nicz­ną struk­tu­rę, docho­dzi do jej wyzwo­le­nia się z narzu­co­nych jej przez czło­wie­ka kry­te­riów literackości”[7]. Pod­czas korzy­sta­nia z dzi­siej­szych chat­bo­tów, zamiast ule­gać efek­to­wi ELIZY (powścią­gnąć poku­sę auto­ma­tycz­ne­go dopi­sy­wa­nia maszy­nie inten­cji, empa­tii bądź rozu­mie­nia), war­to doce­nić ich podat­ność na halu­cy­na­cje oraz wszel­kie momen­ty, kie­dy sys­te­my funk­cjo­nu­ją­ce dzię­ki eks­trak­cji wie­dzy i nakar­mio­ne miliar­da­mi stron tek­stów napi­sa­nych przez ludzi seman­tycz­nie się wyko­le­ja­ją, zamiast „wyplu­wać” kon­tek­sto­wo ade­kwat­ne kon­fi­gu­ra­cje słów.

Dla poety-pro­gra­mi­sty Joh­na Cay­leya „kod nie jest tek­stem” w sen­sie lite­rac­kim, sta­je się nim tyl­ko wte­dy, gdy nie peł­ni funk­cji ope­ra­cyj­nej. Jego zda­niem aby kod mógł funk­cjo­no­wać jako gene­ra­tor, musi sta­no­wić odręb­ną część glo­bal­ne­go sys­te­mu tek­sto­we­go. Kod posia­da wła­sne struk­tu­ry i skład­nie, nie jest z koniecz­no­ści przej­rzy­sty w języ­ku czy­tel­nym dla czło­wie­ka. W takim uję­ciu kry­ty­cy, któ­rzy oma­wia­ją powierzch­nio­we repre­zen­ta­cje sym­bo­li „kodu-jako-tek­stu”, czy­nią to bez inter­pre­to­wa­nia kodu jako wyko­nal­nych instruk­cji czy pro­ce­sów leżą­cych u jego podstaw[8]. W pole­mi­ce z Cay­ley­em Rita Raley[9] przy­rów­ny­wa­ła ten spo­sób fawo­ry­zo­wa­nia kodu nad out­pu­tem do twier­dze­nia The­odo­ra Ador­na, że „par­ty­tu­ry są nie tyl­ko nie­mal zawsze lep­sze niż reali­za­cje, ale są tak­że czymś wię­cej niż tyl­ko wska­zów­ka­mi; wię­cej: samą rzeczą”[10].

Ten typ namy­słu nad przej­rzy­sto­ścią kodu co rusz roz­bi­ja się o pyta­nie, co zro­bić z inter­pre­ta­cją dzie­ła, kie­dy kom­pe­ten­cjom lite­ra­tu­ro­znaw­czym towa­rzy­szy brak zna­jo­mo­ści języ­ków pro­gra­mo­wa­nia. W prak­ty­ce her­me­neu­tycz­nej istot­ne jest prze­cież to, żeby dotrzeć do sen­su tek­stu poprzez zor­ga­ni­zo­wa­nie sobie odpo­wied­nich narzę­dzi lek­tu­ro­wych. „Czy­tel­ni­kiem” kodu pro­jek­to­wa­ne­go z myślą o wyko­na­niu pew­nej pro­ce­du­ry jest przede wszyst­kim maszy­na. Języ­ki kom­pi­lo­wa­ne jesz­cze przed uru­cho­mie­niem wyma­ga­ją prze­kształ­ce­nia kodu źró­dło­we­go do posta­ci pli­ku wyko­nal­ne­go, nato­miast w języ­kach inter­pre­to­wa­nych kod jest wyko­ny­wa­ny na bie­żą­co, linij­ka po linij­ce, za pomo­cą inter­pre­te­ra. Pro­gra­mi­sta może bez­po­śred­nio wypro­wa­dzić z pod­da­wa­ne­go testom kodu uży­tecz­ne i czy­sto prag­ma­tycz­ne kon­klu­zje, nato­miast kie­dy uwzględ­ni­my inne try­by lek­tu­ro­we – takie, któ­re nie spro­wa­dza­ją się do bez­myśl­ne­go „grze­ba­nia w bebe­chach” – z kodem jako szcze­gól­nym typem języ­ka pośred­nio sty­ka­my się, gdy już natra­fia­my na inną jego postać: wynik wyko­na­nia (exe­cu­tion result) pro­gra­mu.

Musi­my zatem zadać sobie pyta­nie o to, co zysku­je­my i co tra­ci­my, gdy poru­sza­my się pomię­dzy dwo­ma nie­toż­sa­my­mi obsza­ra­mi, mię­dzy tek­stem „wyko­ny­wal­nym” (tym, czym kod jest) a tek­stem, do któ­re­go czy­tel­nik może dotrzeć za pomo­cą tra­dy­cyj­nych pro­ce­dur her­me­neu­tycz­nych (tym, co kod czy­ni, ale też wszyst­kim, co widzial­ne na wierz­chu, a więc rów­nież do para­tek­sto­wej war­stwy inter­fej­su). Żeby jed­nak nie prze­śle­pić przy­pad­ków zawod­no­ści pro­gra­mu, łatwiej będzie – za Mar­kiem C. Mari­no – spoj­rzeć na kod jak na sys­tem zna­ków posia­da­ją­cy zna­cze­nie wykra­cza­ją­ce dale­ko poza jego funk­cjo­nal­ną użyteczność[11]. Ale co jeśli w per­spek­ty­wie tek­sto­cen­trycz­ne­go namy­słu nad lite­ra­tu­rą kod jest Barthes’owskim nie­skrę­po­wa­nym przez żad­ne wzglę­dy repre­zen­ta­cyj­ne tek­stem pisal­nym, któ­re­go isto­tą jest to, że „być może nie da się [o nim] nic powiedzieć”[12]?

Prze­świad­cze­nie, że tekst potrze­bu­je swo­je­go inter­fej­su, któ­ry warun­ku­je akt lek­tu­ro­wy, już daw­no temu wyzna­cza­ło rede­fi­ni­cyj­ne ramy. Kart­ka prze­wra­ca­na w wydru­ko­wa­nej papie­ro­wej książ­ce wyda­je się na tyle oswo­jo­na, że jako inter­fejs sta­je się czymś prze­zro­czy­stym. Ina­czej jest przy­kła­do­wo w przy­pad­ku lite­ra­tu­ry wyko­rzy­stu­ją­cej tech­no­lo­gię roz­sze­rzo­nej rze­czy­wi­sto­ści (AR), któ­ra anga­żu­je mate­rial­ność książ­ki i spra­wia, że gdzieś „pomię­dzy” zaist­nieć może akt komu­ni­ka­cji lite­rac­kiej.

Nale­ży pamię­tać, że inter­fejs nie jest neu­tral­nym pośred­ni­kiem, gdyż nie tyl­ko ukry­wa przed nami zło­żo­ność pro­ce­sów obli­cze­nio­wych, ale masku­je też ide­olo­gicz­ne czyn­ni­ki, któ­re unie­moż­li­wia­ją zba­da­nie funk­cjo­no­wa­nia ide­olo­gii jako takiej. Zda­niem Ale­xan­dra Gal­lo­waya archi­tek­tu­ra czar­nych skrzy­nek sygna­li­zu­je kry­zys czy­tel­no­ści albo rekon­fi­gu­ra­cję tego, co zna­czy czy­tać i pisać. Nale­ży więc wypra­co­wać nowy model czy­ta­nia, któ­ry będzie opie­rać się na imma­nent­nej lub maszy­no­wej kon­cep­cji opro­gra­mo­wa­nia i zada­wać pyta­nia nie tyl­ko o logos (dys­kurs), ale i ergon (pra­cę). Meto­da ta nie ma cha­rak­te­ru wyłącz­nie her­me­neu­tycz­ne­go, ale rów­nież doty­czy danych i ich par­so­wa­nia, ska­no­wa­nia, prze­or­ga­ni­zo­wa­nia, fil­tro­wa­nia i interpolacji[13]. Lite­ra­tu­ra jako kod dopusz­cza moż­li­wość lek­tu­ry jako zda­rze­nia – taką sytu­ację, w któ­rej sens nie zosta­je cał­ko­wi­cie wyczer­pa­ny przez funk­cję, jaką tekst ma do speł­nie­nia na dro­dze jed­no­ra­zo­we­go aktu inter­pre­ta­cji. Dopó­ki taki kod może jesz­cze „dry­fo­wać” – gene­ro­wać nad­miar, któ­re­go nie da się jed­no­znacz­nie skla­sy­fi­ko­wać ani wyko­rzy­stać przez tech­no­lo­gicz­ny instru­ment racjo­na­li­za­cji – pozo­sta­je on po stro­nie lite­ra­tu­ry. Gra­ni­ca prze­bie­ga wte­dy, gdy błąd, inde­ter­mi­na­cja, loso­wość czy nie­prze­kła­dal­ność zosta­ją ujarz­mio­ne przez logi­kę kom­pu­ta­cji i reżim wydaj­no­ści.