静的型チェックの好き嫌いについて

Matzさんが過去DRYじゃないから好きじゃない的な発言を繰り返し、DHHさんがこないだいきなりTurbo8のレポからTypeScriptを消し去り大騒ぎになり、、
MatzさんはコミュニティからRubyの静的型チェック対応のプレッシャーを受けてたらしいし、DHHさんの決断は多くの批判を受けたり、、

最近の言語は明らかに静的型チェックを重視しているし、静的型チェックは人気もある

では、MatzさんやDHHさんがおかしなことを主張しているのだろうかというと、、たぶん違うと思うのです

あまり静的型チェックの議論で話題にのぼりませんが（DHHさんは少し言及している）プログラマーも含めて、人がどのように考えるかというのは、想像以上にばらつきがあるのではないかと、、

MatzさんやDHHさんにとって、以下の二つがあるのではないかと「勝手に」想像します
①静的型チェックで得られるメリットがそんなに重要なものだと感じられない
②静的型チェックを実現するための記述を行うことが（周りが思っている以上に）かなり重い負担

こう想像するのは私がそのように感じるからです

経験談です。
JavaScriptからTypeScriptに移行した人たちが、TypeScriptは書きやすく、管理しやすいと絶賛するので、私は何度もTypeScriptにチャレンジし、それなりに大きな規模のプロジェクトで採用したこともあります
（そのプロジェクトは無事リリースできました）

しかし、やはり私はいまだに①②を感じます。

みんながいいと言っているのにいいと感じられないのは、私が現状維持バイアスにとらわれている？とかいろいろ、自問自答したんですが、、

今の所の結論は以下の通り。
①について
→静的型チェックでカバーできるバグなどは、個人的にJSでも発生させていない気がする。過去もそんな覚えがない。
②について
→型定義など、型に関する記述を書く時、どうもプログラムをするときと違う頭を使っている感じになる。そして、プログラムを書く頭に戻すスイッチングコストがかかる。これが本当に苦痛。静的型チェックに関する記述が含まれるコードを読む時も同様。

それぞれ深掘りしてみる。
まず①
静的型チェックで防げるバグをもともと発生させてない（だからこの部分のメリットを感じられない）というのは、別に私がバグを出さないスーパープログラマーというわけではなくて、、別の箇所で、いろいろやらかしてる
ただ、静的型チェックで防げる部分ではバグを作っていない、作りそうにないというだけ

また、②
静的型チェックのための記述が負担というのは、、本当につらい。
①だけなら、別に静的型チェックやればいいんじゃない？という感じになるかもしれないが、②があるために、私は駄々をこねてしまう。
感覚的な話だけど、静的型チェックの効果の一つにドキュメントとして使えるというのがあるが、どうも、静的型チェックに関する記述、型アノテーションとかを書いていると、脳がドキュメントを書くモードになるような気がする。しかし行っているのはプログラミングなので、すぐプログラミングモードに戻らなくてはいけない。
頻繁すぎるスイッチングで疲弊する、、

とはいえ、、ここまで書いた私の感覚に共感してくれる人は、多数派じゃないと思う。
①において、いやいや、そこがバグりやすいからチェックして欲しいよね、と思い
②において、なぜ静的型に関する記述を書くことがプログラミングではない？型アノテーション書くのもプログラミングだから脳のモード変わらんでしょう、と思う人が多数派なんだと思う。

だからこそ、静的型チェックは各言語で受け入れられてきたのだと思う。

ただ、私が書いた感覚も率直なもので、、

ということで、、プロジェクトなどにおいて静的型チェックを導入するのは多数派の認知の仕方にフィットしているという意味でリーズナブルだし、私も、もちろん、プロジェクトにおいては静的型チェックがある言語を積極的に採用するんだけど、、私が楽に書けるJSやRubyについては、静的型チェックとの関係が今のままでいて欲しいなあ、と思います✨

静的型チェックの好き嫌いについて
Matzさんが過去DRYじゃないから好きじゃない的な発言を繰り返し、DHHさんがこないだいきなりTurbo8のレポからTypeScriptを消し去り大騒ぎになり、、…

— してゆう (@siteyuu) December 6, 2023