うーん、アウスターハウトの二項対立と結論には同意できないな。まず、彼のポイントの理解として - 言語はCのようなシステム言語か、TCLやPythonのようなスクリプト言語のどちらかだってこと。システム言語は「強い」型を持ち、データ構造やアルゴリズムに使われ、スクリプト言語は「型なし」で「ものをつなげる」ためのもの。主張は、スクリプト言語はより簡潔で、型なしの性質のおかげでつなげるのが早くできるってこと。彼の例では、Tclでボタンを作る。button .b -text Hello! -font {Times 16} -command {puts hello} 彼は続けて言う。「C++とMicrosoft Foundation Classes（MFC）では、3つの手続きで約25行のコードが必要です。フォントを設定するだけでもMFCでは数行のコードが必要です：CFont *fontPtr = new CFont(); fontPtr->CreateFont(16, 0, 0, 0, 700, 0, 0, 0, ANSI_CHARSET, OUT_DEFAULT_PRECIS, CLIP_DEFAULT_PRECIS, DEFAULT_QUALITY, DEFAULT_PITCH|FF_DONTCARE, “Times New Roman”); buttonPtr->SetFont(fontPtr); このコードの多くは強い型付けの結果です[...] Tclでは、フォントの本質的な特性（フォント名Times、サイズ16ポイント）を宣言や変換なしですぐに使える。さらに、Tclではボタンの動作をボタンを作成するコマンドに直接含めることができるが、C++やJavaでは別に宣言されたメソッドに置かなければならない。引用終了。私たちは長い道のりを歩んできたし、例はこの二項対立が間違っていることを明らかにしている。アウスターハウトの見解は彼の限られた経験に影響されていて、彼が実際にTclの何を好きなのかを誤解している。構文について話そう。彼が提示した正確なTclコードは、静的型解析を行う言語によって解析され、コンパイルされることができる。そうではないのは、彼が実行時にのみ型をチェックするインタープリタで実行しているからだ。でも、コードがコンパイルされるかインタープリタであるかは、構文とはほとんど関係のない実装の詳細だ。彼は自分の構文がC++より明らかに優れているから好きなだけで、それ以上のことはない。そして型について：彼は「型なし」言語が制約が少ないから開発が早くできると主張している。これは、もちろんナンセンスだ。制約の量は問題の関数であって、言語の関数ではない。動的型付けが開発を早くしているように感じるのは、制約に直面するのを後回しにしているからだ。プログラムが実行される前にすべての型エラーに遭遇することを保証するほうがいい。でも、どの言語でも静的型解析を行えるのに、なぜすべての言語がそれを行わないのか？それは難しいからだ。型理論は複雑だ。すべての型システムが決定可能なわけではないし、実用的な理由から決定可能なものを選ぶ必要がある。決定可能なものは、注釈や複雑なアルゴリズム/セマンティクスの制約が必要な場合がある。PLデザイナーとしては、静的型チェックを実行時にのみ行うことをあきらめるほうがずっと簡単だ。そして、すぐに使える言語を埋め込むことが最優先なら、それは理にかなっている。でも、それが実際に良いからだとは思わないでおこう。