- ジェラルド・サスマンは1962年から、IBM 7094・PDP-6・Mac Hack 6・Maximaのような初期コンピューティング環境を渡り歩きながら、プログラミングそのものの楽しさを持ち続けてきたと語る
- プログラミングは、仕様をコードへ機械的に移し替えるコーディングではなく、不完全な目標のもとで実現可能な仕様と実装をともに探っていく 抽象的な工学設計 に近い
- Lispの eval/apply 構造とMaxwell方程式の相互作用を並べて見ながら、プログラミングを物理学・数学・哲学のように深い概念的問題を扱う創造的活動として捉える
- バグは単なる失敗ではなく、有限の人間が単純化した計画で問題を解く中で生まれる学習の機会であり、「ほぼ正しい計画をデバッグする問題解決」の一部である
- 自動微分、Schemeのジェネリック演算拡張、古典力学を実行可能なプログラムとして表現した経験は、プログラミングが他分野をより明確にできることを示しており、free/libre software として共有するときに楽しさが完成すると強調する
コーディングを超えた設計と探索
- Sussmanは1962年に高校生としてコンピュータを使い始め、Columbia Science Honors Programでコンピューティングに触れた
- 初期のコンピュータはIBM 7094系のように数百万ドルし、2^15個の36ビットワードしかアドレス指定できず、約2マイクロ秒サイクルで動作する機械だった
- MITに入った後、DEC PDP-6のようなコンピュータに触れ、そのシステムは2^18個の36ビットワードをアドレス指定できた
- 大きなメモリは Maxima のような初期の記号操作システムに必要だった
- MITはFabritekに大容量メモリを発注し、製造に1年かかり、記録上およそ38万ドルだった
- このメモリは当時としては非常に大きかったため、クジラの名前にちなんで Moby と呼ばれた
- 彼は人工知能、新しいコンピュータ設計、プログラミング言語の発明、天体力学の数値シミュレーション、大規模な記号システムの作成に関わってきたが、その中心には一貫してプログラミングへの愛情があった
- プログラミングは、よく定義された仕様を実行可能なコードへ変換する機械的作業ではない
- 良い仕様は普通、上から降ってくるものではない
- 実装可能なものを探ったあとで、実際に達成できることに合わせて仕様を書く
- だからプログラミングは、部分的に定義された目標に向かって可能な仕様と実装を一緒に見つけていく 共同探索 である
- 物理的な工学と違って、プログラミングは公差、切削曲率、抵抗誤差のような物理的制約よりも、思考を組織する能力 に大きく制約される
- プログラマは表現、アルゴリズム、抽象化レベルを選びながら、巨大な仮想機械を扱う
創造的芸術としてのプログラミング
- Sussmanはプログラミングの感覚を説明するため、Edgar Allan Poeが「The Raven」をどう書いたかを説明した文章を引用する
- Poeは作品が偶然や直感ではなく、数学の問題のように段階的に完成したと述べ、選択・削除・挿入・修正の複雑な過程を明かしている
- この過程は、仕様をコードに変える作業よりも実際のプログラミングの感覚に近い
- プログラミングは、建築、音楽、数学、理論物理学のような 創造的芸術 に近い
- 数学は美しい定理を発明しようとする活動である
- 理論物理学は物理世界の説明を発明しようとする活動である
- プログラミングもアイデアと構造を発明し、磨き上げる活動である
eval/applyとMaxwell方程式が示した構造
- MIT1年生のとき、Lisp 1.5とeval/applyインタプリタを学んだ経験は、Sussmanの人生を変える契機になった
- eval は式と環境を受け取り、演算子と被演算子を評価して手続きと引数を作り、apply は手続きと引数を受け取って形式パラメータに引数を束縛したあと、本体の評価へ戻る
- Sussmanはこの構造が、あらゆるコンピュータ言語とコンピュータそのものの動作方式にも当てはまると見る
- 同じ時期、電磁気学の授業でMaxwell方程式を学び、もうひとつの強い印象を受けた
- Maxwellは電荷保存と既存方程式の不整合を解決するため、変位電流 項を追加した
- その結果、電磁波方程式が導かれ、光が電磁波であるというつながりが生まれた
- eval/applyの相互作用と、Maxwell方程式で電場・磁場が互いに変化を生み出す構造との間には深い類似がある
- こうした類似は、位置と運動量、エネルギーと時間のような 双対変数 の関係にもつながる
- プログラミングは日常的に哲学的問題に出会う
- プログラム内の
Chicago という名前が現実の都市をどう指すのかは単純ではない
- 二つのオブジェクトが同一かどうかは、一方を変更したときに他方も変わるかで明らかになり、変更(mutation) は同一性の問題と結びつく
- 純粋関数型プログラムには変更がないため、同一性を別のやり方で考えなければならない
- 引用された表現の中では、「同じものは同じものに置き換え可能である」という原則が破れることがある
- 「すべてのカラスは黒い」のような命題は、HempelのRaven Paradoxのように証拠の意味を難しくする
バグへの向き合い方
- Sussmanはバグを恥ずべき失敗ではなく、学習の機会 と見なす
- 良いツールでデバッグすることは冒険のように楽しく、バグにはfencepost errorやreader-writer bugのような名前があるべきだと語る
- バグは強力な設計戦略の結果でもある
- 人間はすべてを一度に考えられないため、計画を立てる
- 計画には単純化が必要で、単純化は抜け落ちた部分を生む
- その結果バグが生じ、デバッグはほぼ正しい計画を望む方向へ修正していく過程になる
- Sussmanはこの方法を「ほぼ正しい計画をデバッグする問題解決」と呼ぶ
- 電気フィルタ設計の例はこの戦略を示している
- 30Hzから3kHzの間で応答を持つフィルタを作るため、システム関数を因数分解する
- 抵抗とコンデンサを組み合わせて必要な部分回路を構成する
- しかし各部分回路は「電流が出ていかない」という仮定を持つため、つなぎ合わせるとloading bugが生じる
- 増幅器によるパッチが一部の状況ではこの問題を解決できる
- すべてのバグが楽しいわけではない
- SussmanはCとC++が罠だらけだと批判する
- メモリ管理バグのために新しいカーネルが頻繁に必要になる状況も、Cで書かれたコードと結びつける
- Pythonでも
{} は辞書だが {1} はsetであり、tupleは括弧ではなくカンマで定義されるなど、一貫性に欠ける例を挙げる
自動微分と実行可能な物理学
- 1992年、SussmanはCaltechでKip Thorneのグループと過ごしながら一般相対性理論を学び、知識を保存する媒体としてプログラムを使ったと語る
- Hewlett-Packardの浮動小数点チップ設計者だったDanとともに関数の導関数を考えるうちに、前方モード自動微分(forward-mode automatic differentiation) を独立に再発見した
- 目標は、関数の中身をのぞき込む記号微分でも数値近似でもない方法だった
- 核心はchain ruleだった
- 数を有限部分と無限小部分を持つdifferential objectへ拡張すると、関数合成でchain ruleが自動的に働く
- Schemeを使っていたため、原始算術演算子をdifferential object向けに再定義でき、Sussmanはこれを「hack attack」として一晩で実装した
- その後、多くの人が高階関数の導関数、多変数導関数、Schemeの原始演算の動的拡張を洗練させることに貢献した
- Abelsonは多変数導関数の正しい理論を整理するのを助けた
- Jeff Siskind、Barak Pearlmutter、Alexey Radulは高階関数の導関数に関する微妙なバグをデバッグした
- HansenはSchemeの原始演算を効率よく動的拡張する方法を考案した
- この作業はJack Wisdomとともに使った Scmutils システムへとつながり、古典力学と微分幾何学の教育と研究に用いられた
- SussmanとWisdomによる『Structure and Interpretation of Classical Mechanics』は、計算技法によって古典力学の理解を明確にしようとする本である
- 従来のLagrange方程式の表記は、文化的知識がなければ曖昧で、関数の型という観点からも問題がある
- 関数型の表記とSchemeコードで書けば、数学的アイデアは 明確で実行可能なプログラム になる
- 単振動子の例では、質量、ばね定数、位置に対する正しい運動方程式と角振動数の関係を計算する
共有されて完成する楽しさ
- Sussmanはプログラミングの楽しさをいくつかの側面に整理する
- 異なる世界のあいだに深い類似を発見する楽しさ
- 哲学者たちが長く考えてきた問題に実作業の中で出会う楽しさ
- バグを追跡する狩りの楽しさ
- 良いアイデアと抽象化を発見する楽しさ
- プログラムによって他分野を明確にする楽しさ
- プログラミングの楽しさは他の人と成果を共有するときに完成し、free/libre software を使い、書くことを勧める
- SussmanはZoomで録画しなければならなかったことを残念がり、読んで修正し、再び共有できるソフトウェアを望むと語る
- 自由ソフトウェアとソフトウェアの自由については GNUの自由ソフトウェア哲学 を参照するよう勧め、Free Software Foundationへの参加と寄付を呼びかける
1件のコメント
Hacker Newsのコメント
この部分が本当に良かった: 「プログラムは何かを記憶する方法として書く。私の記憶は、私が書いたプログラムだ。数学、物理、生物のようなものを学び、それを表現するプログラムを書いておけば、後で読み返しても曖昧ではなく理解しやすいので、知識をそうやって保存していることになる」
https://www.infoq.com/presentations/Expression-of-Ideas/
上の引用と非常に近いテーマで、プログラミングが数学や物理のような対象をより深く理解するのにどう役立つかを扱っている
たとえば鎮痛剤が作用する仕組みはキーロガーや中間者攻撃を理解する助けになり、有糸分裂中のDNAの「文法チェック」を見るとコンパイル全般を学べる
子犬が目に入ったものを何でも飲み込もうとする行動は、免疫系に周辺環境について十分なテストデータを与えることでもあり、機械学習にも似ているし、サイバーセキュリティの概念のかなり多くも生物学から理解できる
私は図で考えるタイプなので、数学を本当に理解するのは難しかったが、コーディングによって頭の中に図や関係性を作れるようになった
子どもの頃にこれを知れたのは幸運だったし、なければ道に迷っていたと思う
問題、決定、理由、根拠となった事実、検討した代替案はすべて知識であり、プログラミング言語に入力した各命令も一つの決定だという見方だ
ソフトウェア設計は、以前の決定や文脈を忘れてしまうほど長く続くことがあり、人が去って知識が失われ、新しい人が入って知識不足になるほど長く続くこともある
コンピュータにソースコードを理解させることは難しい部分ではなく、より難しいのは、他の人が何が達成されたのかを理解し、より良く、より速く作業できるようにすることだ
頭と記憶だけでは足りないときには、文章、印刷、ソフトウェアのような技術の助けを借りて、より大きな知識の束を記憶し整理しなければならない
数学で最大の問題だったのも、自分が誤りを犯さないと信じることも、誤りを見つけられると信じることもできない点だった
コンパイラやインタプリタは、それに気づかせてくれる
昔、NYUの地下で神経科学の博士課程学生20人ほどと一緒にSussmanの講演を聞いたことがある
AIの解釈可能性が流行するずっと前から、その話題について語っていた
質問を一つしたところ、部屋に電気工学専攻がいることをすぐ見抜いて隣の黒板に行き、演算増幅器がどう動くかを第一原理から導けることを示してくれた
あの人にはものすごいエネルギーと知性があり、間違いなく強い印象を残した
動画はまだ見ていないが、SICPの献辞でSussmanとAbelsonが使ったAlan J. Perlisの引用をすぐ思い出した
コンピュータサイエンスにおいてコンピューティングの楽しさを守ることは非常に重要で、初期には本当に楽しかったという内容だ
顧客が時には被害を受け、その不満を真剣に受け止め始めたものの、私たちがこの機械の成功した、誤りのない完璧な利用に責任を負っているとは見ていない、という観点だ
むしろ機械を押し広げ、新しい方向へ送り出し、楽しさを保つ責任があり、コンピュータサイエンスが楽しさの感覚を失わないことを願い、宣教師や聖書の訪問販売員のように振る舞うな、というのが核心だ
成功するコンピューティングの鍵が自分たちの手にしかないとは感じるべきではなく、手にしているのは知性、つまり最初に触れたときよりも機械をより多くのものとして見て、より大きくできる能力なのだとする
豆を数えるプログラムを作っているその他大勢にとっては、給料を払う側の立場では、豆を一つも失わないことのほうが、私たちがどれだけ楽しんでいるかや可能性をどれだけ広げているかより、はるかに重要だ
バグではなく小さな楽しさの塊だというわけ /s
より良いタイトルは「学術的コンピュータサイエンスは面白い、あるいは面白くあるべきだ」に近い
要点は、類推を見つけること、哲学的に考えること、デバッグすること、良いアイデアを出すこと、明晰さを得ることはすべて楽しい、というものだが、これは主にそうした活動に給料が出る教授のぜいたくであり、「顧客が今週末までにこれを欲しがっている」という世界には、デバッグの議論好きな楽しさを除けばあまり当てはまらないように見える
たいていの「プログラミング」は、おそらく溶接のように職業訓練校の科目に近いものとして見るべきだ
新しい溶接技術を開発するなら大学院レベルの研究課題であるのは確かだが、ほとんどの溶接工やプログラマは、よく知られた道具と比較的単純なシステムで仕事をしている
職業訓練校の学生は、MIT/GNU Schemeを学んだあと職業人生で二度と使わないかもしれないものに時間を無駄にしたくないかもしれないが、学術志向の学生にとっては、言語学専攻がLinear Bを読み書きする方法を学ぶように実りあることかもしれない
どんな仕事でも楽しくなりうるが、結局は同僚や管理職の力量と情緒的安定性、作業空間の設計と安全性、生活可能な報酬、ずさんな仕事をそのまま通してしまう組織文化かどうかといった条件のほうがより大きく作用してきたし、産業制御システムのプログラミングのような他の専門職でも同じだ
好奇心があり、思慮深く、学ぶ人は、独学かどうかにかかわらず、どんな職業でもそうでない人よりうまくやるということが分かるはずだ
ずっと昔に溶接工として働いていたときも、賢く、やる気があり、好奇心のある人たちは、ただ時間をつぶしているだけの人たちよりもうまくやっていた
だからプログラミングが溶接に似ているという点には同意するが、それは意図された意味とは別の形でだ
SICP は、Pascal や C でハックしていた同僚たちのそばで、コード、抽象化、モジュール性についての考え方を完全に変えてくれた
Lisp/Scheme では問題の精神的モデルを構築できた一方で、同僚たちは頭の中で抽象化を行ったうえで、低水準への集中を要求する言語で実装しなければならなかった
だから SICP に早く出会えたことに永遠に感謝している
どの言語でプログラミングするかによって、より楽しくも、より快適にもなりうる
C++ にはたぶん一生慣れない気がする
SICP の著者の一人が語るプログラミング観を聞けるのがよく、冒頭数分の逸話も悪くない
翌日に Sussman に会うのでどうしても必要だと伝えたところ、店員が Harvard co-op に電話し、1冊在庫があると言われたので、Uber に乗って Harvard の書店へ行き SICP を買った
翌日 MIT の Sussman のオフィスへ行くと、偶然 Abelson もいてちょうど出ようとしていたので、二人とも私の SICP にサインしてくれた
Sussman は「あと15分早く来ていれば妻もサインしてくれたのに！」と付け加え、その時まで彼の妻が SICP の校正者だったことを知らなかった
この二人の魔法使いと、サインしてもらったばかりの紫の本を持った私が写った素敵な写真もある
この動画を早く見たい
まだ SICP にきちんと取り組んではいないが、本は借りてあり、家の修理をしながら講義は聴いた
SICP の講義にある、複雑なものを理解することについての Sussman の引用 は建築関連の発表によく入れていて、人々がいつも必死に書き写すスライドになっている
正直なところ、何年ものあいだプログラミングを愛してきたし、一時は主な趣味でもあった
新しい言語やソフトウェアを試したり、プログラミングの本を読んだり、libera/freenode のようないろいろなチャットに参加したりしていた
しかしフリーランスになって、より小さな文脈で素早く十分に良いコードを納品することに集中するようになってから、その情熱は薄れていった
エンジニアとしては全体的に良いことかもしれないが、日常業務から多くの 楽しさと学び が失われた
フリーランスやコンサルティングはたいてい問題解決、あるいは問題の切り分けのように、できるだけ早く問題を取り除く仕事であり、優雅さは必須ではない
ツールを作るビルダーになりたいのなら、フリーランスではあまり起こらなさそうで、コンサルタントの役割に移れば可能かもしれない
コンサルタントはもう少し長期的な関係に近いと考えるなら、次の段階として検討する価値はある