不満を増大するように思いました。100行で風変わりに思える書式が、1,000の刺をもってしても通り抜けられない生け垣に見えてきました。それはちょっとした風味と表情の豊かさに見えますが、大きなコードを見据えて一貫したスタイルを維持するのに苦労します。)は脆く、貧弱な感がありました。大きなコードはほんの数日でも目を通さなければこれらの問題が結びついて読むことをさらに難しくさせます。私はアプリケーションの問題よりもこの言語と格闘する時間に多くを費やしていることに気付きました。すべてのうちで最も罪を免れないことは醜いコードを生み出すということです--これは大問題です。醜いプログラムは危険な吊り橋のようです:これらはきれいな物より崩壊しやすいです。人間(特に技術屋)が美を知覚する方法と、我々が複雑さを処理して理解する能力は親密な関係にあるからです。エレガントなコードを書くことがやっかいな言語は、良いコードを書くことをも困難にします。私が携えている2ダースの言語の基準となっているサインはその言語の設計であると発見しました。1997年の中頃、"よりよい方法がなければならない"と思って、より上品なスクリプト言語をあちこちに捜し始めました。戻ることは考慮しませんでした。新しいプログラムにおいて自分自身でメモリを管理することに意味をなす時代は終わっていました。--例外としてカーネルハッキングや科学技術計算、3Dグラフィックスのような専門領域ではハードウェアを最大限活かすためにメモリの使用により最高速度と厳しいコントロールが絶対的に要求されます。よるメモリ・リークなど、その他関連する全ての問題を今日のマシン上でデバッグするオーバーヘッド(負荷)には気が狂いそうです。スクリプト言語のメモリ管理のオーバーヘッド(無駄)に対して少数のサイクルと数キロバイトのメモリを交換して、人間の貴重な時間を節約する方が賢明です。爆発的な成長を促したのです。貧弱であることを発見しました。私は古くからのリスパー(LISPer)です。歴史は相変わらずで、設計は良くてもドキュメントが無かったり、POSIX/UNIXの機能へのアクセスが不完全なのです。深く断片化したユーザーコミュニティーによってほとんど役立たずにされていました。悪いか、理論上は優れているけれども役に立つものであるとは言い難いものなのです。見たのは初めての時と同じように偶然からでした。設定ファイルに関する問題が増大していることをエンド・ユーザー達が明らかにしてくれました。アカウントを持っているとぞっとするぐらい複雑になってしまいます。書いて問題の対処にあたりました。インターフェースに置き換えて完全に隠してコントロールすることです。私の興味をひかなかったです。コードよりさらに醜いようでした。ここで私が6ヶ月以上前に計画したことを覚えていたのがポイントです。実地経験の機会を得たことだったのです。インデントの重要性に再び直面しました。要素の一握りのサンプルを描いたのです。インデントの使用が不自然に感じなくなりました。プログラムのインデントのように、コードを単にインデントしてやるとそれはうまくいったのです。これが第一の驚きです。次に、2,3時間プロジェクトのために作業してみました。Pythonで新しい特徴を探すために手を休めましたが)普段タイプするのと同じくらい速くコードを生成できるのです。これを悟ったときには本当にビックリしました。コーディングしてみることはとても重要な努力です。タイプするものはあなたが思ったことを言葉にするようにはうまくいかないでしょうが、問題の考えと一致しなくても立ち返り繰り返すのです。すぐれた言語設計を知る手段として、言語の経験を得ると同時にこの種の失敗の割合が急速に減少するかを測ってみることなのです。一般的に、タイプするのと同じように速くコードを書くことが出来てそして失敗率がほぼゼロに近づいたならばそれは言語への熟成を達成したことを意味します。私はそれにはうなずきませんでした。最初の手掛かりとなりました。ほとんどの言語は先に挙げた失敗率が下がるよりも前に沢山の関数のセットを覚えなければならない摩擦と不器用さを組み込んでいます。私が今まで使った汎用言語のうちでこのプロセスを逆にした初めての言語でした。私が関数のセットを学ぶのに多くの時間を費やしたという意味ではありません。そのものを学ぶために費やしたと思います。この事は他の特性を反映しているのです:コンパクトなのです--あなたは頭の中で関数のセット(と少なくともライブラリの概念の索引)を記憶しておけるのです。素晴らしくコンパクトな言語です。簡潔さを「実現するひとつ以上の道がある!」けれども可能性にとどまっています。発見の劇的な瞬間が待ち受けていました。アクションから簡単に設定ファイルを作成することが出来ましたが、編集するのがとても難しかったのです。言い換えれば、編集可能なようにフォームへ読み込むことが問題だったのです。設定ファイルの書式を解析するプログラムはかなり手の込んだものでした。言語を解析するコードを生成します。複製する必要があると思いました。これには気がすすまなかったのです。その理由のひとつは作業の複雑さ、もうひとつは2つの異なった言語の解析プログラムが同じように動作するか確証がなかったからです。最後に、私が書いた解析プログラムが発展していたので、2つの解析プログラムを同時に入れておくことが余分なことだったからです!この問題には悩まされました。オプションを加えました。イニシャライザでフォーマットして標準出力にダンプします。見ることが出来ます(スペースを節約するために、参考例に関連していないデータは省略されています)。出力を評価できるようになりました。値として設定を利用できるようにしたのです。ここでもまだダンスの最後のステップに到達したわけではありません。現存の設定ファイルを持たないことでした。オブジェクトのツリーへリンクを貼ることではないのです。(サイトに添付されるユーザーを表す)。例に挙げたファイルには5つのサイト・オブジェクトと、サイトそれぞれに添付されるユーザー・オブジェクトが書いてあります。私は早々と3つのオブジェクト・クラスを設計して書きました(この作業には4日かかりました。そのほとんどはウィジェットのレイアウトに費やしました。編集パネルがポップアップするよう、それぞれのメソッドを持っています。イニシャライザを使って死んだデータを本物のオブジェクトへ変換させることでした。3つのクラスすべてがその構造と仕様に関して明快に区別できるようにイニシャライザを通して調和するオブジェクトを作成するようなコードを書くように考えました。言語が成長するとともに時が経つにつれてクラスのメンバが加えられそうだったのでその考えを捨てました。当たり前のようにオブジェクトを作成するコードを書いていたら、こわれやすく、そしてクラス定義やイニシャライザの構造のどちらかが変化したときに同時性を損なう傾向があるでしょう。私が何を望んだかというと、イニシャライザの型とメンバを分析し、それらのメンバについてクラス定義自体に疑いをかけ、そして2つのセットとインピーダンスマッチそのものを調整するコードでした。この種の考えはメタクラス・ハッキングと呼ばれ、一般的には恐ろしいほどの奥義であると考えられています--神秘的な黒魔術。)、かなり込み入っていて壊れやすい仕事なので注意が必要です。低い不和率に感動させられましたが、ここに本当のテストが待ち構えていました。メタクラス・ハッキングのためにどのくらい熱心に私はこの言語と格闘する必要があるのでしょうか?勝ったと仮定しても以前の経験からこの勝負は苦しくなることは解っていました。メタクラス機能を研究したのです。