アラン・ケイの「Is "Software Engineering" an Oxymoron?」

OOP


UPDATE!!：
id:propella さんがすばらしい翻訳を公開してくださいましたので、そちらをどうぞ


"-- -- -- -- -- -- -- -- -- -- -- -- -- --"


タイトルの訳はよく分からないのですが「“ソフトウエア工学”は矛盾表現か？」みたいな感じでしょうか。

これは、Croquet（Squeak システム上に構築された仮想３Ｄ空間オーサリング用のフレームワーク。Qwaq 社による商用化もされている）の最初の公開バージョンのマニュアル（Croquet0.1.pdf）の付録に掲載された文章なのですが、なぜか公式サイトからは消えていて、ググって見つけた勝手アーカイブから入手できる元の PDF でも絵が壊れていたので、それを直してあらためて当該文章だけ PDF 化して勝手ミラーしておきました。


真の“ソフトウエア工学”と呼べるものはまだないけれど、次善の策として動的結合というものが役に立ちそうなこと、それをメッセージングで実現することでどんなメリットがあるかなどが語られていて、メッセージングのＯＯと抽象データ型のＯＯとの（要素だけ挙げると共通項も多そうな気がする両者において）決定的なスタンスの違いを際だたせるのに役に立つ内容ではないかと思います。

あと、動的言語というと巨大システムの構築や長期プロジェクトには向かないというのが現在の“常識”となっているわけですが、メッセージングという“ツール”と、Smalltalk システムという“実績”を持つアラン・ケイの頭の中ではそれが真逆になっているのもおもしろいですね。（ただ、動的な言語ならなんでもいいというわけでもないので LISP 以外の動的言語のファンはぬか喜びしないほうがよさそうです。言語が動的でも、処理系自体が古い“工法”で作られていたらダメだと思うので。詳細は原文を）


以下、内容をおおざっぱにメモ。自慢することじゃないですが、訳はかなりいいかげんなのでできるだけ原文にあたってください。

▼（イントロ）

  • 真の“ソフトウエア工学”というものは、まだ存在しない。
  • 今のソフトウエア技術者は、エンパイアステートビルを一年、3000人以下で造り上げた技術者たちが用いたようなアイデアやツールを持ち合わせているとは言えない。
  • 今の“ソフトウエア工学”は、あるとしてもエジプトのピラミッドを造っていたころのレベル。
  • まだアーチ構造が発明される前の状態（文字通り、アーキテクチャー以前）。
  • ピラミッドは、何十万もの人手で十年以上かけて石を積み上げて造られた。
  • 使われたアイデアやツールも貧弱で、こうした状況は今のソフトウエア開発に似ている。
  • ソフトウエアにおいて、真に近代的な工学的プロセスに我々を導いてくれる実践は存在するのだろうか？
    • 単純になにかを積み上げること以上に強力な
  • 我々の抱えているジレンマに、似たようなゴールに向かうプロジェクトでも毎回、多くの学習を強いられるという状況がある。
  • 我々がソフトウエアについて本当に知っておくべきことをまだ知らないという事実も原因の一部であろうが、
  • ランプソンが指摘しているように、ムーアの法則による絶え間ない状況の変化が、似たようなものに見えるゴールを実際は違うものに変容させしてしまっている、ということもあるかも。

â–¼ The FRAM oil filter principle

  • プロジェクトの進行の途中で、プロジェクトの開始前に知っておきたかったことを発見することは常である。
  • 古いソフトウエア開発スタイルでは、新しい方法が見つかっても、最初からやり直さないかぎり使えない。
  • ソフトウエアは完成して動き始めてからのほうがコストがかかり、その要因は多岐にわたる。
  • 早期の都合が良く省コスト的に見える処置も、長いライフサイクルのプロジェクトでは後に指数級数的なコスト増を生じさせうる。

â–¼ Late binding

http://squab.no-ip.com/collab/uploads/61/oxymoronfig2.png

Late binding allows ideas learned late in project development to be reformulated into the project with exponentially less effort than traditional early binding systems (C, C++, Java, etc.)

  • 真の“ソフトウエア工学”と呼べるものが現われるまでは、動的結合が次善の策。
  • システムを走らせながらテストしたり、変更を加えたりできるべき。
  • 根幹に関わる変更も、インクリメンタルに実施でき、その変更は瞬時に反映されるべき。
  • 危険な結果をもたらす変更に対しては、その“取り消し”の手段が複数用意されるべき。
  • 総括的なメモリ管理。ＧＣ。オブジェクトのサイズ変更を安全に行なえる。
    • 何年にもわたって運用され、いろいろなものが追加されたシステムがあるとする。
    • そこですでに存在する何十万のオブジェクトすべてに安全にインスタンス変数を追加することが可能だろうか？

â–¼ Modeling and models of all ideas

  • 開発環境それ自体をモデルにすることは有効である。
  • （何かを）開発中に得たアイデアを開発環境自身に適用できる。
    • オブジェクトはどうやって作られるべきか？
    • 変数とはいったい何者なのか？
    • まったく違った継承システムを容易に試せるか？
    • クラスベースよりプロトタイプベースのほうが有効か？　それを実際に確かめて判断できるか？
  • An extension of modeling basic building blocks is to also model and simulate larger facilities.
    • Squeak VM にはドキュメント化された仕様はない。
    • しかし、Squeak VM には Squeak Smalltalk 自身で書かれ、実際に動かしデバッグもできるシミュレータがある。
    • （そのコードを C に変換後、ホストOS 向けにコンパイルすることで、実際に運用可能な Squeak VM をビルドできる。）

â–¼ Fewer features, more meta

  • 将来必要になるすべての機能を予測することはできない。
  • 必要なのはメタな機能。
  • 多くのソフトウエアはノンメタな機能満載の言語で書かれてしまっている。
  • C++ ã‚„ Squeak Smalltalk のように、メタな機能はあるがユーザーのメタスキルの欠如がそれをスポイルする場合もある。
  • 総じて、今のプログラマの多くは、静的結合の言語で学習しているため、メタプログラミングを学びにくいという問題もある。

â–¼ What are the tradeoffs of learning "calculus"?

  • Squeak のような動的でメタな機能を有するシステムでは、equivalent mechanism や、文法、日常的なプログラムを（通常の言語処理系や OS 同様に）学ぶこともできるが、そうしたことだけではなく、
  • 新しいアイデアを得たり、それでシステムにパワーを与えるのには何が必要かを改めて整理したりすることも学ぶべき。
  • Squeak のようなシステムには、新しい解析学（微積分学）を学ぶような心構えで接するといい。
  • 解析学というのは、代数学や幾何学のたんなる延長ではなく、新しく、たいへん強力な方法論を我々に提供してくれる。
  • 解析学を学び、パワーとして利用できるようになるには１ヶ月では足りないかもしれないが、１年もあれば多くの人には十分だろう。
  • 100年前の建築士は誰も、まだ、テンソル解析というたいへん強力な解析学を学ぶ必要がなかったが、
    • 構造物にかかるねじれや圧力、張力を解析したりシミュレートするのに役立つ非常に美しい新しい数学
  • しかし 50年前にはもう、この新しい数学を流ちょうに操れることは真の建築士には当たり前のことになっていた。
  • Squeak のようなシステムを学ぶことで得られるパワフルで今までとは違ったアイデアは、このテンソル解析が提供するものと似ている。
    • 《そしてそれはテンソル解析を学ぶよりもっと簡単に得られる。》
  • これらのアイデアは、今はまだ慣習化されていないが、そう遠くない未来にはきっと普通のものになるだろう。

â–¼ Most of current practice today was invented in the 60s

  • 世の中に受け入れられ浸透するのには時間がかかることに留意する必要がある。
  • たとえば、C から C++ が生じるのに為されたことは、1965年ごろの ALGOL に SIMULA が為したこととほとんど一緒。
  • Java もよく似ている。
  • マウスやハイパーリンクは 60年代の初頭に発明されている。
  • HTML は 60年代の終わりのマークアップ言語 SCRIBE 。
  • XML はより一般化されているが、それも 60年代初頭に LISP が実現している。
  • Linux はほとんど 1970年の Unix だが、多くのプログラマにとって今まさに「ホットなもの」である。
  • オーバーラッピングウインドウなどの UI は、70年代になってから生じたアイデアなので例外的。
  • しかし他のほとんどは 60年代のもの。
  • 新しい技術が受け入れられるのに必要なタイムラグは 30年ほどだと分かる。とくにビジネスの分野では。
  • けれども、Squeak Smalltalk システムで使われている方式や実践は 70年代半ばに形作られたもの。
  • まだ 30年経過していない。
  • （Smalltalk と似たところもある）ピアツーピア・コンピューティングも同時期。
  • これらのようにインターネットのようなしくみで動作するコンピュータシステムはまだあまり作られていない。
  • 《この“30年ラグ説”は冗談のたぐいだが、これまでの史実とはおもしろいように合致する》
  • 大事なことは、ごく少数とはいえ、この新しいソフトウエア開発手法を 25年以上にわたって経験している者たちがいるということ。
  • つまり、もはや思索の段階を終えて久しく、今や知識や実践例の体系をなしている。
  • こうした事実は、携わる（ごく少数の）人間には、新しい手法の「現実感」をより確かなものにさせ、
    • たとえばデスクトップパブリッシングシステムのようなものを従来の手法と、新しい手法で作り分けてみることをしたり、
    • その結果、動的結合でなら、20分の１程度の小ささで、ずっと少ない人月で作ることができる理由の答えを得ることができたりする。
    • and yet still runs faster than human nervous systems at highly acceptable speeds.
  • （他の）大多数のプログラマには、新しい手法を学ぶ動機付けや、いずれは要求となるだろう。

â–¼ What is it like to learn the new ideas?

  • このような柔軟な装置は、どの程度、複雑なものであるべきか。
  • 文法的には複雑である必要はなさそう。
  • 「主語 å‹•è©ž 目的語」で事足りる。
  • オブジェクトの世界では、「主語」がメッセージレシーバで、残りの「動詞 目的語」がメッセージ。
  • 重要なのは、こうしたシンプルな約束にしておけば、簡単に新しい表現を読みやすく作れること。
  • ユーザーは文法とセマンティックスの対応を一対一に保つことができる。
  • （メッセージの意味はレシーバが把握している）
  • レシーバたちはちょうどピアツーピア・ネットワークのサーバーのように見なし扱う。
  • 《この一致は偶然ではない。》
  • ダイナミックなＯＯＰでは、相互にコミュニケートするオブジェクトを前提にシステムを設計し構築する。
  • オブジェクトシステムが、オブジェクトのみから成り、オブジェクト自身もオブジェクトの入れ子構造でできているなら、我々はこのシステムの構造上の必要とされる知識をすべて得ていることになる。
  • オブジェクトの内面は、振る舞い。
  • 振る舞いは「役割」や「観念」としてひとまとめに扱える。
    • 「表示されるもの」という役割
    • 「他のオブジェクトのコンテナやキャリヤ」という役割
    • 「基本的なオブジェクト」という役割
  • 役割はシステム内での使われ方によっては特異的なものになる。
  • 子供やプログラマでない人たちには、このスタイルのプログラミングは学びやすいはず。
    • 馴染みの文法。馴染みの世界観。
  • オブジェクトは、しかるべき振る舞いで体現される役割を持ち、他のオブジェクトの集まりとして構成される。
  • コンピュータの画面を見て欲しい。
  • すべてオブジェクトという単一の部品で構成できることに気付くはずだ。
  • これはすべてエンドユーザーの視点（で完結する）。
  • それなのに、なぜソフトウエアはこう複雑なものになるのか。
  • 原因の一部は、人間の神経系の特性。
    • 類似性よりは差異のほうに強く反応する。
    • it is similarities that create small descriptions for seemingly large complex systems.
  • 差異（へのこだわり）は多くの不必要な特例を生じさせ、それらはトラブルの元となる。
  • 「類似性」（への着目）は、代数学に通じる。
    • it unifies many seemingly different relationships under a single rubric which represents all.
  • Squeak のようなダイナミックなオブジェクトシステムを 60年代に考案したとき、代数学的要素を持つことを予見していた。
    • オブジェクトの再帰的構造が、少ないもので多くを成せる能力を説明する。
  • 代数学的な知見は、古いスタイルの静的結合の日常のプログラミングでは得られにくい。
  • ほとんどのプログラマはまだ気づいていない。
  • 子供達はまた、並列という概念を扱うことができるので、
  • オブジェクトの協調による並列のイベント駆動型のシステムを書くことができる。
  • それは小さくシンプルなプログラムになる。
  • 一方で、多くのプログラマは「アルゴリズムとデータ構造」から学習を始める。
  • これは子供達とは逆、つまりシーケンシャルで非オブジェクトな面を助長する。
  • これは弱い受け身のデータを「神がごとく」コントロールしようとする手法。
    • こうしたやり方はスケールしない。
  • 私は（こうした「神がごとき」手法をいったん身につけてしまった）多くのプログラマが、後から「神ではない」視点やオブジェクトの視点を理解するのは非常に難しいと考える。
  • 私の友人で同僚のリードは、
    • 《彼は TCP/IP の / のような人で、TCP と IP という二つのプロトコルを取り持つ仕事をした》
  • ARPA ã‚„ ODR、PARC には certain odd humbleness があったとよく指摘する。
  • 彼らは本当に大きな数々の難題に対し、謙虚な姿勢で対応した。
  • 彼らは自分たちが「ごり押し」や「神のごとき」手法でこれらの問題を解決する能力を持たないことを分かっていて、
  • 代わりに各問題を finesse する方法を探した。

â–¼ Architecture Dominates Materials

  • 時計と同じ程度の単純なものなら作ることも、それが壊れたときに直すことも容易だ。
  • しかし巨大なシステムでは、その成長や変化に際して be negotiated with が必要になる。
  • それは生物的であり、巨大なシステムは生態系のような振る舞いをみせる。単純な歯車の噛み合わせで動くシステムというよりは。
  • Squeak のようなシンプルでパワフルなシステムでは、
    • システムとは何かを深く考えたり
    • ごり押しせずに物事を進める方法を考えることを学べる。
  • 前者は、早い次点で物事を見通す力となり。
  • 後者は、人間のいたらなさと（それを補う）メタな思考の必要性を見通す力となる。