1行のコード
ソフトウェアと、それを記述するコンピュータ・プログラムは、今日もっとも身の回りに溢れ、私たちの生活の中に偏在するメディアとなった。コンピュータはプログラムに書かれたコードを翻訳、解釈、実行することで、大量のデータを処理し、その結果を表示したり、コンピュータ同士でやりとりする。人々は、コンピュータのプログラムを作成するだけでなく、ソフトウェアを日常的に使用することで、ものごとの見方や考え方を形作っていく。私たちは、プログラム・コードをつくるだけでなく、プログラムによってつくられている。
プログラムは、コンピュータと人間の双方が理解可能な、人工言語によって記述されている。プログラムはコンピュータと人間のコミュニケーションの記述であり、より一般的には（分析や解釈の対象となる）「テクスト」である。そこには、アルゴリズムだけでなく、プログラム制作の前提、目的、過程、改良の過程が埋め込まれている。さらに変数や関数の名付け方や、アルゴリズムの注釈や解説といったプログラムのアルゴリズム以外の部分にも、さまざまなものごとを書き込むことができるし、逆に人間にとって理解しにくいよう難読化することもできる。プログラムは数学／数値的、論理／構造的な言語であると同時に、文化／人文的、思想／哲学的なテクストでもある。
実用的な、あるいは有用なプログラムの多くは、正しく、効率よく実行すること、あるいは保守や改良、再利用がし易いことが求められている。それらを巧みなバランスで実現したコードはしばしば、コンピュータ・プログラミングの「ART（技芸）」と呼ばれる。しかし、そうした自明な目的や有用な機能がないプログラム・コードでありながら、多くの人に共有されているものも存在する。そのひとつの（代表的であり、極めて早い時期の）例が、「10 PRINT」と呼ばれる1行のBASICプログラムである。
10 PRINT CHR$(205.5+RND(1));:GOTO 10
「10 PRINT」プログラムをVirtualC64（Commodore 64のエミュレータ）上で実行している様子
Commodore 64という、米コモドール社が1982年に発売開始した8ビットの家庭用コンピューターで、この極めてシンプルなコードを実行すると、斜め線、または逆斜め線のグラフィック記号がランダムに1つづつ、左から右、そして上から下へと表示されていく。画面が一杯になると2行ずつスクロールし、このプログラムは（中断するまで）永遠にこの表示を繰り返す。当時のコンピュータの速度は遅かったので、記号が画面を埋め尽くすのには約15秒かかる。しかしこのたった1行のコードが、当時のさまざまななパーソナルコンピュータに移植され、さまざまなバリエーションが生みだされた。そして、Commodore 64の誕生から30年を経た2012年、この文化的工芸品としてのプログラムを、ソフトウェア・スタディーズの視点から詳細に分析した本※1がThe MIT Pressから出版された。本のタイトルも『10 PRINT CHR$(205.5+RND(1));:GOTO 10』である。
ジェネリックでないコード
今日の、使いやすく、わかりやすく、役に立つ、そして技芸に優れたソフトウェアからみれば、こんなちっぽけで単純な迷路生成プログラムは、取るに足らないもののように見える。しかしそんな、40年近く前のマイクロコンピュータのための1行のプログラムに対して、今なお多くの人が関心を持ち、議論し、さらには今日のコンピュータにも移植され、さまざな修正版が実行されているのはなぜなのだろう。
まず重要なのは、このプログラムが非常に短いことである（おそらくこれ以上に短いものは、“hello, world” くらいのものだ）。今日の大規模データを活用した計算論的（computational）な文化分析手法（cultural analytics）が、対象そのものに触れることなく、そのマクロな傾向を把握しようとするのに対し、このコードは私たちに、ミクロな「精読」を要求する。しかしその精読は、限られた専門家による精読ではなく、（コードが短いがゆえの）万人に開かれた、そして対象に自由に手を加えることができるような精読である。
伝統的なプログラミングにおいては、プログラムで記述しようとする対象を分析し、それをなるべくシンプルなかたちで抽象し、（人間にとって）わかりやすい形で表現することが推奨されてきた。こうした機能の抽象化によって、コードの汎用性、再利用性を高めたコードを「ジェネリック・コード（generic codes）」と呼ぶとすれば、「10 PRINT」のように、（キャラクター文字を使って迷路のような模様を生成し続けるという）ある限られた目的のために作られたプログラムは、「スペシフィック・コード（specific codes）」と呼べるだろう。
スペシフィック・コードという呼び名は、ジェネリック・コードの対義語であるだけでなく、米国の美術家ドナルド・ジャッドが1964年に提示した「スペシフィック・オブジェクト」という概念にも由来している※2。ジャッドのこの概念は、50年代から60年代に制作された、アメリカ美術の新しい傾向の特徴分析から生まれたものである。「彫刻でも絵画でもない」このスペシフィック・オブジェクトのように、スペシフィック・コードはプログラム・コードであるだけでなく「テクストでもポエトリーでもある」。一般的で汎用のコードは、コードそのものよりも、コードが記述しているアルゴリズムとその実行結果が重要であることが多い。それに対して、スペシフィックなコードは、コードそのもの、そこに何がどのように記述されているのかが重要である。つまり、コードの実行結果（例えば「10 PRINT」が描く迷路自体）だけではなく、コードを実行した主体がその実行をどのように受容（観賞）したのか、コードの実行中に何が生み出されているのか、そしてそれらが指し示しているものごとは何なのか、ということに思いを馳せなければならない。
ミニマルであるが故に、固有のものであると同時に拡張的でもあるスペシフィック・コードは、ユーザーにシステムやツールを提供するのではなく、ユーザーとしての、つまり個人の使用から見たコードの内在的な可能性を探求し、それを限りなく拡げていこうとする。通常のプログラミングにおける有用性や再利用性のような、客観的な価値や機能を実現するのではなく、その意味や価値は状況や文脈（コード以外の環境）に大きく依存している。スペシフィックであるということは、ジェネリックでないだけでなく、それが異質であり、強いインパクトを持っている、ということでもある。
テクストとしてのコード
スペシフィック・コードが現れる代表的な場として、「コード・ポエトリー」と「ライヴ・コーディング」の2つがあげられる。コード・ポエトリーとは、その名前の通り、コードを用いて詩を書くことである。その代表的なサイトの一つである、Source Code Poetry※3には、このような規範が書かれている。
- どんな言語でもいい：あなたが一番好きな言語で書いてください。
- コンパイルできること：とはいえ、インタープリタ言語で書かれたものでも受け付けます。
- 韻を踏むこと：とはいえ、現代の名作は規範を逸脱しています。
このサイトには、さまざまなコード・ポエトリーの作例が掲載されている。中でも、Python言語で書かれたこのMike Heatonの詩はもっとも短いものである。
t = 0
while True:
print("Nothing lasts forever.")
t += 1
「10 PRINT」と同じように、単にテキスト出力を無限に繰り返す（だけの）ものであるが、時間を表す変数名の「t」と出力を繰り返す文の間には、意味の詩的な結びつきがある。
2012年に刊行された「code {poems}※4」というアンソロジーには、55のコード・ポエトリーが掲載されている。これらは、プログラム・コードとして実行するよりもむしろ、テクストとして読まれることを意図している。例えば、Daniel Bezerraの「UNHANDLED LOVE（処理されない愛）」は、C++のプログラムではあるが、その実行結果ではなく、プログラムのエラー管理機能としての「例外処理」が持つ意味を用いた詩である。
class love {};
void main()
{
throw love() ;
}
Richard Littauerの「Import Soul」も同様に、Python言語としての意味とテクストそのもの意味が重ね合わせられている。
# This script should save lives.
import soul
for days in len(life):
print "happiness"
Daniel HoldenとChris Kerrによる、「./code–poetry※5」は、逆にコードの実行結果に着目したものである。そこにはコードの実行時に具体詩、あるいはアスキーアートのような視覚的出力が生まれる、実行詩としてのコード・ポエトリーが数多く収録されている※6。
./code –poetryトップページの「turing.poem」のスナップショット
パロールとしてのコード
ライヴ・コーディングは、プログラム・コードを直接操作しながら行うライヴ・パフォーマンスの総称である。その起源は、21世紀初頭のラップトップ・ミュージック、さらには80年代のFORTH言語の音楽制作への使用に遡ることができる※7。今日のライヴ・コーディングは、Algorave※8というクラブ文化との融合や、プログラミング教育への応用※9など、多様な文化と結びついている。
ライヴ・コーディングのスタイルには、白紙のエディターから始めて、その場で一からすべてのコードを書く人から、事前に用意していたコードのフラグメントを、DJのようにその場で組み合わせていくスタイル（CJ：コード・ジョッキー）まで、さまざまなやり方がある。しかし、基本的にライヴ・コーディングにおけるコードは、音のようにその場で生まれ、その場で消える。コード・ジョッキーのように、事前に準備しておくことはあっても、パフォーマンスの場で一度実行されたコードを、そのまま別のライヴで再利用することはない。
ライヴ・コーディングの場におけるコードの現れ方を、もっとも特徴的に体現しているのが、ライヴ・コーディング運動の提唱者の一人であり、自らが生み出した TidalCycles※10というライヴコーディング言語を用いて行われる、アレックス・マクリーンのパフォーマンスだろう。彼が2018年11月に来日した際に出演した、DOMMUNEでのライヴの様子が以下に記録されている。
YouTube: Alex McLean (Yaxu) live on DOMMUNE Tokyo, 14 Nov 2018
TidalCyclesという言語が、少ない入力で迅速に出力（パターン）を変化できるように設計されているため、アレックスが書くプログラムは決して長くはなく、どんなに長くても数行で、全体が1画面の中に収まる程度である。ライヴ・コーディングにおいては、ディスプレイが身体であり、この身体をパフォーマーと観客が共有することから出発していることを考えれば、常にコード全体を一望できることは、ライヴ・コーディングの演奏者にとっても、リスナーにとっても、重要な意味を持っていることがわかる。
しかし何よりアレックスのコーディングで印象的なのは、コードの入力のしなやかさと、書いたコードを実行し終わるとすぐに消し、新たなコードを次々と書き続けていく、エフェメラルな姿勢である。プログラム言語というと、どうしてもアルゴリズムを正確に記述するラング（規則体系としての言語）を思い浮かべがちだが、アレックスのライヴ・コーディングにおけるコードは、話しことばとしてのパロール（個人的な発話）である。コード入力の行き来はアレックスの思考の構造を垣間見せ、カーソルの揺らぎはアレックスの思考の状態を反映している（ように見える）。このパフォーマンスでは、映像のちょうど18分のところで突然コンピュータがクラッシュし、再びそこからライヴを再開するのだが、そんなハプニングも決してエラーやミスには感じられない。日常の会話においては、言い直したり、中断する（させられる）ことは茶飯事である。パロールとしてのコードは、スペシフィック・コードのもうひとつの重要な特徴である。
通気口としてのコード
ソフトウェアが日常のインフラストラクチャーとなり、スマートフォンが生活の日用品となった今、それらは生活の中で、ますます見えなくなっている。人間は、スマートフォンを運ぶメディアとなり、人々のものの考え方や行動は、暗黙のうちにソフトウェアによって操作管理されている。冒頭で述べたように、プログラム・コードは確かに人間がつくったものであるが、逆にプログラムによって人間なるものがつくられている。
そうした状況の中、個人、あるいは市民としてのエンドユーザーが、自らの手でプログラムを書き、それを実行することに、一体どんな意味が残っているのだろうか。本稿で取り上げたいくつかのスペシフィック・コードは、
- 極めて短いミニマルなコード
- 正しさよりも大切なものがあるコード
- アルゴリズム以外の部分も重要なコード
- 環境や文脈に依存するコード
- 実行する必要のないコード
- 話し言葉のように生成され消滅するコード
といった特徴のいくつかを持つ。それはいずれも、IT／SNS企業やエリートハッカーのように超越的に見える何者かが提供してくれる、使いやすく、わかりやすく、役に立つものとは違うかもしれない。しかしスペシフィック・コードは、自分でつくり実行するものであり、変更できるものであり、他の人たちと共有できるものでもある。その意味で、スペシフィック・コードは、究極のエンドユーザー・プログラミングであり、今日の資本主義と監視社会の中で、個人が自由に息をするための、通気口のひとつにもなる。だから僕自身、個人が生き延びるための通気口としてのスペシフィック・コードを書き、そのことについて、もうしばらく考え続けたいとも思っている。
