文章を書くということは不思議な行為だ。常に曖昧なものを含んでいるし、自分が伝えたかったことが、読み手に正しく伝えられているかどうかを判定する方法もない。そもそも自分が伝えたかったことが、正しい文章に表現されているかどうかを確認するすべもないのである。だから理論的には他人の書いた文章の「添削」はできないことになる。やったところで添削した結果の文章が、元の作者の意図通りになっていない確率は高い。そもそも元の作者の「意図」というものをどう取り出したらよいのかについて、添削者もできないし、元の作者ですらできないのである。それでもかろうじて添削指導が成立するのは、添削者のなかに、良い文章、通じやすい文章の規範モデルが存在しているからだ。しかしその規範は、元の作者がその文章を書いた意図とはまったく無関係に存在している。したがって、添削によって文章は通じやすくなったが、逆に、原作者の意図は通じにくくなってしまったということは十分起こりうる。
一方、プログラムを書くということは、同じ「書く」という行為でも、文章に比べてきわめて明快な特徴を持っている。
まず第一に、それは常に目的を持っているということだ。つまりそれを書くための意図が明確にあるということだ。「さて、何かプログラムでも書いてみるか」と言って、何をやるプログラムかを決めないで書き始める人はいないだろう（いたら知らせて欲しい）。しかし、この文章をここまで書いて来た私は、いまだに何のためにこの文章を書いているのかを明確に意識していない。いつものように1600字程度書いたら終わりにしようと思うが、そのときまで最終的にこの文章はどういう意図を持ったものになるか私自身わからないのだ。
プログラムの第二の特徴は、それを実行してみれば、正しいのか、あるいはどこかに間違いがあるのかがはっきりわかるということだ。実行するためには、まずソースプログラムをコンパイルする。これによって文法的な間違いをはじく。文法的な間違いがなくなれば、コンパイルされた結果のオブジェクトを実行する。この実行結果が自分の目的に沿う形に出力されていれば、自分の意図が実現されたことになる。
文章の場合、コンパイルはスペルチェックや文法チェックに当たる。スペルチェックはすでに実用に供されている。文法チェックも基本的なものであればある程度は間違いをはじくことができる（この文章に間違いがときどき見つかるのは、スペルチェッカーも文法チェッカーもかけていないからである）。しかし文章が語彙的にも文法的にも正しいと証明されたあと、その文章が自分の意図を実現化してくれるかどうかチェックする方法がない。つまりできあがった文章を「実行」してみて検証することができないのだ。そもそも「文章を実行する」とはどういうことか、わからない。
とはいえ、実行できる種類の文章はちゃんと存在する。インストラクション（教示文）である。たとえば、料理のレシピはこれにあたる。「フレンチトーストの作り方」という文章はそれにしたがうことによって「実行」する事ができ、実行した結果を食することよってインストラクションの正しさを検証することができる。プログラムとインストラクションの類似性はその構成要素にもある。プログラムは宣言文（定義）と命令文の二種類の文から成っているが、インストラクションもまた、宣言文である「用意する材料」と、命令文である「料理の手順」の二種類の文から成っている。
さて、問題はインストラクションではない文章（たとえばこの文章）である。とここまで書いてきたときに、現代のプログラミング様式の主流であるオブジェクト指向では、フローチャートで描けるような古典的なプログラミングといささか違うのではないかということに気がついた。古典的なプログラムはインストラクションと同型であるが、オブジェクト指向プログラムは、インストラクションとは違う。そこでは、オブジェクト同士のメッセージのやりとりや、ユーザがオブジェクトに働きかけることによってプログラムされた働きが発現する。こう考えると、ホーンが「ハイパーテキスト情報整理学」の中で文章の種類を分類することに注意を払った意味が分かる。文一つや段落一つ、あるいは章ひとつがオブジェクトであると考えればいいのである。ポイントはそれらオブジェクトの配置とオブジェクト同士の関連である。
（なるほど。これは面白い思いつきかもしれない）
はじめ、この文章を書くための明確な意図はなかった。しかし、ここにいたってやっと実行結果が得られた。つまり、この思いつきに至る思考過程を書き留めておくことである（しかしこれがどう役に立つのかはわからない）。こうしたたぐいの文章はインストラクションの対極にある。一番分析的に扱いにくい種類のものである。
