LemonHX

strong type と weak type の議論について困惑している初心者や型理論を学んでいる人は、ぜひご覧ください。

まず、ゲスト著者 dannypsnl に感謝します。彼のブログを読んでみてください！

Type とは何ですか？#

Weak Type と Strong Type#

実際には、言語が strong type か weak type かを説明することはできません。なぜなら、strong と weak はそれぞれの人によって異なる範囲を持っているからです。一般の開発者にとっては、この範囲は間違っています。

専門の理論学者にとっても、彼らの内部の範囲は間違っています。私たちは一晩中議論を重ね、この範囲を以下の 5 つに縮小しました。現在、学術界でも民間科学者でも安定した用語で範囲を表現することはできませんので、説明と例を試みるしかありません。

第 1 グループ：実行時の型がコンパイル時の型と完全に一致し、すべてが静的で変更不可能で理論的に完全なもの#

このグループの言語はほとんど存在しません。なぜなら、この範囲では言語全体が静的で予測可能な状態で実行されることが保証されるため、停止問題に触れる前に、このモデルは言語と外部のインタラクションを制限してしまいます。

簡単に歴史を紹介しましょう。遠い 20 世紀に、Miranda という言語がありました（Haskell の父）。その当時、ほとんどの大学でこの言語のフォークがありました... なぜなら、Miranda では日常的なプログラムを書くことがほとんどできず、みんなが上に DSL の層を重ねてさまざまな穴を作って実際に意味のあるプログラムを実行していました。

ここでの意味のあるプログラムとは、PL の論文を発表するためのものでも、型安全な電卓のようなものでもありません。

基本的に Miranda は、ネイティブとのインタラクションを一切行うことができないプログラムを書くことができませんでした... これは歴史的な前提条件です。

そして、このグループの人々はティーパーティーを開催し、最終的にはあまり厳密ではない Haskell を作り出しました。

（上記の歴史には一部省略がありますが、大まかにはこのような経緯です）

なぜ彼らは第 2 グループにランクダウンしたのでしょうか？それは第 1 グループの実際の価値が一般的には不十分だからです。プログラミング言語を書くことができない言語の誕生には何の意味があるのでしょうか？

まとめると、第 1 グループの言語のユーザーはコードを完全に信頼できますが、意味のあるプログラムを書くことはできません。

第 2 グループ：実行時の型がコンパイル時の型と完全に一致し、すべてが静的で変更不可能で理論的に完全なものであり、キャストが許可されている#

• Haskell
• Rust
• C

一部のキャストと穴を許可することで、既存の複雑な副作用を持つ世界と実際にやり取りすることができます！通常、このグループの言語は理論的により完全であるため、その背後にある理論を完全に理解しているプログラマが無駄なくコードを書くことができます。

（太字のフォントに注意）

ただし、通常、彼らの理論は（通常の学士号を持ち、PL に関連する知識を持たない）一般のプログラマにとって非常に複雑です。たとえば、Haskell の $System\ F_\omega$ などです。

ただし、これは専門のプログラマにとって悪いことではないと言っているわけではありませんが、大きなサークルを回避する必要がある場合があります。これを俗に型体操と呼びます。

まとめると、このグループの言語では、一定の専門知識があれば安全なコードを無駄なく書くことができます。このグループの言語については、評価が非常に二極化していることがよくあります。

最近注目されている Rust 言語も、大まかにはこの位置にあります。

実際、C 言語もこの位置にありますが、C については後で説明します。

第 3 グループ：コンパイル時の型があり、実行時に動的に変更不可能な型であり、チェックが行われる#

このグループでは、最近人気のあるいくつかのスクリプト言語を見ることができます。

• Elixir
• Ruby3
• Typed Racket
• TypeScript*（この言語は、コンパイル時の型が信頼できないが、実行時の動作には関係がないという意味で、この位置に置かれます）

このグループでは、通常、ts 以外の言語に触れる機会はあまりありませんが、基本的にはコンパイル時の型チェックをほとんどのコード（上記のグループは基本的には良いコードを書けばすべて）に適合させることができ、同時にスクリプト言語の動的性を確保するために any などのものを予約しています。

このグループの書き方の体験は非常に優れており、専門家以外の人々にとってもほぼ一貫して良いと評価されています。

第 4 グループ：コンパイル時の型がなく、実行時に動的に変更不可能な型であり、チェックが行われる#

このグループの言語は、一般の人々にとっては弱い型または実行時の強い型（動的型）の言語と区別がつかなくなります。この範囲にはいくつかの代表的な言語が含まれます。

• JS*（これは第 5 グループには含まれていませんが、本質的には JS は自己完結できると言えます）

• Erlang

• Ruby2

このグループの言語のユーザーは、作者の期待に合わないランタイムエラーにはほとんど遭遇しません。ほとんどの場合、ユーザーはコードを信頼できます。

（前提として、正しい動作がわかっている場合）

第 5 グループ：実行時に動的に変更可能な型（俗に弱い型と呼ばれる）#

• Python
• Perl
• PHP

このグループの言語は、作者のスキルが限られているか、人気を考えずに書かれたか、当時の技術的制約によって生まれたものです。主な特徴は、ユーザーが作者のドキュメント（前提として、きちんと書かれている場合）だけを信頼できるが、コードを全く信頼できないことです。

Type の階層は、言語をどのように見るかによって変化します#

ここで、なぜ C 言語が第 2 グループに位置しているのか疑問に思う人もいるかもしれません。

無数のバグを引き起こした C 言語が Haskell と一緒に立っているのはなぜでしょうか？

実際、C 言語はあなたがメモリの安全性の問題を引き起こす可能性があることを作るときには考慮されていませんでした。したがって、この問題は C が解決すべき問題の範囲にはありません。また、C 言語を名目（名前の型）型の言語と見なす場合、第 5 グループに属するでしょうが、もし作者の意図する使用法を本当に理解しているのであれば、彼のタイプはサイズ（つまり、私たちが俗にC ABIと呼ぶもの）であり、それによって第 2 グループの厳密さに達することができます。これが、一部の C プログラマーが C は非常に厳密な言語だと言う理由ですが、ほとんどの人々はそうは思いません。

ほとんどの人々は数字に敏感ではないため、これは私たちの遺伝子によるものかもしれません（

もう 1 つの可能なアプローチ：構造的な型付け#

ただし、成熟した実装を持つ言語はありませんが、このセットは第 2 グループの振る舞いを第 4 グループで説明することができます。

言語の使いやすさと Type の関係はありますか？#

全く関係ありません

統計的な一致がないため、非常に複雑で完全な Type 理論を使用しても非常に悪い言語を簡単に作ることができます。

以前は、構文の利点や型の単純さが重要でしたが、今はテキストエディタでコードを書くことはありません。

柔軟すぎる言語では、良い IDE プラグインを作成することができません。たとえば、Racket の構文マクロは、自由に構文を変更できるため、リーダーマクロなどがあります。

Ruby は今でも良い補完がないのは、実行時に大量のコードが生成されるためです。

また、言語の信頼性の問題は、ドキュメントがあればコードを書けるかどうかに関係します。極端な例を挙げると、Haskell プログラマーは通常、コメントを必要としません。型を見ればわかります。Hoogle のようなものを例に挙げましょう。

私たちプログラマーは名前を覚える必要がありません。型がどのようなものかを覚えておけば十分です。

しかし、Racket プログラマーは、複雑なプロジェクトを書くときにライブラリの作者のヘルプなしでは説明できないことはありません。

もう 1 つ重要な問題は、ツールチェーンです。

それが言語の使いやすさを決定します

例えば、人間に反対の言語である Rust という言語があります。その構文は醜く、非常に書きにくいですが、Cargo という世界一流のツールチェーンがあるため、大成功することができました。もしツールチェーンが Haskell の stack だったら、この言語はもう終わっていたでしょう。

trait XXX<T: Send + Sync + Clone> {
    type YYY<'a>: Future<Output = zzz::<AAA>::BBB<T>> where Self : 'a;
}

まとめると、Type は、ファイルに含まれるコードの動作が予想どおりかどうかを決定するだけであり、Type のサウンドネスの程度は正確性を保証するだけであり、使いやすさを保証するわけではありません

なぜある言語が他の言語よりも優れていると考えるのですか？#

それぞれが異なる問題に直面し、解決する必要があるものであり、要求されるものも異なります。私のような PL の人間でも PHP でブログを書いています。あなたが注目すべきは、問題をどのように解決する手段であり、その言語が Type を持っているかどうかではありません。

多くの場合、あなたが言う言語が良いかどうかは、あなたの経験に基づいていますが、この質問をする人が同じことをしようとしているわけではないかもしれません。また、自分の道が最適解であることを保証することはできませんので、言語を適当に推奨しないでください〜

研究者の PL 人は何をしているのですか？#

• 名詞を作る🤫
• 精神病院に向かう途中🚑
• 私に対して怒っている準備をしている🤯

結論#

プログラミング言語を冷静に見ることをお勧めします。それらはただの一般的なツールです。