プログラミング言語の見方が変わった！きっかけの文章

これめちゃいいね！最近CSの研究結構やってるんだけど、いくつかまだ見たことないのがあったよ．ここに載ってないお気に入りをいくつかパッと思いついた限りでシェアさせてね．
－ Ian Piumartaの”Open，Extensible Object Models”（https://www.piumarta.com/software/id-objmodel/objmodel2.pdf）は、プログラマーに最大限の自由を許す最小限のオブジェクト指向メタオブジェクトシステムを作る話．メッセージ送信操作だけ定義してて、他は実行時に全部変えられるんだ．分厚い”Art of the Metaobject Protocol”本のより実践的な対になる感じ．
－ John Ousterhoutの”Scripting：Higher-Level Programming for the 21st Century”（https://web.stanford.edu/~ouster/cgi-bin/papers/scripting.pd…）－これは論文ってよりは記事かな．Tclの作者によるシステムプログラミング言語とスクリプティング言語の二分法について．一見当たり前だけど、そこから得られる教訓は広く応用が利くと思うんだ．みんな、高性能で生産性も最高の完璧なマルチパラダイム言語を探してるけど、コンパイルされて速くて扱いにくいシステム言語と、扱いやすくて柔軟なインタプリタ型のフロントエンドを組み合わせるのがベストなのかもしれない．よくあるのは、同じアプリにCとTclがあれば十分ってケース．また新しいプログラミング言語を書こうとしてる人は必読だね．
－ Niklaus WirthのProject Oberon（https://people.inf.ethz.ch/wirth/ProjectOberon/）は、ハイレベルなUIからカーネル、コンパイラ、RISCっぽいCPUアーキテクチャまで、システム全体を実装したもの．彼は有名な”plea for lean software”を書いてて、それを実際に実践したんだ．依存関係地獄とか、普通のコーダーによる高すぎる抽象化が蔓延するこの時代には失われた芸術だね．

うーん、Ousterhoutの二分法とその結論には同意できないな．
まず、彼の主張の理解として－言語はCみたいなシステム言語か、Tclやpythonみたいなスクリプティング言語のどっちか．システム言語は”強い”型があってデータ構造やアルゴリズム向け、スクリプティング言語は”型なし”で”糊付け”向けだってことだよね．
主な主張は、スクリプティング言語は”型なし”のおかげで糊付け作業でより簡潔で開発が速いってこと．
彼の例だと、Tclでボタンを作るコードがあるね．
button .b -text Hello！ -font {Times
16} -command {puts hello}
彼は続けてこう言ってるんだ．
C++とMicrosoft Foundation Classes（MFC）だと、３つのプロシージャで約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では別に宣言されたメソッドに置く必要がある．
引用終わり．
あれからずいぶん進歩したし、この二分法が誤りなのは例を見れば明らかだよ．Ousterhoutの見方は彼の限られた経験に色付けされてて、Tclの何が彼に気に入ったのかを誤解してるんだ．
構文について話そう．彼の提示した正確なTclコードだって、静的型解析をする言語でパースしてコンパイルできるはずだ．それはそうしてない、なぜなら彼はランタイムにしか型チェックしないインタプリタで実行してるからね．でもポイントは、コンパイルされるか解釈されるかは実装の詳細であって、構文とはほとんど関係ないってこと．彼が自分の構文を気に入ってるのは、彼の構文がC++より明らかに優れてるからであって、それ以上じゃない．
そして型について：彼は’型なし’言語は制約が少ないから開発が速いと主張してる．これは、もちろん、ナンセンスだよ．制約の量は問題に依存するのであって、言語に依存するわけじゃない．動的型付けが開発を速く感じさせるなら、それは制約に出くわすのを後回しにしてるだけだ．
プログラムが実行される前にすべての型エラーに遭遇することを保証する方が良いに決まってる．でも、どんな言語でも静的型解析ができるのに、なぜすべての言語がそうしないの？
だってそれは難しいからだ．型理論は複雑なんだ．すべての型システムが決定可能じゃないし、実践的な理由で決定可能なものを選ばなきゃいけない．決定可能なものは、アノテーションや複雑なアルゴリズム・意味論的な制約（例えばHindley-Milner）を要求するかもしれない．
PL設計者としては、ただ諦めてランタイムに型チェックするだけの方がずっと楽だ．そして、最優先事項が使える言語をすぐに組み込むことなら、それは非常に理にかなってる．でもそれが実際に優れているからだなんてフリはやめようよ．

僕の意見だけど、型なし言語は短いプログラムに最適だと思うな．だってプログラムの100％を理解できるから．型付き言語は、より大きなプログラムの複雑さを管理する方法なんだよ．
関連する例として、BASICプログラミング言語は、24行（ガラスTtyが表示できた行数）に収まるプログラムにすごく向いてるね．

静的型付けのスペクトラムには、明確なコストとメリットのトレードオフがあるよね．みんなCoqを使ってるわけじゃないし．その一方で、”基本的な”静的型付けの負担は、型推論で成功してる現状を考えると、この時点では非常に低いよ［0］．
全ての動的型付けプログラミング言語が（オプショナル／段階的な）静的型付けシステムを追求してるみたいだし、もはや”純粋な”動的型付けPLはほとんど過去のものになった気がする．問題は、どのくらい、どんな種類の静的型付けをするかってことだね．そして、これはおそらくドメインによるだろうね（例えば、Rustとそのメモリ安全性への注力はGCを避けてて、それがライフタイムアノテーションを必須にしてる）．
0）型推論が万能だとは思わないよ．例えば、複雑な型システムがクレイジーな型を推論して、推論器が失敗した時にそれらをデバッグするのに詰まるような場合、あまり役に立たないね．

BASICの変数には型があるよ．BASICは元々印刷端末向けに設計されたから、24行の制限はなかったんだ．現代のBASICはもっと大きなプログラムを書くのにも向いてるよ．
今日のHNでもこんな記事見たよ：
”I Miss Visual Basic”
https://news.ycombinator.com/item？id=43988853
”The history and legacy of Visual Basic” https://news.ycombinator.com/item？id=43949855

僕が使ってたBASICは70年代のPDP-10のBASIC-10だったよ．オリジナルからそんなに改良されてなかったな．24行の件はガラスTtyの制限であって、BASICじゃないんだ．

関数が画面一つに収まるのは、今でも良いアイデアだと思うよ．
僕の言いたかったことは、テレタイプ式の印刷端末は、ビデオ表示端末みたいに垂直方向の空間に本質的な制限がないってことなんだ（そして、結局印刷はかなり長くなる可能性がある）．
でも今考えてみると、もしかしたらBASICの設計者たちは、初心者にとって、80カラム（シーケンス番号付きだと72カラム）のパンチカードの小さな束に収まるような短いFORTRANプログラムに匹敵する何かを書く方法を、午後一つか二つで簡単に学べるようにすることを考えてたのかもしれないね．

同意するよ、僕の経験則だと1k LoCを超えるなら静的型付き言語で構築するのが一番だね．長期間メンテするつもりのない20行程度のプログラムなら、PythonよりRustを選ぶことはまずないかな．

うん、20行のコードにborrow checkerを使う理由は全くないよね、borrow checkerを実験してる場合を除いては．

静的型付けは、型が制約を保証する非常に大きな硬い構造を構築できる．ただし、これらの制約は迅速な作業の妨げになる．関数のシグネチャを変更すると、その関数を呼び出すコードのすべての部分を最初に変更する必要がある．その後、コンパイルし、プログラムを再起動し、全体の硬い構造を再構築し、変更が期待通りに機能することを確認する必要がある．このプロセス全体に数分かかることがある．これらのエラーをコンパイル時に検出することで、より信頼性の高いコードになるという主張がある．
動的型付けには、コンパイル時にエラーを検出するのに役立つそのような制約はない．動的型付けを使用すると、より流動的に変更される有機的な構造を構築できる．関数シグネチャを変更しても、その関数を呼び出すすべてのコードを変更する必要はない．アプリケーションを再起動せずに、実行中のアプリケーションで関数を変更してテストできる．これには数秒しかかからない．動的型付けを使用すると、100倍速くイテレーションできる．迅速にイテレーションできるということは、テストがよりしっかり行われたコードになり、より信頼性の高いコードになることが多い．
どちらも価値がある．要件が頻繁に変更される開発段階やプロトタイプを構築する必要がある場合に、動的型付けは価値がある．コードがより成熟しており、変更が少なくなり、コードを本番環境に配置する必要がある場合に、静的型付けは価値がある．
理想的には両方を持つことだ．プログラムのより成熟した部分は静的型付けされ、より流動的な部分は動的型付けされる．

＞ 静的型付けだとカッチリした大規模構造が作れて、型のおかげで制約が守られるけど、その制約が素早い開発の邪魔になる。関数のシグネチャを変えると、呼び出してるコード全部直さなきゃいけないってさ。
これ、動的型付け言語の方が”素早い”ってのには断固反対だな〜特に小規模じゃない（つまりデカい）コードベースだとね。
動的型付け言語でそんな変更しても、フィードバックゼロだし、変更がどんだけ影響するかも分からない。実際、変更が本当に全部終わったのかすら分からないんだよ。
それに比べて、静的型付けだと即座にすごく役に立つフィードバックがあって、変更箇所まで教えてくれる。直す必要があるコードが全部特定されて、こっちに伝えてくれるからね。

＞ これらのエラーをコンパイル時にキャッチすると、より信頼性の高いコードになるって主張ね。
俺にとって一番大事な理由は、静的型付けの方がコードがずっと自己文書化してくれること。関数が何を返してるか見れば分かるし、もし分からないものだったら型宣言を見に行けば、その型で何ができるか分かるんだ。
これは動的型付けとは全く違う。動的型付けだと、ドキュメントがすごく良くて最新であることを祈るしかないけど、これがそうじゃないことってしょっちゅうだからね。

コンパイラがやってくれるはずの作業（発見しにくいバグ追跡も含めて）に時間を使うのは、動的型付けのルーズな仕組みから得られた時間よりもはるかに多くの時間を無駄にしたよ。

＞ それからコンパイルして、プログラムを再起動して、硬い構造全体を再構築して、変更が期待通りに動くか確認しなきゃいけない。このプロセス全体で何分もかかることもある。
これ、俺の経験とは全然違うんだよ。Virgilは完全に静的型付け言語だけど、コンパイルは速い。Virgilコンパイラ（約50KLOC）で作業してる時、普通のワークフローはデバッグモードでインタープリタを使って、編集→実行のループを回すことなんだ。インタープリタはコンパイラ全体を読み込んで、型チェックして、俺の変更で実行するのに90ミリ秒しかかからない。最適化付きのコンパイルをループに入れても400ミリ秒だよ。
ターミナルタブ２つ切り替えるより時間かからないね。
これは静的型付け対動的型付けの問題じゃないんだ。めちゃくちゃ非効率な言語/ビルドシステム対効率的なやつの問題なんだよ。

非効率な言語やビルドシステムは問題を悪化させる可能性はあるね。
１秒未満でコンパイルできる静的型付け言語はたくさんある。でも、関数のシグネチャを変えたら、呼び出し側全部直さなきゃいけないのは変わらない。
それから再コンパイルして、アプリケーションを再起動して、全データ構造を再構築しなきゃならない。
一部の静的言語はインタプリタモードでホットリロードを許してるけど、許される変更の種類は限られてる。
Common LispやSmalltalkみたいな動的言語だと、プログラム動かしたまま更新できる。イテレーションの速度は100倍速いよ、だって変更をテストできる状態にするために、アプリケーションを再起動して全データ構造を再構築する必要がないからね。

＞ プログラムが実行される前に全ての型エラーに遭遇することを保証する方が良い。
これ、ミッションクリティカルなソフトウェアを書いてるか、無限に時間がある場合しか通用しないよ。
あなたの議論は、納期があって出荷しなきゃいけない場合を考慮してないね。だから、型の完璧さなんてどうでもよくて、生産性を最適化するのが最優先なんだ。
パフォーマンスが重要な環境でさえ、スクリプト言語があまり向いてないのに、どうにか生産性のためにそれらに頼る理由があるんだよ。
例えばゲーム開発（Unreal EngineとそのBlueprintシステム、GodotとそのGDScript、C++とLuaを組み合わせた多数のゲームエンジン）。
もちろん、ゲーム開発者だって静的型付けで理想的なデータ構造を書いてゲームがクラッシュしないようにしたいのはやまやまだけど、彼らの目標は10年以内にゲームを出すことなんだ。だから、パフォーマンスが重要なエンジン部分に強い型付けを限定して、型理論の本なんか見ないでコアプロダクトの開発とイテレーションに集中できるんだ。
Mr. Ousterhoutの議論のポイントは、選択肢は二つしかないってことだよ。つまり、万能薬、つまり100％安全なのに実験やオプショナルな型付けもできて、C++並みの速さでネイティブコードにコンパイルできる生産性の高い強い型付け言語っていう神話を invent するか、これが不可能な夢物語だと受け入れて、問題に合ったツールを使う必要があるってことさ。
これは表面上は当たり前なんだけど、今でも議論の的になってる点だよね。

＞ 結局、全部アセンブリ（実行される）か、インタープリタ（実行される）にコンパイルされる。アセンブリ最強だね。
ここでの本当の選択肢はこうだ：プログラマーのコードを事前にアセンブリにするか、ランタイムでそうするか（アセンブリがプログラマーのコードを解釈する）。あるいはJITコンパイルみたいな中間。
そして：どんなガードレールを設置するか。
だから、高レベル言語っていうのは、面倒で嫌なアセンブリコーディングをもっと palatable にする方法だと言えるね。
例えば、ただマシンがクラッシュする代わりにエラーレポートを出したりとか、サンドボックスを提供したりとか、プログラマーの思考に合う計算モデルを提供したりとか。
それらの間には、ただいくつか役に立つ抽象化が必要なんだ。できればシンプルで汎用性のあるやつ。
例えば、（ビットマップ）”スクリーン”は、ただの平らなメモリ空間（フレームバッファ）でもいい。あるいはピクセルの２次元配列で、おそらく”ピクセル”は別の場所で定義されてるとか。
プログラマーはGPUがどうやってそれらのピクセルを表示するように強制されるか気にしないし、低レベルコードは高レベルソフトウェアがそれらを生成するために何をするか気にしない。
そして、そういう抽象化は可能な限り少なく（ただし少なくしすぎないように！）持つことだ。
Tcl: ”全ては文字列”
Lisp: ”全てはリスト”
Unix(-like): ”全てはファイル”
とかね。
個人的には、表現力 / 少なくても役に立つ抽象化の数と、その実装サイズの比率で期待以上の働きをする言語に惹かれるね。Forth、Tcl、Luaなんかが思い浮かぶ。
まあ、それはただ俺の好みだけどね。開発者とその所属組織は自分たちで選択するんだ。

＞ ここでの本当の選択肢はこうだ：プログラマーのコードを事前にアセンブリにするか、ランタイムでそうするか（アセンブリがプログラマーのコードを解釈する）。あるいはJITコンパイルみたいな中間。
言語が好むコンパイル/インタープリタモデルは、大まかに言って、その型システムや、開発速度、正確性、パフォーマンスのどれを重視するかとは直交するね。
それに、多くの言語は実際には様々なコンパイル/インタープリタモデルを使って実装できる。例えばCのインタープリタもあるし、Javaの事前機械語コンパイラもあるよ。

＞ だから、高レベル言語っていうのは、面倒で嫌なアセンブリコーディングをもっと palatable にする方法だと言えるね。
うん、スクリプト言語のポイントはほとんどが動的型付けと動的バインディングだね。これはランタイムでバインディングを解決するってことで、実行が遅くなるってことだ。
銀の弾丸なんてない：速度が欲しいなら、速い機械語にコンパイルされる扱いにくい言語が必要だ。
使いやすさとか手間のかからなさが欲しいなら、遅い言語になるよ。

動的な問題には、動的言語の方が間違いなく使いやすいね。
静的に分かりきってる問題には、必ずしも使いやすいわけじゃない。
静的言語は正確さと速度でメリットがある。
キーワードは「動的」だね。

経験が少ないって言葉は違ったかも。1998年に書いてるって考えると、視野が限られてたって言いたかったんだ。
前のコメントへの補足説明だね。意図が伝わるように訂正してる。

この議論でいつも分かんないのはさ、全部理解してないデータをどれくらい渡してるの？
あと、型使う人が結局リフレクションで型パターンマッチングするようになるけど、それってユーザーレベルから型システムに型付けを移しただけで、あんまりメリットない気がするんだよな。

”全部理解してないデータをどれくらい渡してるの？”
いつでもでしょ。プログラムが大きくなると、どこで何が渡されてるか、全部把握なんて無理になるんだ。
”あと、型使う人が結局リフレクションでパターンマッチング…”
それはツールとして使う場合であって、デフォルトは型をちゃんと使うことじゃない？

”全部理解してないデータをどれくらい渡してるの？”
例えば、同僚が1週間頑張ってコミットした新しいコードを使う時とかね。

ほとんどの人は型パターンマッチングにリフレクションを使ったりしないよ。だって、型が変わったときにバグを仕込んだ場所で、すごく分かりやすいエラーが出るんだから。

でもさ、本当に制限が少ない言語もあるよ。Javaのごちゃごちゃに比べたら、Pythonで気にしなきゃいけないことはずっと少ないんだ。
問題を先送りしてるって言われるかもだけど（そうかもね）、多くのスクリプティング用途では全然アリだよ。

うーん、そうとも違うとも言えるかな。GCやRust借用チェッカーみたいに、言語で制限の違いはある。
でも、問題は擬似コードの時点で型があるんだから、コードにする時に型を合わせるのは一緒。エラーが実行時かコンパイル時かの違い。俺はコンパイル時エラーが好きだ。大規模開発では超重要。
PythonとJavaの心配事の違いは、型チェックのタイミングじゃないと思うな。

Pythonだとボイラープレートほぼゼロでタスクできる。ループとオブジェクト、ライブラリ呼び出しだけで。クラスも使わないこと多いし状態はグローバル。
Javaだと同じことするのにすごい量になるんだよ。儀式が多いよね。
GCの制限はあるけど、主にスクリプティングのニーズでPythonは優れてる。その分野でPythonが一般的でJavaがそうじゃないのは理由があるんだよ。

”型なし言語は制限少ないから開発速い”？
コード書いてる時は分かんないことの方が多い。強い型付け言語は、何やりたいか分かってない段階で型に集中させられる。
データを型にはめるのは、データ構造が落ち着いてもう変わらないと確信できた時。
まず動くコードを書いて、次に正しく、速くって進める。弱い型付けはプロトタイピングに使って、後で型付けしてしっかり書くんだよ。

どんな問題の解決策も型で記述されるんだよね。型チェックは実行時でもコンパイル時でもできるけど、意味あるプログラムには型がある。もし文字列を引数に取る関数があって、型システムがint渡しちゃうプログラム動かせるなら、それって「素早いイテレーション」できたの？早く動くのは確かだけど、結局「関数はstringなのにintが来た」って同じ型エラーにぶち当たるじゃん。大規模なコードだと、型チェック満たすのがイテレーションを遅くするって意見もあるだろうけど、静的型付けなら他の場所で引き起こした型エラーのリストを計算できるのは明らかにお役立ちだよ。