poem = new form(poem);
Før hadde dikt form, rytme og rim. Så kom frie vers. De som lengter tilbake, har fått en ny medhjelper i sin lengsel etter formtvang: kompilatoren. Derimot har de som vil forbli frigjorte fra stivnede former en alliert i grensesnittet, datamaskinens mediale og variable overflate.

Av Tore Ferner/Kunstnett Norge

Man har laget maskiner som genererer setninger og «romaner». Om de ikke er meningsløse er de gjerne håpløst kjedelige. Akkurat som matematikk og teorier kan være vakre som musikk, kan data-algoritmer også være vakre eller skjønne.[1] Og det fins dikt om matematikk og data. Men hva med å skrive programkode som i seg selv er dikt? Hvordan blir det?

Sharon Hopkins har gjort akkurat det og har formulert et kriterium for et «godt» programkodedikt ved å sammenligne med «vanlig» diktning. La oss glemme frie vers for et øyeblikk. Hun mener at et vanlig dikt gleder oss ved at vi overraskes av eller beundrer hva som faktisk kan uttrykkes med de begrensningene som rytme og rim pålegger dikteren.[2] Tilsvarende gleder et programkodedikt ved at man beundrer hva som faktisk lar seg uttrykke, selv når alle ordene tilfredsstiller et programmeringsspråk alle syntaktiske regler.

Dikt uten feil
En annen måte å si det samme på, er at kildekoden lar seg kompilere uten feilmeldinger. Å kompilere programkode betyr at en tekst som inneholder verbale instruksjoner, som er tilstrekkelig lik vanlige språklige uttrykk til at vi mennesker lett forstår det, oversettes til en binær representasjon av disse instruksjonene som datamaskinen kan utføre. Etter Hopkins kriterium må et programkodedikt i det minste kompilere uten noen feilmelding. Hvor godt diktet er, er i neste omgang avhengig av hva som lar seg uttrykke med eller til tross for en slik formal begrensning. Programvarediktet blir enda bedre dersom det i tillegg genererer en output som kompletterer dets innhold. Det siste er som regel svært vanskelig å få til uten at diktet blir svært stygt.

Programmeringsspråket Perl er svært velegnet til programkodedikt fordi man ikke behøver å definere alle elementer i et program før man bruker dem. Perl er designet slik at det skal være mulig å skrive programkode som til en viss grad mimer vanlig engelsk. Rekkefølgen på ulike elementer kan ofte byttes om. Dessuten har komma og punktum kontekstavhengige funksjoner i Perl som er kjekke for en kodedikter. I programkodedikt benyttes for eksempel at komma ofte tar og «kaster bort» argumentet til venstre for seg. En anonym student har skrevet følgende programkodedikt:[3]


   study, write, study,
   do review (each word) if $time.
   close book. sleep? what's that? 


Dette er neppe det mest sublime eller spreke diktet du har lest, men det kompilerer uten feilmelding. Ordene do, each, if close og sleep har spesielle betydninger i Perl. Det samme har som sagt komma- og punktum-tegnene. Det har også tegnene ? og $. Dessuten har konstruksjonen med do ... (each ...) en spesiell funksjon som forøvrig stemmer godt overens med betydningen man ville tillegge uttrykket «do review each word» ifølge vanlig engelsk.

Og nå litt erotikk:


   sleep, close together,
   sort of sin each spring & wait; 
   50% die


Opphav er ukjent. Begge diktene følger - stort sett - reglene til de japanske haiku-diktene. De består av tre linjer som har 5, 7 og 5 stavelser. En haiku skal beskrive noe ved naturen som indikerer en av årstidene og skal frembringe en følelsesmessig reaksjon. Målet var å uttrykke eller å antyde mye med så få ord som mulig.

Her kommer et noe lengre dikt av Hopkins fra (1995), som også har stått i Guardian og Economist:[4]


   APPEAL:

   listen(please, please);

       open yourself, wide;
            join(you, me);
       connect(us, together),

   tell me.

   do something if distressed;

            @dawn, dance;
            @evening, sing;
            read (books, $poems, stories) until peaceful;
            study if able;

            write me if-you-please;

   sort your feelings, reset goals, seek (friends, family, anyone); 

            do*not*die (like this)
            if sin abounds;

   keys (hidden), open(locks, doors), tell secrets;
       do not, I-beg-you, close them, yet.

                   accept(yourself, changes),
                   bind(grief,despair);

       require truth, goodness if-you-will, each moment;

   select(always), length(of-days)


Som man ser, preges slike Perl-dikt mer av imperativer enn av stemningsskildringer, kontemplasjon eller hva man som dikter nå ellers kunne tenke seg å oppnå. Grunnen til det er at programmeringsspråk til stor del består av instruksjoner.

Skal man klare å sette pris på slike dikt, må man nok kjenne til en del detaljer ved et spesielt programmeringsspråk, i dette tilfellet Perl, slik som at for eksempel select, length og keys har spesielle betydninger og hvilke restriksjoner de forøvrig legger på syntaksen. Ordenes betydning (eller funksjon) i programmeringsspråket står ofte i en pussig kontrast til det de uttrykker når de betraktes som en del av diktet. Et slikt dikt leker med en flertydighet som hefter ved ethvert ekspertspråk eller enhver sosiolekt som har et vokabular som overlapper det normale språket.

Man kan si at Hopkins syn på programkodedikt er heterogent i den forstand at målet er å lage et innhold i diktet som er så fremmed som mulig i forhold til det medium man dikter i: koden eller kodingen.

Rene dikt
Florian Cramers syn på programkodedikt heller i en puristisk retning, noe som viser seg i hans egne perl-dikt. De er ikke-heterogene og selvrefererende. Slik ser perl-diktet «and» ut:[5]


   open(THIS,'and');open (THAT,">>and");while(); "#to"; close (THIS); 


Hvis du har lagret diktet i en fil som heter and, så åpner diktet seg selv og legger til seg selv på slutten av seg selv (med kommentarer). Når man leser diktet, danner det nesten en normal setning, og betydningen til denne setningen stemmer ganske godt overens med hva diktet faktisk gjør.[6]

Diktet «self» fungerer i prinsippet på samme vis, men gjør det bare på en litt annerledes måte:[7]


   #!/usr/bin/perl
   open (IT, "< self");

   while () {
   push @it, $_}
   close (IT);
   open (IT, ">> self");
   print IT join ("\n  ", @it); 
   close (IT);


Vi behøver ikke å gå gjennom koden her, for man legger uten videre merke til at i Cramers dikt «self» er Hopkins heterogenitet helt borte. De fleste ordene har ikke noen dobbel betydning som referer utenfor koden selv og hva kodediktet gjør når det kjøres, selv ikke ordet «self». Ordet «self» er et naturlig valg ut fra hvordan diktet - eller burde man her heller si programmet? - virker. Diktet tematiserer bare sin egen kode, åpner seg selv og multipliserer seg i seg selv.[8] Man kan sikkert finne en aller annen dobbeltbetydning av dette diktet, men sammenlignet med Hopkins dikt ovenfor er det her mer opp til leseren. En mulig heterogen tolkning for «self» kunne være at når egoet «pusher» seg selv, er det ingen grenser for hvor mye det kan ese ut. Men dette er ikke noe som er uttrykt i diktet, men en parallell man selv kan trekke.

At det er vanskeligere å finne en heterogen tolking for Cramers dikt enn for Hopkins', er ikke ment å påpeke en svakhet ved Cramers dikt, men skal illustrere et mer generelt synspunkt hos Cramer. En mer nærliggende tolkning av diktet «self» kan være at diktet skal illustrere at digital kode både kan være programmer som kan kjøres på en datamaskin og passive dokumenter, at de kan være gjenstand for manipulasjon, også av seg selv. Diktene «and» og «self» sier derfor noe om egenskapene til de «tekster» som særpreger datakode til forskjell fra tekster i andre medier, for eksempel på papir.

# Bilde blir til «tekst».
digitalCode = BinaryMap(MakeDiscreet(textObj, pictureObj, soundObj));

Stedet der litteratur og det digitale møtes er for Cramer ikke den teksten du ser i tekstbehandleren din, i Word eller WordPerfect. Møtestedet er heller ikke den teksten du finner på en nettside eller i Flash og andre plug-ins. For ham ligger datanettverkenes «litterære» og «tekstuelle» dimensjon først og fremst i algoritmer, maskinkoder og protokoller. Disse kan foreligge på et abstrakt nivå i et høynivåspråk, slik som i C++ og Java, og som protokoller såsom TCP/IP. Digital tekst forekommer også i form av passive dokumenter, for eksempel som vanlig tekst eller PostScript. På et lavere nivå er det derimot ingen forskjell mellom programkode og passiv tekst, for de er alle kodet i det binære «alfabetet» bestående av 0 og 1, mener Cramer. «Man kan ikke avgjøre om en snutt med kode er kjørbar eller ikke ved bare å se på koden. Denne egenskapen kommer ikke fram av alfabetet av nuller og ettall, men er helt avhengig av hvordan annen datakode - en kompilator, en sanntidsinterpretator eller en mikroprosessors innbakte logikk - behandler den. Programkode er derfor høyst rekursivt og høyst arkitektonisk, og bygger på lager med lager av kode.»[9]

Sammenlignet med vanlige språk, har datamaskinens formale språk et mindre «alfabet» (0 og 1) og færre syntaktiske regler, og derfor kan ikke en datamaskins algoritmer fange opp alt det man kan gjøre og si i et vanlig språk.[10] Men til gjengjeld kan en vanlig tekst i en bok oversettes til og representeres i det binære «alfabetet» og derfor overføres til en datamaskin uten tap av informasjon. Det samme gjelder ikke for bilde og lyd siden deres kontinuerlige variasjoner må tilnærmes med diskrete oversettelser. Alt i en datamaskin, også lyd og bilde, er derfor etter Cramers syn «tekst», det vil si kode. Dessuten utgjør datamaskinens syntaks en delmengde av den grammatikken vi finner i naturlige språk.[11] Endelig kan kode, i egenskap av programmer og algoritmer, til en viss grad sies å fange opp handlingsaspektet ved språket.[12]

Ifølge Cramer gir disse tre parallellene mellom datakode og naturlige språk oss en mulighet til å bruke datamaskiner og programkodedikt til å utforske det vanlige språkets strukturer og koder. Omvendt burde man bruke vanlig litteratur og poesi til å lære oss å lese og håndtere datamaskinenes «tekstualitet», det vil dens kodethet.[13] «I sammenblandingen av naturlig språk, programmeringsspråk og nettprotokollenes tekstkode ligger etter mitt syn det største potensialet for fremtidig datanettverksdikting; et potensiale som for tiden stort sett ligger brakk», skriver han i «Hvorfor det fins for lite interessant nettlitteratur».[14]

Om kriteriene for vellykket datanettverksdikt skriver han: «I et verdensomspennende nettverk vinner den maskinelt eksekverbare teksten en hittil ukjent kvalitet og sprengkraft. En tilsiktet protokollgjenstridig tekstkode kan sabotere datamaskiner og de dertil koplete infrastrukturene.» Her tenker han for eksempel på flood-ware og virus. «I stedet for å fremtre ovenpå de øverste protokollsjiktene til verdensveven, burde nettverkslitteratur gjenspeile de mangfoldige sjiktene til sin egen språk- og tekstkode, og man burde ved hjelp av programmeringsspråk kunne dikte nettverksprotokoller og datasystemer og ikke bare manipulere brukergrensesnittenes overflate, men snarere deres egen kode.»[15]

# «Tekst» blir til bilde.
environment = TranslateToInterface(digitalCode);

«Internett er en litteratur, det er et bokstavvesen,» skriver Cramer. Med det utgangspunktet kritiserer han at datamaskiner og datanettverk omtales som «nye medier». Siden man med «medier» gjerne tenker på passive formidlingskanaler, slik som analoge TV'er og radioer, mens datamaskiner er universelle tegnmaskiner som koder sine tegn tekstuelt, er det også uheldig å kalle datanettverk for multimediale, mener Cramer.

Cramer har vel et poeng der, men uten et (bruker)grensesnitt ville ikke en universell tegnmaskin være til særlig nytte. Grensesnittet for datanettverk og -maskiner kan varieres i det uendelige siden man med en datamaskin kan styre og ta imot input fra alle tenkelige duppeditter, ikke bare skjermer, skrivere og tastaturer. Nettopp fordi alt i en datamaskin er representert i kodet form ved binære tall, gir det mulighet for å manipulere tekst, bilder og lyd på tilnærmet samme måte. At de alle i bunnen er tekstuelt kodet, som Cramer ville kalle den binære tall-representasjonen, forhindrer ikke at man like fullt kan se på all fremtredelse på en skjerm som billedlig eller grafisk. Selv om skjermen en gang i fremtiden erstattes av et annet grensesnitt, blir vi neppe kvitt behovet for visuell formgiving. Den binære representasjonen av både tekst, bilde, lyd og programvare er såpass abstrakt, at det ikke er opplagt at den ligger nærmere tekst enn bilde og lyd. For fremvisningen av teksten som den binære koden representerer, forutsetter en billedlig eller typografisk fremstilling av bokstavene for at de skal være rimelig forståelige og tilgjengelige for de fleste mennesker. Enhver tekst har også en grafisk formgiving. Hvis man absolutt vil unngå bokstavene, kunne vi for eksempel gå tilbake til hullkortene, men en fordeling av hull på en papirremse har også en viss layout.

Pseudo-programkodedikt som konkret poesi
Grunnen til at det fins så få eksempler på den genre av programkodedikt eller nettlitteratur som Cramer foreslår, er at det krever spesiell kompetanse innen matematikk, formal lingvistikk og algoritmer. Dessuten er ikke Cramers «forbud» mot overflate og brukergrensesnitt overbevisende.[16]

Til gjengjeld forekommer pseudo-programvaredikt desto oftere. Et pseudo-kodedikt ligner mer eller mindre på et programmeringsspråk, men uten at syntaks følges helt nøyaktig. For å lese slike dikt, er det tilstrekkelig å ha generell kjennskap til programmering. Fjerner slike pseudo-kodedikt seg langt fra et konkret programmeringsspråk, er kildekodepreget til diktet kun en ren (data)estetisering, snarere enn en overensstemmelse med visse formale kriterier à la Hopkins. En slik estetisering ligner mer på konkret poesi enn på programkodedikt.

Det nye arbeidet «FILMtext» til Mark Amerika inneholder flere pseudo-programkodedikt. De inngår som elementer i en større, delvis lineær flash-design.[17] «FILMtext» er et samarbeid mellom Amerika (tekst), John Vega (Flash) og Twine (lyd). Amerika er opptatt av hvordan hans skriveprosess endres av at han må samarbeide med de andre for å kunne fullføre prosjektet. Hans skriving bakes inn i designen av helheten. Det endrer både hvordan teksten skal se ut, hva den skal uttrykke og hvordan temaet utvikles. Forfatteres aktive deltagelse i samarbeidsprosjekter som integrerer fremstilling av design og tekst, kaller Amerika for designskriving (designwriting).[18]

I datanettverkenes interaktive grensesnitt «har arrangementet av tekstlige enheter en helt nytt sett av muligheter enn det har innenfor rammene av den trykte side. Skriving kan inkorporere nye strategier av samtidighet, sammenstilling, plassering og nærhet - hver og en kan tjene en semantisk funksjon og ha innflytelse på erfaringen og lesingens rekkefølge.»[19] Forfatterens designskriving på nettet er post-litterær fordi den innebærer et farvel til romanen, til boken, et farvel til leserens fokus på én lineær tekst av gangen. For Amerika gir de nye designskrevne fortellingene opphav til multimediale erfaringer som kun er forstyrrelser i surferens omflakkende fokus.

Amerika tematiserer alt dette selvironisk i en av sine FILMtekster:


   telltarget("screenwriter") {
   gotoAndPlay("memoryrecorder");

   This is not literature;

   I am a network practitioner.

   I conduct polyvocal consciousness.

   I remix viral ostranenie.

   This is what it means to expand the concept of writing.

   This is what it means to break with out of the cage of history. 

   This is what it means to MAKE HISTORY.

   TO MAKE HISTORY UP.

   A pseudo-autobiographical work-in-progress with anticipated
   completion date of ________.

   An ongoing ungoing Life Style practice without aim.

   }

Amerika vil også oppgi skillet mellom original og kopi, mellom dybde og overflate. Han holder seg til det perseptuelle nivået og hva som utfolder seg i grensesnittet (the interface). Amerika fokuserer på hva man kanskje kan kalle grensesnitt-immanent persepsjons-fenomenologi og designskrivingen av hva som kan erfares der:


   telltarget("nightvision") {
   gotoAndPlay("nanoscript");

   Not only can there be no original, the similacrum has now lost 
   its punch too.

   Aura is interface.

   What you see is what you get.

   Or is it?

   There is only perception.

   Chewing on the raw image with eyes sharpened.

   Ripping into the pictorial flesh.

   The experience of seeing what is there in front of your eyes 
   and capturing that thereness in the experiential act of 
   perception. 

   }


I motsetning til Cramer, vil ikke Amerika trenge inn til datamaskinenes underliggende tekstlighet, men løfter den i estetisert form opp til overflaten og formgir sin tekst etter ActionScript, programmeringsspråket i Flash. Heller enn å tematisere den underliggende koden i seg selv, antyder Amerika med sine pseudo-kodedikt at hans egen litterære tekst og skriveprosess påvirkes av å være designskriving. Her ligger selvreferansen på forfatterens endrede rolle og praksis i det digitale grensesnittet.

Subversiv i koden eller i grensesnittet?
Amerika øyner fremtidige muligheter for designskrivingen i de høynivåspråk på verdensvevens overflate, som Cramer avfeier som uinteressante og kommersielle.[20] Cramer er hacker-sympatisør og foretrekker nettlitteratur som er subversiv på kodenes, protokollenes og standardenes vegne. Han er tilbøyelig til å mene at hackernes Free software- og Open Source-bevegelser med sin GPL-lisenserte programvare er det eneste vellykkede nettspesifikke litterære prosjektet som fins.[21] Men det eksisterer også andre kritiske verker som grenser opp mot Crammers idealer. Som eksempler nevner han flood-ware, virus, samt «Web Stalker» av I/O/D og nettstedet jodi.org.[22]

Amerika vil bedrive designskriving som virker analogt med Brechts teater. Surfere skal forstyrres i deres vante e-diskurs i den globale økonomien som er under utvikling. Han vil utsette dem for eksperimenter som rykker dem ut av deres e-handlende klikking rundt omkring på nettet. Her ser Amerika for seg strategier som intervensjon av nettsteder og «parasiting», det å infiltrere nettsteder som opprinnelig ikke har noe med kunst å gjøre med kunst. Det er i denne sammenhengen man må se hans forståelse av design som de-sign: «de-kontesktualisering, de-konstruksjon og de-familiarisering».[23] Som en kommentar til at det i USA nå for tiden regnes som god patriotisme å shoppe, er følgende pseudo-dikt fra FILMtekst kanskje et eksempel på de-sign:


   telltarget("polyvocal") {
   gotoAndPlay("consciousness");

   on(rollOut) {
    tell target ("seeInnocence") {
     gotoAndPlay("patriotism");

   on(press) {

    s = new posture

    s.attachPosture ("...");

    s.start(0,1);

    tellTarget ("_root.Attack01") { 
      gotoAndPlay ("bombardment");

     }

   }



Fotnoter:

[1] Se artikkelen «Algoritmer og dobbelkompetanse» for mer om algoritmer.

[2] Sharon Hopkins: «Camels and Needles: Computer Poetry Meets the Perl Programming Language», s. 1.

[3] I originalen var det ikke noe dollartegn, men min versjon av perl (5.004_04) gir feilmelding uten.
Lynkurs for begynnere i hvordan man kjører perl-dikt: logg inn på en unixmaskin eller -kloning med for eksempel telnet eller ssh. Start perl ved å skrive "perl" (uten gåseøyne) og trykk på ENTER-tasten; deretter skriver du inn hele diktet for hånd direkte via tastaturet eller klipper og limer inn hele diktet i sin helhet. (Som input-fil bruker du i dette tilfellet strømmen av tegn fra tastaturet som fungerer som såkalt standard input.) Til slutt trykker du Ctrl-D (som betyr End-of-file, i hvert fall i bash). Får du ikke avsluttet, trykker du Ctrl-C for å avbryte det hele.
Hvis det ikke kommer noen feilmeldinger på skjermen, så er diktet etter Hopkins' formale kriterium OK. Siden studie-diktet ikke genererer noen output, betyr det at du får et nytt prompt på linjen etter siste linje i diktet. Det skjer med andre ord tilsynelatende ingenting. (Ikke mye action, altså.)
Programkodedikt er interaktive i den forstand at du i det minste må skrive de inn manuelt eller starte dem for å se om de feilfrie, med mindre du har et algoritmehode som klarer å finne enhver feil i et program uten å testkjøre det.
Dersom du kommer over et dikt som er «enda mer» interaktivt i den forstand at den krever input i tillegg til at diktet selv må testkjøres eller mates til perl-skallet, må du sannsynligvis lagre diktet i en kjørbar fil, avhengig av hva slags «ekstra input» det vil ha. For å lagre diktet i en fil, gjør du følgende: Utfør kommandoen "which perl". Hvis du for eksempel får "/usr/bin/perl" som svar, skaper du en ny fil (kall den for diktfil) med "#!/usr/bin/perl" som første linje (uten gåseøyne). Lim eller skriv inn resten av diktet i linjene under. Lagr så filen og gå ut av teksteditoren. Utfør kommandoen "chmod u+x diktfil" for å gjøre filen kjørbar. Det kan også hende at du må bestemme om filen skal være skrivbar (chmod u+w diktfil) eller ei (chmod u-w diktfil). Skriv "dikt1" og trykk på "ENTER"-knappen for å kjøre diktet.

[4] Larry Wall og Tom Christiansen : «Programming Perl», OReilly, 1999, s. 552 og 553.

[5] Hvordan diktet virker er avhengig av om du lagrer det i en fil eller ikke og om du har skrivetillatelse eller ikke. Se forrige fotnote. Instruksjonen "open(THIS,'and')" sier at filen and skal åpnes for lesing og refereres til med uttrykket THIS. Instruksjonen "open (THAT,">>and")" sier at den samme filen (and) refereres til med uttrykket THAT samt at når det skrives til filen, skal det legges til på slutten.

[6] Dersom diktet etter flere kjøringer skulle gå inn i en uendelig loop, avslutter du det ved å trykke "Ctrl-C".

[7] Dette diktet må du lagre i en fil som heter self.

[8] For hver gang du kjører diktet, skjer følgende: diktet begynner med å åpne seg selv, leser inn hele seg, øker linjeavstanden og legger så i en jafs den «oppblåste» varianten av seg selv til på slutten av seg selv.

[9] FlorianCramer: «Digital Code and Literary Text», s. 6: http://userpage.fu-berlin.de/~cantsin/homepage/writings/net_literature/
code_poetry/erfurt_2001/digital_code_and_literary_text.pdf
. At Cramer kaller de to tallene 0 og 1 i datamaskinenes binære tall-representasjon for et «alfabet» er etter min mening uheldig fordi det visker ut forskjellen som tross alt fins mellom tekst og den binære representasjonen av den. Se nedenfor.

[10] «Digital Code and Literary Text», s. 4-5.

[11] «Digital Code and Literary Text», s. 4-6.

[12] «Digital Code and Literary Text», s. 8.

[13] «Digital Code and Literary Text», s. 8.

[14] Florian Cramer: «Warum es zuwenig interessante Netzliteratur gibt - Neun Thesen», s. 11, 2000: http://userpage.fu-berlin.de/~cantsin/homepage/writings/net_literature/
general/karlsruhe_2000//karlsruher_thesen.pdf
. Se også «Literatur im Internet», 1999.

[15] Se «Warum es zuwenig interessante Netzliteratur gibt - Neun Thesen», s. 12. Hans egne dikt «and» og «self» er selvrefererende på den måten han selv foreskriver.

[16] Kunstnere som Roy Ascot jobber først og fremst i forhold til datanettverkenes brukergrensesnitt og de bevissthetsforandringer de eventuelt kan føre til.

[17] Se: FILMtext.

[18] Mark Amerika: «Designwriting».

[19] Amerika siterer Anne Burdick i essayet «Designwriting».

[20] VRML, dynamic HTML, Java, Shockwave og lignende.

[21] Florian Cramer: «Warum es zuwenig interessante Netzdichtung gibt - neun Thesen», s. 11.

[22] Florian Cramer: «Nettkunst und konkrete Poesi», s. 2-3. Han nevner også Hopkins perl-dikt m.m.

[23] «Designwriting».