逆サピア＝ウォーフとプログラミング言語
(lukeplant.me.uk)- Inverse Sapir-Whorf は、言語が何を考えにくくするかではなく、何を言わずにおきにくくし、どのような情報を明らかにするよう強いるかに焦点を当てる
- 英語の現在時制、性別代名詞、フランス語の性名詞、トルコ語の mış 過去形は、暫定性、性別、情報源や信頼性のような情報を話者に語らせる方向へ押しやる
- プログラミング言語でも、計算順序、async かどうか、メモリの割り当てと解放、スコープ、型のように、開発者が関心を持っていないかもしれない話題をコードに含めるよう強制することが多い
- Python や Javascript の
async、C のメモリ管理、Rust のライフタイム、静的型付け言語の型注釈は選択を明示させ、Haskell は 非正格意味論 と厳格性解析によって一部の選択を言語に委ねられる - よりアクセスしやすいプログラミング言語は、Inverse Sapir-Whorf の障壁が低く、まだ理解していなかったり意見を持っていなかったりする話題について語ることをあまり強制しない特性を持ちうる
Inverse Sapir-Whorf が意味するもの
- Sapir-Whorf hypothesis は、単純化すれば、使う言語が思考に影響するという考え方である
- Sapir-Whorf の強い形、とくに言語が思考を統制したり、特定の考えを持つために特定の言語が必要だとする 言語決定論 は、今日の言語学では広く真剣に受け入れられてはいない
- ある言語に文法的な時制がないからといって、その話者が時間についてより制限された形で考えるという結論にはならず、時間を表す他の方法は常にある
- 口語が特定の領域の知覚、記述、態度に影響しうるという証拠はかなりあるが、大きな直接効果を立証するのは通常難しい
- Inverse Sapir-Whorf は、言語が何を言ったり考えたりしにくくするかではなく、何を 言わずにおきにくく するかに焦点を当てる
- この観点では、言語がどのような情報を語るよう押しやるのか、あるいはどのような考えを避けにくくするのかが核心である
自然言語に現れる強制性
-
英語の現在時制における暫定性と永続性
- “I’m living in London” と “I live in London” はどちらもロンドンに住んでいるという意味だが、前者はその状態が 一時的 であるという情報を明らかにする
- 非母語話者はこの違いに気づかないことがあり、母語話者であっても無意識に受け取っているだけかもしれない
- 「一時的」という意味は、実際の居住期間よりもロンドンをどれだけ気に入っているかとより関係している場合もある
- 英語では時制を選ばなければならず、たいていは無意識に選ぶため、言語が居住期間や感情のような情報を明らかにするようにしている
-
英語・トルコ語・フランス語の性別代名詞と名詞
- 英語の日常的な発話では、特定の人を指すとき通常は “he” か “she” を使わなければならない
- “singular they” は存在するが、性別を知っている、あるいは推測している特定の人物について話すときにはあまり自然ではない
- トルコ語では he/she/it に相当する “o” ひとつを使い、このような性別代名詞の不在が人の性別について考えたり話したりすることを妨げるわけではない
- この点で一般的な Sapir-Whorf を支持するのは難しいが、英語の代名詞が、望むと望まざるとにかかわらず性別を語るよう押しやるという点で Inverse Sapir-Whorf は明確である
- 知っている人について匿名で話そうとしても、“him” や “her” を何気なく使うと性別が明らかになり、識別しやすくなることがある
- フランス語では名詞が性を持ち、“my friend” を訳すときに “mon ami” と “mon amie”、または “mon copain” と “ma copine” のどちらかを選ばなければならず、情報を明かすことになる
- 所有代名詞も英語とフランス語の両方で性別化されているが、英語の his/her は所有者の性別を、フランス語の son/sa は所有される対象の性別を指し、それぞれ異なる情報を明らかにする
-
トルコ語の “mış” 過去形
- トルコ語には、単純化すれば英語の単純過去に近い一般過去形と、“mış” 形という二つの主要な過去時制がある
- “mış” 形は複数の機能を持ち、過去の出来事を語るときには、その情報が 伝聞 である、あるいは信頼性が低い場合に使われる
- 「Fred は月曜日に出勤したか？」という問いに、直接見たなら一般過去形 “geldi” を使い、聞いた情報なら “gelmiş” を使う
- 英語では単純過去形だけで情報源や信頼性を特定せずに語れるが、トルコ語では特定の状況で確信の度合いや直接目撃したかどうかを含めるよう強制される
- “mış” 形があるため、一般過去形は中立的な選択ではなく、二つの選択肢のどちらもあまり適切でないときには不自然になる
- トルコ語では “mış” 接尾辞が文の最後の語尾に来ることが多いため、英語の文を言い終えてから「これは伝聞情報であり、直接見たものではない」という印を入れていなかったことに気づき、最後に “mış” を付け足す癖がつくこともある
- 英語でも “apparently” のような語で同じ内容を容易に表現できるが、英語はそれを明示するよう 強制せず、トルコ語はかなり強く強制する
-
母語話者には見えにくい言語の強制性
- こうした違いは、他の言語を学んだり、自分の言語を外国人に教えたりするまで気づきにくいことが多い
- 単純現在と現在進行を選ぶほとんどの場面で、その選択が何を示唆するかを意識的に考えることはない
- 言語が何らかの表現を強制するとき、それは常に何かを含める形で現れるとは限らず、省略 によって意味が固定されることもある
- “I love cake” は一般的なケーキを指し、“I love the cake” は特定のケーキを指す
- 最初の文では “the” がないため、ケーキ一般を指すことが明確になり、特定のケーキなら “the” や “this” のような印を必ず使わなければならない
- 他の言語には、この区別に直接対応する表現がない場合もある
プログラミング言語における Inverse Sapir-Whorf
- プログラミング言語では、一般的な Sapir-Whorf もより当てはまりやすいかもしれない
- Python や Haskell のような言語では、メモリ割り当てについて語るのは難しいが、不可能ではない
- プログラミング言語の限界は、通常、その言語で表現しにくいものとして語られる
- Hillel Wayne の Sapir-Whorf does not apply to Programming Languages は、この主題をより詳しく扱っている
- Inverse Sapir-Whorf の観点では、プログラミング言語が実際には関心のない話題まで語るよう強制するかどうかが核心である
- このような強制性は、複数の言語を学ぶときに生じる 外国語学習者のような視点 があってこそ見えやすい
プログラミング言語の主な例
-
計算順序
- ほとんどの言語は、計算が実行される 順序 を表現するよう強制する
- Python の
x = some_func(y + 1, z + 2)は、まずy + 1を計算し、次にz + 2を計算し、その後二つの値をsome_funcの引数として渡す順序を述べている - この順序を意識しないことはあっても、Python では上の計算を表現しつつ順序を指定しない方法はない
- ほとんどの言語は似ているが、一部の言語では評価順序が非常に複雑になる
- Haskell の
some_func (y + 1) (z + 2)のような等価な表現は、非正格意味論 のため評価順序をまったく指定しない - この特性は、まだ定義していない値を参照する Tying the knot のような手法を可能にする
-
async 関数の色
- async 関数の色 は良い例である
- Javascript や Python のように明示的な
asyncキーワードがある言語では、コードが同期か非同期かを語らなければならない - 同期関数では
asyncキーワードを省略することで表現するが、それでもなお二つの選択肢の一方を選んでいる - この話題について曖昧なままでいられるコードを書く方法はない
-
メモリの割り当てと解放
- ガベージコレクション) がないほとんどの言語は、メモリの割り当てと解放を語るよう強制する
- C のような言語では通常これをかなり明示的に扱うか、あるいはスタック割り当てを暗黙に使うが、いずれにせよ選ばなければならない
- 他の言語ではこの問題がより隠されることはあっても、消えるわけではない
- Rust ではこの問題はライフタイムや明示的な参照カウントの話へと姿を変える
- 「このメモリがいつ割り当てられ、いつ解放されるかは気にしないので、うまく処理してほしい」という選択肢は、実際には提供されていない
- メモリ割り当てを語らないことにもコストがある
- そのような言語はほぼ確実に多くの値をヒープに置き、ランタイムのガベージコレクタを必要とする
- その代わり、言語には選択の自由が大きく与えられ、Haskell はたとえば厳格性解析によってこうした選択を行うことが多い
-
スコープ
-
型
- 静的型付け言語は通常、すべての変数の 型 について考え、語るよう強制する
- 型推論は、より賢い聞き手が文脈からより多くを読み取るように、この負担を軽減してくれるが、対話そのものは依然として存在する
- 純粋な動的型付け言語でも Python の
isinstanceチェックのように型を語ることはできるが、より不自然であり、技術的にも別物である - 漸進的型付け言語 の魅力の一つは、Inverse Sapir-Whorf 問題を実際に回避し、好みに応じて型について語るか語らないかの自由を与える点にある
- 実際にどれほどよく機能するかは定かではなく、既存コードベースの慣習や使用するリンターが、常にどちらかの方向へ圧力をかける
アクセスしやすい言語と低い障壁
- より「アクセスしやすい」または「読みやすい」プログラミング言語の多くの特徴は、Inverse Sapir-Whorf の観点から分析できる
- こうした言語は Inverse Sapir-Whorf の障壁 が低く、まだ意見を持っていない、あるいは理解していない事柄について語るよう強制しない特性を持ちうる
- プログラミング言語が強制する話題は、使用する言語に対する認識や選択に影響しうる
1件のコメント
Lobste.rsの意見
言語設計は、プログラミング言語であれ自然言語であれ、言語にどんな要素を入れるかによって、ユーザーがどこに注意を向けるべきかを定める営みだと見なせる
Cは暗黙に「メモリ管理を気にしろ」と言い、Haskellは「変数や式が取りうる型を気にしろ」と言う
言語が自分が実際に注意を向けたい方向へ導いてくれると、その仕事に合った道具のように感じられるし、そうでないと、カクテルパーティーで静かに話す人の声を聞こうとしているのに、部屋の向こう側で誰かが大声を出しているように感じる
注意力はもっとも貴重な資源なので、道具がそれをどう誘導し形作るのかを意識する必要がある
英語で"the"を明示するか省略するかは対象の特定性について中立ではなく、トルコ語でmişを使うかどうかは、その情報が直接得たものか伝聞かについて中立ではない
これは「言語が言えることを制限する」という標準的なサピア＝ウォーフ仮説、つまり表現の中立性の反対側とも見なせる
そうすると、ある主題について言語が中立かどうかを説明でき、言語設計者としてユーザーの注意を拡散させたり集中させたりするよう調整できる。たとえばガベージコレクションはヒープ割り当てについて表現を中立的にし、エフェクト追跡は副作用と入出力について表現を非中立的にする
文章の核心を完全につかめているかは分からないが、Rustについて長年繰り返し考えてきたことを思い出した
Rustは参照を扱えるようにしてくれる一方で、メモリ安全性を保証するために厳格な規則を置いた、妙な立ち位置にある
C++なら何かを参照にすべきだと思えばそのまま参照にして、問題が起きないことを祈るし、Pythonならそんな制御権はないのでデータを気軽にコピーする
ところがRustでは、「コピーは非効率だから参照にしよう」という最適化の落とし穴にはまりうるし、borrow checkerが騒ぎ出すと、この参照は安全だと確信していても1時間コードをリファクタリングすることになる
良いRustプログラマーたちは「とにかく
.clone、RC、Boxなどを使え」と言うし、それには同意するが、参照が目の前にあって安全に使えそうだという事実は残るだから、borrow checkerをなだめるためにより悪くしてしまったような奇妙な感覚が残るし、「borrow checkerは自分には厳しすぎる」と諦める人が出てくる理由も分かる
良いテーマだし、トルコ語の文法の話が少し出てくるのも嬉しい
もう1つよくある例として、ある言語では複数性のような細かな情報を省略できることがあり、ベトナム語はその例だ
"exaggerated"という単語にリンクが付いているのを見て、「もしかしてArrivalの話か？」と思ったら、本当にそうだったのも楽しかった
多くの人に好かれている映画だが、個人的にはなかなか納得して受け入れられなかった。SFだと言いながら、その「科学」が一種の魔法めいた言語学のように感じられたからだ
たいていのアプリケーションプログラミング言語は、単一の値をある種の原子的な基盤としている。その上にリストやマップは作れるが、これらも結局は1つの単一なものだし、微妙に相互運用できないことも多い
Rustではこうした構造のあいだをコピーすることが多く、SQLではその問題をあまり気にしない代わりに、インデックスやクエリプランを気にしなければならない。とくに、データベースが自分の尋ねたいことを複雑にする、明らかに愚かなプランを立てるときはそうだし、SQL NULLには触れないでおこう
結果として、私たちのソフトウェアの大半は個々の値のレベルに至るまで信じがたいほど過剰に指定されていて、PCの性能は1000倍良くなったのに、最良のUIレイテンシは昔の10倍になっている
オブジェクト指向プログラミングの教条主義も部分的には責任がある。非同期も一度試したが、独立した作業を1つずつ
awaitするような、木を見て森を見ずの状態へあまりにも簡単に劣化してしまうhttps://www.uiua.org/ は幸福であるべきだと想像しなければならない
良い指摘だ。現代のあらゆる言語は、プログラマーが雑草むらに踏み込むように細部を扱うことを強制するか、少なくとも強く促す
スクリプト言語は、プログラムやWebページのような少し細部の少ない対象に対する演算を提供するが、それでも細部を消し去ることはできない
依然として数字や文字列やエラーコードのようなごく小さな細部を考え、管理させる
私たちは長年の訓練と実務によって細部の管理に慣れすぎてしまい、細部の観点で考えないことが非常に難しくなっている
最初に思い浮かんだのは、オブジェクトやモジュールのインターフェースだった
プログラミング言語ではこれは非常に具体的だが、自然言語の会話ではずっと曖昧だ
もう1つの例は、C++のジェネリクスとPythonのジェネリクスの違いだ。C++では非常に意図的に扱わなければならないが、Pythonでは型ヒントを無視すればかなり暗黙的に扱われる
「逆サピア＝ウォーフとは、言語が言えないことを制限したり、あることを言わないのを難しくしたり、さらにはあることを考えないのを難しくしたりするものだ」という部分は、文法 > イディオム > 標準ライブラリ > サードパーティライブラリ > エコシステムというピラミッドのように見える
「考えないのが難しい」という部分は、表現しにくい、あるいは重要な制約のある問題に焦点を当てているようだ
慣れは上下の両側から内側へ作用し、人は各層でコードを書くやり方によって自分の背景を表す
英語を15年以上読み書きし話してきたのに、"I live in London"と"I'm living in London"が違うことを知らなかった
自分がLondonに住んでいるのか、今Londonに住んでいるのかも分からない 😅
ここで動名詞形を普通の形容詞に置き換えて"I am cold"と言ってみると、今寒いという意味であって、何かのスーパーヴィランみたいに永久に冷たいという意味ではないと受け取るはずだ
同様に、"I am living in London"は現在Londonに住んでいるが、将来は変わるかもしれないことを示唆する
また、ずっとLondonに住んでいたわけではないというニュアンスもある。"I am cold"が、少なくとも一度は十分暖かい温度を経験したことがあり、だから今の状態を「普通」ではなく「寒い」と認識している、という含みをある程度持つのと似ている