Is “Software Engineering” an Oxymoron? By Alan Kay
(訳注: 以下の文章は、http://d.hatena.ne.jp/sumim/20080806/p1 に紹介されていたアラン・ケイの文章 -- Is “Software Engineering” an Oxymoron? -- を訳したものです。原文もsumim さんのサイトからダウンロードしました。最初に書かれたのは 1999年から2000年ごろと少し古いので注意してください。日本語で矛盾語法(oxymoron)とは聞き慣れない言葉ですが、ジーニアス英和大辞典によると an open secret (公然の秘密) や、living death (生き地獄) のような矛盾する二つの単語を組み合わせた熟語の事を言うらしいです。)
真のソフトウェア工学はまだ未来のものだ。一年とかけずに三千人以下でエンパイアステートビルを造り上げるようなものは、現在のソフトウェア工学に存在しない。彼らはソフトウェア開発にはまだ無い強力なアイデアと道具を使った。もしもソフトウェアが何らかの工学を行うとしても、大抵はアーチの発明以前(文字通りアーチづくり、アーキテクチャ以前と言える)の古代エジプトと同じようなレベルにしかならない。劣悪な知識と工具しか持たず、何十万もの奴隷を何十年も使い石に石を重ねてゆく様は、まさに今日ほとんどのソフトウェア開発で行われている事だ。
Real Software Engineering is still in the future. There is nothing in current SE that is like the construction of the Empire State building in less than a year by less than 3000 people: they used powerful ideas and power tools that we don’t yet have in software development. If software does “engineering” at all, it is too often at the same level as the ancient Egyptians before the invention of the arch (literally before the making of arches: architecture), who made large structures with hundreds of thousands of slaves toiling for decades to pile stone upon stone: they used weak ideas and weak tools, pretty much like most software development today.
(古代エジプトとエンパイアステートビルの間に何か強力で値打ちのあるものはあるだろうか？)
Is there anything worthwhile and powerful between the ancient Egyptians and the Empire State Building?
本当の疑問は、この二つの間に、真に近代的なソフトウェアの為の工学プロセスとなり得る技法 -- 二つのものを積み上げる以上のもの -- があるだろうかという事だ。
The real question is whether there exists a practice in between the two —- stronger than just piling up messes —- that can eventually lead us to real modern engineering processes for software.
この現在のジレンマを特徴づける一つの見方として、たとえ同じような目的を持つプロジェクトでも、毎回必要以上に大きな学習曲線が必要になるという事がある。一つの原因はわたしたちがまだソフトウェアについて必要な事がまだ分かっていないからだろう。しかし Butler Lampson が指摘しているのは、ムーアの法則によって年々新しく大きな要求が生まれ質的に違う環境に置かれるため、同じようなプロジェクトであっても全く違ったものになるという点だ。
One of the ways to characterize the current dilemma is that every project we do, even those with seemingly similar goals has a much larger learning curve than it should. This is partly because we don’t yet know what we really need to know about software. But as Butler Lampson has pointed out, this is also partly because Moore’s Law gives us a qualitatively different environment with new and larger requirements every few years, so that projects with similar goals are quite different.
(訳注: あとで直すのは高く付くというテレビコマーシャルより)
The Fram oil filter principle
プロジェクト設計時に知っていれば良かった事がプロジェクト期間中に明らかになる事は大変良くある。今日において、より素早い開発と高い成功の鍵となるのはこのような新しい知識で行われるものだ。「エジプト的」ソフトウェアシステムでは、もしもシステムの基礎に基本的に新しい方法を採用しようとすればかなり最初からやり直さなくてはならない。これは大変な工数を要するため、一般的には行われない。
Very often during a project we’ll find out something that we wished we’d known when designing the project. Today, much of the key to more rapid construction and higher success is what we do with this new knowledge. In the ”Egyptian” SW systems, we pretty much have to start over if we find a basic new way to deal with the foundation of our system. This is so much work that it is generally not done.
同じような不吉な話を挙げると、ソフトウェアシステムにおいて全コストの85% は成功裏に導入された後で必要になる。コストのおおまかな内容は、新しい要求に応える為の変更、後で発見されるバグ等だ。前もって適切であったり節約に見えていた事でさえ、後々実際の大きなライフサイクルを視野に入れると、結局費用が指数関数的にかさむ羽目になる。
Something quite similar obtains in the ominous fact that 85% of the total cost of a SW system is incurred after it has been successfully installed. The bulk of the cost comes from the changes needed from new requirements, late bugs, and so forth. What seemed expedient and cost saving early on, winds up costing exponentially more when the actual larger life cycle picture is taken into account.
Late binding
真のソフトウェア工学が開発されるまでの次善の策は、あらゆる要素について極端に遅延結合な動的システムを使って開発する事だ。これを重要な部分で実際に行ったのは LISP が最初だ。そして沢山の偉大なアイデアは、70 年代の初期に XEROX PARC で Squeak の祖先である Smalltalk -- 最初の完全にオブジェクト指向な開発操作環境 -- の発明にも使われた。Squeak はこの遅延結合をさらに押し進めたものだ。
Until real software engineering is developed, the next best practice is to develop with a dynamic system that has extreme late binding in all aspects. The first system to really do this in an important way was LISP, and many of its great ideas were used in the invention of Squeak’s ancestor Smalltalk -- the first dynamic completely object-oriented development and operating environment -- in the early 70s at Xerox PARC. Squeak goes much further in its approach to latebinding.
(早期結合なシステム(C, C++, Java 等)と比較して、遅延結合を使う事で、プロジェクト開発の遅い時期に得られた知見を指数関数的に少ない工数でプロジェクトに適用出来る。)
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.)
鍵となるアイデアは、試験中や、特に変更中にシステムを走らせておく事だ。たとえ大きな変更であっても少しずつ秒に満たない時間で更新されるべきだ。危険な変更などから穏やかに回復できるよう様々な種類の「取り消し」機能が必要とされる。
One key idea is to keep the system running while testing and especially while making changes. Even major changes should be incremental and take no more than a fraction of a second to effect. Various forms of “undo” need to be supplied to allow graceful recovery from dangerous changes, etc.
もうひとつの鍵は、一般的なメモリ割当とガベジコレクタで、効率よく実時間で働く(アニメーションや動的なメディアが GC 中に再生出来るように)だけでなく、オブジェクトの再構成が安全に行われる必要がある。例えば、あなたのプロジェクトを一年以上続けていて、沢山の大切な物が出来上がっているとする。システムを破壊せずに、何万もの動いているオブジェクトがあるクラスにいくつかのインスタンス変数を追加して、動的にそれらを再構成する事は出来るだろうか? Squeak ならいつもやっている事だ。なぜならメモリ割当は遅延結合のために作られ、実時間性能にも優れているからだ。
Another key idea is to have a generalized storage allocator and garbage collector that is not only efficient in real- time (so that animations and dynamic media of many kinds can be played while the gc is collecting), but that allows reshaping of objects to be done safely. For example, you have been working on your project for more than a year, and many important things have been built. Can you add several instance variables to a key class that has hundreds of thousands of working instances and have these reshaped on-the-fly without crashing the system? In Squeak this is done all the time, because its storage allocation system was designed for late-bound reshaping, as well as good realtime performance.
Modeling and models of all ideas
極端なアイデアを挙げると、開発システムをそれ自体のモデルにさせて、開発中に新しいアイデアとして進化させる事がある。これには UI ウィジェットのような普通のツールだけでなく、システムのメタ構造になるようなものも含まれる。インスタンスそのものはどのように作られるだろうか? 変数は実のところどうか? 簡単に様々な継承構造の記法を実現出来るか? クラスがプロトタイププロトタイプがクラスよりも上手く働くかどうか決定して、プロトタイプベースの設計に移動する事が出来るだろうか?
A radical key idea is to make the development system have a model of itself so that it can be extended as new ideas occur during development. This means that there are not only classes for workaday tools, such as UI widgets, but there are also classes that represent the metastructure of the system itself. How are instances themselves made? What is a variable really? Can we easily install a very different notion of inheritance? Can we decide that prototypes are going to work better for us than classes, and move to a prototype-based design?
基本的な構成要素のモデル化を拡張すると、より大きな機能をシミュレートしモデル化する事になる。例えば、Squeak バーチャルマシンの仕様は紙の文書によっては記述されていない(机上の確認だけで 1/2 ページの紙の仕様書を書けるのかという事すらあやしい)。その代わりに、Squeak VM の仕様はSqueak の上で走り、デバッグされる生きたシミュレーションモデルとして存在している。FM 音源シンセサイザのような新しい機能は、C 等の低レベル言語では無く、VM 仕様の為の一つのモジュールとして Squeak 自体の中で新しいプロセスをモデル化する事で作られる。これは高い Squeak レベルでデバッグされる(実際には、VM シミュレータは十分に速いのでリアルタイムに 3, 4 の音源を制御出来る)。次に数学的な変換によって高レベルのモデルから Squeak が走る数多くのプラットフォーム用コードへと確実に変換される。更なる変更もこの VM シミュレータ上に実装され、「生きた仕様」の一部となり、上に記したように変換されてゆく。
An extension of modeling basic building blocks is to also model and simulate larger facilities. For example, the Squeak Virtual Machine specification is not represented as a paper document (it’s not even clear that a 1/2 page paper specification could be made without error just by desk checking). Instead, the Squeak VM specification is represented as a working simulation model within itself that can be run and debugged. New facilities, such as adding FM musical synthesis are not created by writing in C or other lower level languages, but by modeling the new processes in Squeak itself as a module for the VM specification. This is debugged at the high Squeak level (in fact, the VM simulator is still fast enough to run 3 or 4 separate real-time voices). Then a mathematical translator is brought to bear which can make a guaranteed translation from the high level model to low-level code that will run on the two dozen or so platforms Squeak runs on. Further changes are implemented in the VM simulator and become part of the “living spec”, then translated as described above, etc.
Fewer features, more meta
もしもわたしたちがソフトウェアの書き方を本当に分かっていたら、システム開発の以前に全ての必要な機能を定義出来るという現在の(悪い)前提だけで十分だっただろう。しかし実際そんな事はまだ分からないので、機能満載の大規模設計の正反対であり、「機能なし」か、もっと良い言い方をすると「ほとんどメタ」のシステムが必要になる。残念ながら、現在のほとんどのソフトウェアは機能満載言語で書かれるのでこういったものには対応出来ない。そして必要な拡張は不可能だ。その原因の一端は無知にあり、また、困難さにある。
If we really knew how to write software, then the current (wrong) assumption that we can define all needed features ahead of time in our development system would be sufficient. But since we don’t really know how to do it yet, what we need is just the opposite of a feature-laden design-heavy development system: we need one “without features”, or perhaps a better way to say this is that we need a system whose features are “mostly meta”. Unfortunately, most software today is written in feature-laden languages that don’t cover the space, and the needed extensions are not done: partially from ignorance and partially from difficulty.
例えば、C++ はエキスパートプログラマの為に作られたものだが、この業界では一般的に初心者に使われている。例としては「new」をオーバーライドすることによって(真に優れたプログラマによって)本当に素晴らしい記憶割当システムを書く事が出来る。同じように、テンプレートもまたエキスパートによってオーバーライドされる事を意図したものだ。多くのプログラマが C++ のテンプレートの本来の使い方を活用しないで、ただ与えられたままに使っている事は C++ の開発者である Bjarne Stroustroup のフラストレーションの元になっている。これは常に、大きく、遅く、不安定で、巨大なメンテナンスを必要とする構造を引き起こしてしまう。これは彼の意図したところではない!
For example, C++ is actually set up for truly expert programmers, but is generally used by non-experts in the field. E.g. “new” can be overridden and a really great storage allocation system can be written (by a really great programmer). Similarly other features intended as templates for experts can be overridden. It is a source of frustration to Bjarne Stroustroup, the inventor of C++, that most programmers don’t take advantage of the template nature of C++, but instead use it as a given. This usually leads to very large, slow, and fragile structures which require an enormous amount of maintenance. This was not what he intended!
Squeak は深いメタシステムと初期機能(大変能率的な実時間インクリメンタルガベジコレクタと沢山のメディアクラス等)を達成する事によって別の道を歩んでいる。これは様々な場合に鍵となるシステムを素早く開発するために役立っている。一方で、深い拡張が必要になる場合もあって、多くのプログラマは与えられた沢山の機構を使いこなせないでいる。このような能力不足はどちらの言語にとっても損失だ。
Squeak takes a different route by supplying both a deeper meta system and more worked out initial facilities (such as a really good real-time incremental garbage collector and many media classes, etc.). In many cases, this allows very quick development of key systems. However, it is also the case that when deep extensions are needed, many programmers will simply not take advantage of the many mechanisms for change provided. The lack of metaskills hurts in both languages.
今日のソフトウェアが抱える問題の一部は、多くのプログラマが表面的な少しのプログラムを、しかも早期結合なシステムでしか習わない事だ。彼らはメタプログラミングをほとんど(または全く)習わない -- メタプログラミングこそソフトウェアの混乱から抜け出す大切な鍵の一つなのに関わらず。
Part of the real problem of today’s software is that most programmers have learned to program only a little, at the surface level, and usually in an early bound system. They have learned very little (or nothing) about how to metaprogram —- even though metaprogramming is one of the main keys today for getting out of software’s current mess.
(訳注: calculus は「計算法」のように訳されますが、メタ数学を含む広い意味で使ったそうなので「数学」としました。)
What are the tradeoffs of learning “calculus”?
Squeak を学ぶ上で鍵となるのは同じメカニズムの作り方や日常的なプログラムのための文法を学ぶだけではなく(訳注: 同じメカニズムの作り方 the equivalent mechanisms とは、Squeak に最初から存在する変数や制御機構など組み込みの機能だけでなく、メタ機能によって同じものをユーザが作れるという事を意味しています) 、システムに生かすためにはどう新しいアイデアを使ってどう必要なものを再構成するかを学ぶ事だ。ちょうど良い比喩として、Squeak をある種の数学として見てみよう。この数学は単に代数や幾何学を改良したものではない。なぜなら数学的関係についての新しく、広く、もっと強力な考える方法を導くからだ。ほとんどの人にとって、一ヶ月で数学の力を得るのは難しいだろう。しかしそれを使えば、沢山の人が一年間のうちにいくつかの力をちゃんと使えるようになる。
Part of the key to learning Squeak is not just to learn the equivalent mechanisms and syntax for workaday programs, but to learn how to take new ideas and reformulate whatever is necessary to empower the system with them. An analogy that works pretty well is to view Squeak as a new kind of calculus. The calculus is not the same as simply a better algebra or geometry, because it actually brings with it new and vastly more powerful ways of thinking about mathematical relationships. Most people will not get powerful in calculus in a month, but many can get a very good handle on some of the powers in a year if they work at it.
百年前の土木技師は、沢山の素材(何も無い空間もふくむような)の歪みや圧力、湾曲について解析しシミュレートするためのテンソル解析という大変美しい算術について学ぶ必要が無かった。しかし五十年も前には全ての土木技師が真の技術者と見なされるためにこの新しい数学を身につけなければいけなくなっていた。Squeak の中にある沢山の強力で風変わりなアイデアもテンソル解析のようなものだ(より易しいと思うが)。これはその力にも関わらず現在の実践の一部ではないが、遠くない将来には含まれるようになるだろう。
One hundred years ago structural engineers did not have to learn the powerful form of calculus called Tensor Calculus, a very beautiful new mathematics that allows distortions, stresses and strains of many different materials (including seemingly empty space) to be analyzed and simulated. But, by 50 years ago, all structural engineers had to get fluent in this new math to be certified as a real engineer. Many of the most powerful and different ideas in Squeak are like those in Tensor Calculus (though easier, we think). They are not part of current practice in spite of their power, but will be not too far in the future.
Most of current practice today was invented in the 60s
この広い世界において、いかに吸収と需要のペースが遅いかは特筆に値する。C から C++ に追加されたものは、大まかに言って 1965 年に Algol から Simla に成されたものだ。Java も大変似ている。マウスとハイパーリンクは六十年代初期に発明された。HTML は六十年代後期の SCRIBE のようなマークアップ言語だ。XML はさらに一般化されているが、六十年代に LISP のしたものの別記法だ。Linux は基本的に Unix で、1970 年に由来するが多くのプログラマにとって未だ「熱い話題」である。オーバーラッピングウインドウ UI は七十年代に生まれ現在引き継がれたものの中のうちで数少ない一つだ。しかし現在プログラマが使うシステム上のアイデアはほとんど六十年代のデータ中心、サーバ中心の世界から来たものだ。
It is worth noting the slow pace of assimilation and acceptance in the larger world. C++ was made by doing to C roughly what was done to Algol in 1965 to make Simula. Java is very similar. The mouse and hyper-linking were invented in the early sixties. HTML is a markup language like SCRIBE of the late 60s. XML is a more generalized notation, but just does notationally what LISP did in the 60s. Linux is basically Unix, which dates from 1970, yet is now the “hottest thing” for many programmers. Overlapping window UIs are one of the few ideas from the seventies that has been adopted today. But most of the systems ideas that programmers use today are from the data- and server-centric world of the 60s.
この採用の遅れはプログラミングのより大きな世界、特にビジネス界で大体三十年くらいに見える。しかし現在わたしたちの知るように Squeak の実践と形式は七十年代中盤に開発され、まだ三十年の遅れを満たしていない。ピアツーピアコンピューティングもまた ARPA/PARC コミュニティで同じ頃開発されたが狭い環境で実験的に使われているだけだ。インターネットが動くようなやり方でシステムを構築する等という事もまだ現在実践されていない(この「三十年遅れ説」を一般化するのは冗談めいた見方かもしれないが、今の所驚くべきほど真実味がある)。
The lag of adoption seems to be about 30 years for the larger world of programming, especially in business. However, the form and practice of Squeak as we know it today was developed in the mid70s and has not yet had its 30-year lag play out. Peer-peer computing was also developed by the ARPA/PARC community around the same period and is just being experimented with in limited ways. Building systems that work the way the Internet works is not yet part of current practice, etc. (This general observation about the “30 year lag” could be facetious, but it seems amazingly true to history so far.)
おそらく、Squeak のような新しい種類のソフトウェア開発にとっての大切な事は、あるコンピュータ科学者の小さなグループが二十五年以上かけて極めてささやかな経験を得て来たという事だ。したがって六十年代後期の哲学的憶測などではもはや無く、その代わり広く様々な動的なコンピュータ構造についての知識と実例の実体が今や存在する。この事実は実践的である事を誇りとしている人々にとって新しい方法をもっと「現実的」にさせる。例えば、デスクトップパグリッシングを一般化するような実用的なシステムを(訳注: 静的な世界と動的な世界の)二つの世界で評価されうるし、その答えがなぜ Squeak のようなレイトバインディングなものが二十倍も小さく、開発に少ない人月しかかけずに、それでも高くまずまずの速度で人間の知覚よりも速く走るのかという疑問に応える事が出来るだろう。この事は、より数多くのプログラマがこの「新しい」手段で考え、作る方法を学ぶ事を動機づけ、さらには必須となるきっかけになるだろう。
Perhaps the most important fact about the new kind of software development as exemplified by Squeak is that a small group of computer scientists have gained quite a bit of experience over the last 25+ years. Thus these are no longer the philosophical speculations of the late sixties, but instead are now a body of knowledge and examples about a wide variety of dynamic computing structures. This makes these new ways much more “real” for those who pride themselves on being practical. For example, a paradigmatic system such as generalized desktop publishing can be examined in both worlds, and some answers can be given about why the late bound one in Squeak is more than 20 times smaller, took even less fractional person-time to create, and yet still runs faster than human nervous systems at highly acceptable speeds. This will start to motivate and eventually require more programmers to learn how to think and make in these “new” ways.
What is it like to learn the new ideas?
このような柔軟な機能はどれだけ複雑である必要があるだろうか? 文法上は決して複雑で無くてもよい。なじみ深い英語の語順である主語、動詞、目的語(よく前置詞や、たまに暗黙の主語を伴う)があれば全く十分だ。オブジェクト指向の言い方で言うと、主語はメッセージのレシーバであり、文の残りはメッセージだ(ここでは「動詞」を強調して書く)。これで次のような読みやすい形式になる。
How complex does such a flexible facility have to be? It certainly doesn’t have to be complex syntactically. The familiar English word order of Subject Verb Object (often with prepositions and sometimes with an implied subject) is quite sufficient. In object terms, the Subject is the receiver of the message, and the rest of the sentence is the message (we’ll mark the “verb” by darkening it). This allows readable forms such as:
3
‘this is some text’
pen up
3 + 4
3 * ( 4 + 5 )
car forward by 5
{1 2 3 4 5 6 7} collect [ n | n odd ]
Repeat (1 to 100 by 2) do [ ******* ]
そして大切なのは、この単純な決まりに従って必要なだけ新しく読みやすい記法を作る事が出来る事だ。
And, just as important, these simple conventions allow us to make up new readable forms as we find needs for them.
これは、ユーザが文法と意味の関係を一つだけ念頭に置いておけば良い事を意味する。
This means that a user only has to think of one syntax-semantic relationship.
レシーバ メッセージ -- レシーバが意味を把握している事を意味する。
Receiver message means the meaning is in the receiver
という事で、オブジェクトはただネットワーク上のピア・ピア・サーバのように考えられ、使われると考える。(これは偶然ではなく、六十年代後期におけるARPAnet から Internet にかけての開発にさかのぼるアイデアを起源とする)。
thus objects are thought of and used just like peer-peer servers on a network. (This is not a coincidence and the origin of this idea dates back to the development of the ARPAnet -> Internet in the late sixties).
従って、動的なオブジェクト指向プログラミングを行うという事は通信しあうオブジェクトでシステムを設計し構築する事になる。もしもわたしたちのオブジェクトシステムの内部がそれ自体オブジェクトから出来ているとすれば、必要な構造上の知識は全て知っている事になる。
Thus what we are doing with dynamic object-oriented programming is to design and build a system made of intercommunicating objects. If our object system allows the interiors of all objects to be themselves made from objects, then we have learned all of the structural knowledge needed.
内部構造はオブジェクトの振る舞いの性質を反映したものになり得る。ある部分は他の部分よりより動的だろう。このような振る舞いは「役割」としてグループ化出来る(「観点」の言葉がよりよい時もある)。そういった役割には、「このオブジェクトは可視的な画像要素だ」や、「このオブジェクトは他のオブジェクトを運搬する/格納する」や、「このオブジェクトは基本オブジェクトだ」などがありうる。あるシステムの特別な使い方に特有な役割があるかもしれない。例えば、UI のスライダウィジェットとしての特別な役割があり得るだろう。
The interiors can be portrayed as views of the behavioral properties of the object, some of which are more dynamic than others. These behaviors can be grouped into “roles” (sometimes “perspectives” is a good term to use). One role could be “the object as a visible graphical entity”. Another role could be “the object as a carrier/container of other objects”. A third role could be “the object as a basic object”. There might be roles that are idiosyncratic to the object’s use in some system. For example, the object could have a special role as a slider widget in a UI.
これが、子供や非プログラマにとって特に学びやすいプログラミング方法に見える理由だ。つまり、親しみやすい文法を使い、オブジェクトがお互いに作用し合うという親しみやすい世界の見方を持っている。オブジェクトは役割から成り、役割は関係する振る舞いの集合で、それら全てがオブジェクトである。
This is why children and nonprogrammers find this style of programming so particularly easy to learn: it uses a familiar syntax, and has a familiar view of the world, as objects that interact with each other. The objects are made from roles that themselves are collections of relevant behaviors, themselves in terms of objects.
あなたのコンピュータのスクリーンを見てみよう。するとそこにはたった一種類のオブジェクトしか無い事に(驚きを持って)気づくだろう。それは空間を色分けする領域から成るコスチュームによって表現され、ユーザの動作を扱い、他の同じようなオブジェクトと作用し、他の同じようなオブジェクトを運搬し、それ自体が一部分として特別な劇場効果を担っているかもしれない。これらそこにあるものがすべてエンドユーザの視点から来ている。それではなぜソフトウェアはこうも複雑なのか? その一つの答えは、普通人間の神経系は類似ではなく差異に惹き付けられるが、類似こそが一見大きく複雑に見えるシステムにある小さな特徴を作り出すものだからだ。差異は時間が経つにつれ問題を引き起こす不必要な沢山の特別ケースを頻繁に生み出してしまう。
Look at the screen of your computer and realize (perhaps with a shock) that there is really only one kind of object that you are dealing with: one that is represented by a costume consisting of colored regions of space, that can handle user actions, interact with other similar objects, carry similar objects, and may have a few special roles in the “theatrical presentation” of which it is a part. This is all there is from the end user’s perspective. Then why is software so complex? Part of the answer is that normal human nervous systems are attracted to differences, not similarities, and it is similarities that create small descriptions for seemingly large complex systems. Differences often lead to lots of needless special cases that cause increasingly more trouble as time marches on.
「類似」は数学では代数の仕事だ。代数は一見別々に見える関係を、全てを表現する一つの見出しにまとめあげる。六十年代にオブジェクトシステムが発明された時、代数的特徴を持ちうると分かっていた。そして単一で自己完結的な「オブジェクト性」の組み合わせであり、少しでも沢山の事を行うという能力の多くを説明するものこそが Squeak の代数的特徴である。この代数の可能性は普通の古いスタイルの早期結合な仕事をする日々のプログラミングの中ではまだ少しも明らかではない。これこそがほとんどのプログラマにとってこれからやってくるものだ。
“Similarities” are what an algebra does in mathematics: it unifies many seemingly different relationships under a single rubric which represents all. When dynamic object systems were invented in the 60s it was realized that they could have algebraic properties, and it is the algebraic nature of Squeak, combined with the uniform self-contained “objectness”, that accounts for quite a bit of its ability to do a lot with a little. The possibilities of algebra are not at all obvious in the normal old-style early-bound work of work-a-day programming. This is mostly yet to come for most programmers.
子供達はまた、長い一連の逐次的な論理よりも並列処理の方が得意なので、動的に相互作用する並列イベント式のシステムを書く事に喜んでなじむ。ここから小さく単純なプログラム群が生まれる。
Children are also able to deal with parallelism more easily than long strings of sequential logic, so they readily take to writing parallel event-driven systems that deal with interactions dynamically. This leads to small simple programs.
一方で、ほとんどのプログラマは逐次処理と非オブジェクトという正反対の事を強調する「アルゴリズムとデータ構造」コースで習い始める。これは弱い受け身の素材を制御する単純な一種の「神の視線」で、スケール出来ない。本当のシステム設計に必要とされる「普通の視線」の交渉と戦略を後から採用するのは多くのプログラマにとってとても難しいと思う。
On the other hand, most programmers learn their craft by starting with “algorithms and data structures” courses that emphasize just the opposite: sequential logic and nonobjects. This is a kind of simple “godlike” control of weak passive materials whose methods don’t scale. I think it is very hard for many programmers to later take the “nongod” view of negotiation and strategy from the object’s point of view that real systems designs require.
友人であり、同僚である Dave Reed (TCP と IP という二つのプロトコルを結びつけインターネットを形作るために重要な役割を果たしたTCP/IP における「/」のような人物)がよく指摘するのだが、今日のコンピュータ技術のほとんどを生み出したARPA, ONR そして PARC の創造者達には奇妙な謙虚さがあった。彼らは確かに本当に大きな問題に立ち向かうほどに傲慢であった - 停止も故障もないまま桁違いに成長する世界規模のネットワーク、全てのユーザの為のパーソナルコンピューティング、動的なオブジェクト指向システムによる設計、誰でも使えて大変安価なイーサネットのようなローカルエリアネットワークなどだ。しかしまたこれらの発明者たちも、これらの問題を直接ゴリ押しでは(「神」のようにという言い方も出来る)解決出来ないと感じる程度に賢明だった。その代わり、このような問題に対する巧妙な手口を見つけ出したのだ。兵術の前に策略を用い、失敗を回避せずに受け止める事だった。
My friend and colleague Dave Reed (whom I think of as the “/” in TCP/IP, because he was instrumental in creating the distinct roles for these two protocols that make the Internet work) likes to point out that there was a certain odd humbleness in the ARPA, ONR and PARC creators of most of today’s computer technologies. They certainly had the hubris to work on really large problems — such as a worldwide network that could grow by 10 orders of magnitude without having to be stopped or breaking, personal computing for all users, dynamic object oriented system building, a local area net like the Ethernet that is essentially foolproof and dirt cheap, etc. But it was also true that most of these inventors didn’t feel that they were smart enough to solve any of these problems directly with brute force (as “gods”, in other words). Instead they looked for ways to finesse the problems: strategies before tactics, embracing the fact of errors, instead of trying to eliminate them, etc.
Architecture Dominates Materials
短く言うと、あなたは何か時計のような単純なものを作り壊れたら直せる。しかし大きなシステムでは成長する際や、変化する際の擦り合わせが必要だ。これはより自然の生命の営みにも似て、大きなシステムは単純な歯車の機構よりも生態系のように振る舞う。
In short, you can make something as simple as a clock and fix it when it breaks. But large systems have to be negotiated with, both when they are grown, and when they are changed. This is more biological in nature, and large systems act more like ecologies than like simple gear meshing mechanisms.
そこで、Squeak のような単純で強力なものの秘密は、どうすればできるだけ深く「システムについて考えるか」であり、できるだけ頻繁に「謙虚に考えるか」である。前者は始めてみる際の良い見方だ。後者の方は、今までも今後も上手く行かない脆弱な逐次的アルゴリズムパラダイムの代わりに、人間の欠陥を扱う「メタ戦略」が必要になった時の良い見方だ。
So the trick with something as simple and powerful as Squeak is to learn how to “think systems” as deeply as possible, and to “think humble” as often as possible. The former is a good perspective for getting started. The latter is a good perspective for dealing with human inadequacies and the need for “metastrategic” processes rather than trying to scale fragile sequential algorithmic paradigms where they were never meant to go, and where they can’t go.
(一方で近代的な科学的工学が開発されている間にも、ある強力な建築の原理、例えば曲がったアーチ -- またはソフトウェアの動的な遅延結合オブジェクト-- を使うと、巨大で複雑な構造の設計と建設をてこ入れし加速できる。)
One powerful architectural principle, such as the vaulted arch -- or dynamic late bound objects in software -- can provide a boost into a much higher leverage practices for designing and building large complex structures while modern scientific engineering is still being developed