ハクソク

世界を動かす技術を、日本語で。

リスプと執筆の技術 (2003)

344日前原文(dreamsongs.com)

概要

  • 芸術、工学、科学 の関係性とその連続性についての考察
  • 作家や地図製作者 が現実と虚構の間でどのような役割を果たすかの分析
  • 科学的知識と工学的知識 の発展の歴史的な違い
  • 地図や物語 がどのように現実を省略・歪曲しつつも真実を伝えるかの説明
  • 創造性と探究心 が人間の活動の本質であることの強調

無知・知識・創造性の連続性

  • Charles Darwin の「無知は知識よりも自信を生みやすい」という言葉の引用
  • Lisp が「美しさの言語」と称される理由、プログラマーが芸術家のように創造する過程
  • プログラミングが 創造的自己表現 であり、単なる工学活動ではないという視点
  • 芸術・工学・科学は 真理探究の連続体 であり、相互に影響し合う関係性
  • 芸術家は 自身の内面と物質世界 を同時に扱いながら作品を生み出す存在
  • 芸術活動は 可能性の地図 を作り、時に人類の知識の限界を押し広げる役割
  • 科学や技術の発展は、しばしば 芸術や物語 からインスピレーションを受ける
    • 例： Doctor Faustus の物語→飛行機の発明、 Star Trek の通信機→携帯電話
    • 海底旅行 や 空想科学 が科学者や技術者の夢や挑戦の源泉となる

工学と科学の発展の歴史

  • 技術者（エンジニア） は実際に物を作り、経験則やパターンを記録してきた
  • 現代の工学は 計画的で線形的 なイメージが強いが、歴史的には試行錯誤の積み重ね
  • 例： Tacoma Narrows Bridge の崩壊は、最新工学でも失敗があることを示す
  • 工学知識はしばしば 科学的理論より先行 し、理論が変わっても技術が残る場合が多い
  • 古代ギリシャの 火の理論 と実際の火の利用技術の乖離

科学の役割と限界

  • 科学者は 芸術家や技術者の発見 を整理し、単純化した説明を与える役割
  • 数学 が科学の共通言語となっているが、理論は時代ごとに変化・進化
  • 量子力学や複雑系科学 などの登場で、科学理論の不確実性が増大
  • 科学はしばしば 真理の追求において敗者 となるが、その姿勢が人々に愛される理由
  • 現代社会では 科学への資金集中 と 芸術への軽視 という傾向

作家と地図製作者の役割

  • 作家は 虚構の現実 を創造し、本質的な「真実」を伝える存在
    • 例： Hemingway の物語が現実の一部を的確に描写
  • 地図製作者は 現実を目的に応じて歪曲・省略 し、利用者にとって有用な地図を作成
    • 例： ロンドン地下鉄の路線図 は地理的現実を大きく歪めているが極めて便利
  • 小説や地図は 「嘘」を含みつつも、必要な真実を伝える手段
  • 物語や地図は 情報の取捨選択、どこまで描写しどこを省略するかが重要な技術

探索・発見と創作の本質

  • 地図製作者や作家は ガイドとしての役割 と 探検者としての役割 を併せ持つ
  • 地図作成には 現地調査と発見 が不可欠であり、探検家たちの歴史がその証左
    • 例： Columbus, Magellan, Marco Polo, Lewis and Clark など
  • 作家もまた、 予想外の発想や発見 を求めて創作を続ける
  • 創造活動は 既知と未知の間を往復 し、新たな可能性や真実を探る営み

このように、 芸術・工学・科学 はそれぞれ異なるアプローチで世界や真実を探究し、互いに刺激し合いながら人類の知識と創造性を拡張している。作家や地図製作者の仕事も、現実をそのまま写すのではなく、本質を見極め、必要な「嘘」と「真実」を選び取りながら、人々の理解や想像力を導く重要な役割を担っている。

Hackerたちの意見

リチャード・ガブリエルの文章が大好きです。「プログラミング言語革命の構造」（https://www.dreamsongs.com/Files/Incommensurability.pdf）は、洞察に満ちていて美しいです。

└

シェアしてくれてありがとう。これを読みながら、フィクションに感じるような散文の雰囲気を感じるのが残念です。そんな理由はないのにね。

（2003年、後にいくつかの脚注が追加されました）

ガブリエルのサイトに行ったら、キャデラックやC++環境の基盤についても読んでみて。どうやってXEmacsになったのか、キャデラックプロトコルが現在の有名なエディタを思い起こさせること、C++のための画像のような開発環境のインフラについて、1990年代初頭のことだよ。https://dreamsongs.com/Cadillac.html

PythonはLispの芸術的な特性をたくさん受け継いでいると思う（でも残念ながら全部ではない）。だから、ある意味でLispの芸術的なダイナミックアプローチが、Pythonの人気によって勝ったと言えるね。

└

Pythonはかなり堅苦しくて退屈な言語だと思う。マクロもないし、構文はイライラするし、最近はほとんどOOだよ。インスペクションができて、ランタイムで変数にアクセスできる（ひどい構文を使ってね）けど、それだけ。言語やそのクリエイターに芸術的な志向はあまり感じないな。Rubyはすでにもっと良いメタプログラミングの話があって、コードももっとエレガントに見える。

└

最初のPythonのバージョンはLispで実装されてたと思うよ。だから、docstringが両方で同じなのはそのせいだと思う。

これは素晴らしい読み物でした。最後に言及されている本が2003年に出版されたもので、これが前書きだというのがちょっと悲しいです。Lispは、私が今まで使ったどの言語とも違う、書いたり実験したりするのが素晴らしい体験です。それでも、現場には「仕様を提供するだけ」やお金を稼ぐことにしか興味がない人たちが多いと思います。ソフトウェアの背後にあるアートにあまり関心を持たない実利主義者たちで、これはずっと変わらない気がします。技術とアート、そして熟練が結びつくのはニッチだけど、熱心な人たちのためのスペースでは繁栄していると思います。

└

... でも熱心な人たちのためのスペースでは繁栄しているってことだよね。Arcで書かれてSBCLで書き直されたサイトに投稿している熱心な人が賛成してるよ ; )

└

Lispは、今まで触ったどの言語とも違って、書いたり実験したりするのが本当に素晴らしい体験だよ。Smalltalkの経験も、いくつかの点で似ていると思うけど、言語自体は全然違うよね。結局のところ、Lispの方が好きだな。自分のシステムとよりうまく連携できる気がするから（間違ってるかもしれないけど、きっと熟練のSmalltalkerたちは、昔の自分がイライラした問題の解決策を見つけてるだろうね）。どちらも選ばれなかった道だよ。悲しいけど、Cの罠に何十年も無駄にしなければ、業界はもっと良い状況になってたと思う。でも、歴史はこうなったんだよね。そうなる運命だったのかも。

皮肉なことに、この著者はLispとプログラミングの関係を完全に誤解してるね。Lispは確かにアート的な側面が強いけど、Javaみたいな言語でプログラミングする方が、Lispよりも書くことに近いと思う。書かれた言語には確立された語彙や文法があって、作り手がそれを変えたり再定義したりすることはできない。著者が言う通り、Lispは「プログラミング言語」よりも「プログラミングメディア」としての側面が強い。プログラマーが自分の表現方法で言語を形作ったり変えたりできるからね。でも、彼はこの観察を続けて、Lispのこの特徴が人間の言語とは根本的に違うことを示す明らかな結論には至ってない。

└

それはちょっと違う見解だと思う。詩は一般的な文法ルールを操りつつ、作り手から読み手に意味を伝える。むしろその操作によって、より深いコミュニケーションが生まれることもあるよね。もちろん、Javaや他の多くのプログラミング言語では、文法エラーがあるとコンパイルすらできないけど。LISPは、プログラムごとに文法が変わる数少ない言語の一つで、詩と同じような感じだね。

└

書くときは、どんな構造やスタイルを採用しても自由だし、新しいものを作ることもできるよ。

└

英語は、任意のアイデアを伝えるための最も優れた汎用手段だと思うし、プログラミング言語と同じように文法ルールがある。人間が理解しやすいっていう基準で「最も良い」と言えるんだ。LISPは、シンプルさや構成可能性に基づく指標で「最も良い」プログラミング言語だとも言えると思う。もっとシンプルな言語はないよ。LISPには余計なものがないからね。関数を定義したり呼び出したりするのに、最もコンパクト（しかも人間が読める）な方法なんだ。LISPは他のプログラミング言語より英語に近いとも言えるよ。英語では、括弧やリストを使って言ったことに関連するものを列挙するからね。例えば「(add, 1, 2)」は、任意の数の操作にスケールできる形で二つの数字を足すのに最適な表現なんだ。「(1+2)」よりも優れてるのは、プラス記号が一文字だからスケールできないし、限られた数しか使えないから。記号を使うと、人間はそれを覚えなきゃいけないけど、「add」は読める名前だよね。「add one and two」も有効な英語の文だから、LISPのプログラムは同じように有効な英語の表現なんだ。括弧はただ言語の「句」をグループ化するために使われるだけ。もし世界が一つの高水準プログラミング言語に合意することになったら、LISPが必要になる理由は他にもたくさんあるよ。パーサーの書きやすさから、コードの圧縮、シンプルさ、学びやすさ、子供でも簡単に学べることまで。

└

それは全然間違ってるよ。

└

書かれた言語は静的じゃないよ。自分自身の語彙や文法を導入することができる。確かに、そうするとそれに不慣れな人には理解しにくくなるかもしれないけど、マクロを使いすぎたLispプログラムも同じことが言えるよね。結局、これはアートなんだ。特に英語について話すときは、めちゃくちゃなことになる。どの英語？アメリカ英語？どのグループ？全く新しい文法概念を導入するアフリカ系アメリカ人英語？インド英語？ロンドンで育った二人でも、階級や他の要因によって話し方が全然違うことがあるんだ。一つの英語なんてないし、常に進化してる。シェイクスピアの英語は21世紀の英語とは大きく異なるし、実際、シェイクスピア自身が今日でも使われている約1700語を発明したんだよ。

└

LOOP[1]見たことある？あの例もほんの表面をなぞっただけだよ。言葉に違う意味を持たせたり、文法の厳格さを壊したりすることについてだけど、英語でそれをやると詩って呼ばれるんだよね。確かに悪い詩もあるけど、素晴らしいものもあるよ。 [1] https://www.lispworks.com/documentation/lw51/LWRM/html/lwref...

著者はプログラミングを孤独な活動（発見や分析）として描写するのに多くの時間を費やしていて、詩人や探検家のようなメタファーを使って結論を出してる。LISPやSmalltalkの柔軟性がこのタスクに理想的だと強調してるけど、もし著者がアジャイルやXPの流行を調べたら、プログラミングを社会的な活動として捉えた場合、全く逆の結論に至ると思う。共有された知識や理解を築き、それが常に洗練されてから「放棄」されるソフトウェアになるんだから。

└

悲劇なのは、これらの異なる開発モード（孤独と社会、動的と静的）間を流動的に移動する方法がないことだよね。これが哲学的にも実践的にも互換性のないツールや手法を生み出してしまってる。

└

彼は70年代にAIラボにいたから、その種のプログラミング活動には慣れてたんだと思う。もしかしたら、彼は私ほどクリエイティブだとか楽しいとは感じていないのかもしれないね。

└

著者はリチャード・P・ガブリエルだよ。https://en.wikipedia.org/wiki/Richard_P._Gabriel 彼はソフトウェアの分野でかなり長くて印象的なキャリアを持ってる。

私もPythonを書くときは似たような気持ちだったな。初期の頃のPythonは美しい言語で、C#やJava、C++が主流の企業環境にこっそり忍び込ませることができたら、まるでヒップスターの反逆者になった気分だった。コンパイルが不要な小さなスクリプトを作るだけでも、魔法のように感じたよ。最近は仕事で主にGoを書くようになって、年を取るにつれてプログラミングの行為に深みを感じなくなった。プログラミングよりもハイキングやカヤックの方が楽しいし、LLMのおかげで以前は厳重に守られていたものが一般化されたからね。AIツールが多くの部分を簡素化して、プロセスよりも結果に集中できるようになったのは嬉しい。良いリンターがコードの美学に関する無駄な議論を完全に排除したみたいにね。とはいえ、今は長持ちするツールを評価してる。後方互換性を真剣に考えて、ユーザーのコードを気まぐれに壊さない言語。10通りのやり方をサポートしない言語。外部の依存関係マネージャーやビルドツールを必要としない言語。速くて、構文的なノイズが少なくて、あまり手間をかけずに自分のことができる言語。だから、私にとってはそういう便利な言語が最も美しいと思う。Pythonは、付け足された型システムや、組み込みの依存関係マネージャーがない（uvはカウントしない; 標準ツールチェーンに入れない限り、もっと増えるだろう）し、ひどい型チェッカーもあって、もうあまり魅力を感じない。誰でも好きな言語に美しいオードを書くことができて、それを深いものにすることができると思う。もしできるなら、私はGoにオードを書くだろうな。

└

「LLMが以前は厳重に守られていたものを商品化したからだ。」 そのLLMの商品化なんて見たことないし、プログラミングがゲートキーパーによって守られていたっていう君の視点が理解できないよ。過去20年間は、システムやオープンコード、言語の爆発的な進展があったんだから。君はどこからその考えを持ってきたの？

Lispの力は、そのオープンさにあったんだよね。マクロやホモアイコニシティだけじゃなくて、システムがどうやって自分で形を変えるかを前提にしてた。今の言語にはその期待がないんだよ。今ではカスタマイズは高度な機能で、基本的な部分じゃない。Lispを言語として語るけど、実際には書き換え可能な基盤みたいなもんだった。文化的な部分はロマン主義じゃなくて、ただ人々が人工的な壁なしにあるものを使ってたって感じ。

└

でも、その力は弱点にもなったんだよね。

今、Lisp（例えばCLやScheme）の残された魅力の一つは、（Clojureを除けば）あまり雇用されないことなんだ。だからコミュニティやエコシステムが、もっとオールドスクールでハードコアな感覚を持ってる。Pythonでは、プロジェクトに本気で取り組まないと、99.99%が金のためにやってる人たちによるコードや文章をWeb検索している時に見える不幸な側面を無視できないんだ。多くの人はスキルがあってプロフェッショナルで、責任感もあるけど、そういうのは普通じゃない。JavaScriptの世界では、ちょっとしたことを読むのも、NPMから供給チェーンの災害をインストールしろって無造作に言われるから大変だよ。Rustでは、言語的な考え方が魅力的な部分もあるけど、雇用可能性の問題はまだあるね。ただ、難しさがゲートキーピングの効果を持っていて、それが全く歓迎されないわけでもない（仕事が欲しいなら、JavaScriptやPythonを学べばいい）。PythonやJavaScript、Schemeではあまりできなかったシステムプログラミングのスキルを活かして、効率的で信頼できるソフトウェアを作る未来が見えるんだ。でも、例えばこの前、「このUIパッケージを試してみよう、プラットフォームのWebレンダリングウィジェットのラッパーだから、もしかしたらいい感じかも…」って思ったんだけど、なぜか「hello, world」を表示するのに503個のRustクレートをコンパイルしなきゃいけないんだよ。ラッパーだけで、ラップする非RustプラットフォームのWebウィジェットのコードは含まれてないのに。プラットフォームウィジェットはバグやメモリエラー、デザインの欠陥があるのは分かってるし、その上に膨れ上がったWebスタックを乗せて、Rustコードに呼び出しをすることになる。そんなのをデバッグしたり監査したりできる人がどれだけいるんだろうね？ただシンプルなGUIウィジェットをおしゃれに表示するために。

└

「今、Lisp（例えばCLやScheme）の残された魅力の一つは、（Clojureを除けば）あまり雇用されないことなんだ。だからコミュニティやエコシステムが、もっとオールドスクールでハードコアな感覚を持ってる。」 私がLispで42linksを書いた理由の一つは、ライセンスのヒントなしでChatGPTの返信に載る可能性が低いからなんだ。