【海外の反応】C++生みの親と標準化委員会が対立、Contracts機能めぐり激論
姉妹サイトの新着
Hacker Newsで、C++の設計者Herb Sutter氏が公開した論文「言語の生みの親とその『所有者』が強く対立するとき」が話題になっていた。論文は、新しいContracts(契約)機能の「保証された強制」をめぐって、C++の生みの親であるBjarne Stroustrup氏と、標準化を担うISOの委員会(WG21)が強く対立し、委員会案がISOの国家代表投票で否決された経緯を扱っている。スレでは、そもそも言語を「所有」しているのは誰かという論点から、設計者が一人で決めるBDFL方式とデザイン・バイ・コミッティーのどちらが優れているか、PythonやRustの歴史を引きながら議論が広がった。
Herb Sutter「言語の生みの親とその『所有者』が激しく対立するとき」[PDF]
出典: isocpp.org / 元記事はこちら
ちょっと言いたいだけなんだけど、SutterはBjarneの立場を繰り返しているだけでも正しいと思う。それに彼は、ハードウェア性能の進歩と並行処理への移行について、個人的に最も影響力があったと思う論文の著者でもある: https://www.cs.utexas.edu/~lin/cs380p/Free_Lunch.pdf
>>3
C++委員会のメンバー(主にBoehm、あとStroustrupも)は、関数型言語以外の領域で並行処理のためのしっかり規定されたメモリモデルを与えてくれたことでも大いに評価されるべきだと思う。RustはC++11のメモリモデルをほぼそのままコピペしている。Rustの『恐れを知らない並行処理』は、先人の積み重ねに大きく依存している。
C++委員会のメンバー(主にBoehm、あとStroustrupも)は、関数型言語以外の領域で並行処理のためのしっかり規定されたメモリモデルを与えてくれたことでも大いに評価されるべきだと思う。RustはC++11のメモリモデルをほぼそのままコピペしている。Rustの『恐れを知らない並行処理』は、先人の積み重ねに大きく依存している。
>>3
言語はまだマルチコアに正しく進化していないと思う。『今日の言語』の理想形がどんなものか考えてみたんだけど、核となる考え方の一つは、並行コードを明示的にして設計の表に出すことだと思う。たとえばWebサーバーのメインコードはこんな感じになるかもしれない:
spawn(on_core: 0) {
await receive_packet(input)
}
または『num_cpus』でループして同じことをやり、共有メモリのリソースはCPU番号でハッシュ分けする、みたいなやり方もある。
言語はまだマルチコアに正しく進化していないと思う。『今日の言語』の理想形がどんなものか考えてみたんだけど、核となる考え方の一つは、並行コードを明示的にして設計の表に出すことだと思う。たとえばWebサーバーのメインコードはこんな感じになるかもしれない:
spawn(on_core: 0) {
await receive_packet(input)
}
または『num_cpus』でループして同じことをやり、共有メモリのリソースはCPU番号でハッシュ分けする、みたいなやり方もある。
>>3
その論文は結局完全に間違っていたよ。シングルコアの性能はその後も大きく伸び続けたし、今でもほとんどのソフトウェアは並行処理をほぼ意識せずに書かれている。
その論文は結局完全に間違っていたよ。シングルコアの性能はその後も大きく伸び続けたし、今でもほとんどのソフトウェアは並行処理をほぼ意識せずに書かれている。
Stroustrupの反対意見リストは、自分にはかなり筋が通っているように見える: https://www.stroustrup.com/Contracts_fundamental_flaws.pdf
>>4
最後の方を読むと、文章の一部がLLM由来だというのがかなりはっきり分かる。他の反対意見についてのごく短いまとめなんだけど、なぜ本人(たち)が自分で書かずにLLMに頼ったのか気になる。
最後の方を読むと、文章の一部がLLM由来だというのがかなりはっきり分かる。他の反対意見についてのごく短いまとめなんだけど、なぜ本人(たち)が自分で書かずにLLMに頼ったのか気になる。
>>4
同意。契約(Contracts)の仕組みは色々な理由で前から好きじゃなかった。賛成派は、実際に役立つ機能というより、PL(プログラミング言語)系の博士研究のかゆいところを掻くためにやっている感じがする。既存の`assert`文があるのに、なぜこれが必要な機能なのか、自分は今も納得できていない。
同意。契約(Contracts)の仕組みは色々な理由で前から好きじゃなかった。賛成派は、実際に役立つ機能というより、PL(プログラミング言語)系の博士研究のかゆいところを掻くためにやっている感じがする。既存の`assert`文があるのに、なぜこれが必要な機能なのか、自分は今も納得できていない。
>>4
この論文、すごくClaudeっぽい文体だ。
この論文、すごくClaudeっぽい文体だ。
驚いた。どこかの誰かが機能を思いついたのに、それがC++に取り込まれなかったなんて!
>>7
C++に取り込まれなかったアイデアは山ほどある。みんながどんな提案をしているかにあなたが全く注意を払っていないから、単に聞いたことがないだけだよ。
C++に取り込まれなかったアイデアは山ほどある。みんながどんな提案をしているかにあなたが全く注意を払っていないから、単に聞いたことがないだけだよ。
KernighanとRitchieはC89より新しい規格向けにC言語の本を改訂しなかっただけじゃなく、Kernighanは2023年に(AhoとWeinbergerと一緒に)『Awkの本』を改訂したことでそれを裏付けた。まるで『Cはもう終わっていて、Awkの方がまだ書く価値がある』と言っているみたいだ。
>>8
KNR(Kernighan & Ritchie)は昔からたくさんの本を書いているけど、長年改訂していない本はいくつもあるよ。
KNR(Kernighan & Ritchie)は昔からたくさんの本を書いているけど、長年改訂していない本はいくつもあるよ。
36年間ずっと意見が一致し続けているのは良いことじゃない。誰も何にもノーと言っていないということで、巨大で汚れた雪玉が山から転がり落ちている状態だということだ。
>>9
その見立ては正しくないと思う。実際、この機能の以前のバージョンはC++20から外されたことがある。
その見立ては正しくないと思う。実際、この機能の以前のバージョンはC++20から外されたことがある。
『所有者』? 言語を所有している人なんていない。人々は実用的で現実的かつ必要だと思うことをやるだけだ。委員会が言語を所有していると思っているなら、それは思い上がりで、開発者との関係を誤解している。
>>10
それは言葉の問題にすぎない。委員会はC++の標準とその将来を所有している。思い上がりではない――そうした統治組織が無ければ、分裂か停滞のどちらかになり、どちらも大抵は致命的だ。
それは言葉の問題にすぎない。委員会はC++の標準とその将来を所有している。思い上がりではない――そうした統治組織が無ければ、分裂か停滞のどちらかになり、どちらも大抵は致命的だ。
>>27
いや、標準を所有しているのはISOで、ISOはちょうど委員会が出した草案を否決したばかりだ。
いや、標準を所有しているのはISOで、ISOはちょうど委員会が出した草案を否決したばかりだ。
>>27
言語を所有していると言うのは思い上がりだ。彼らが所有しているのは自分たちの標準にすぎない。それでも主要なコンパイラはみんな違うものを実装していて、それでも全部『C++コンパイラ』と呼ばれている。
言語を所有していると言うのは思い上がりだ。彼らが所有しているのは自分たちの標準にすぎない。それでも主要なコンパイラはみんな違うものを実装していて、それでも全部『C++コンパイラ』と呼ばれている。
>>6
『契約の強制を保証すること』は項目Dに追加すべきだと思う。それが、国家代表の投票をノーからイエスに変えうる唯一の技術的提案だと明示されているからだ。
『契約の強制を保証すること』は項目Dに追加すべきだと思う。それが、国家代表の投票をノーからイエスに変えうる唯一の技術的提案だと明示されているからだ。
>>11
C++11は、それより前にあったJavaのメモリモデルからかなり多くを借用している。結局はみんなが互いから、何がうまくいって何がうまくいかないかを学び合っているだけだ。
C++11は、それより前にあったJavaのメモリモデルからかなり多くを借用している。結局はみんなが互いから、何がうまくいって何がうまくいかないかを学び合っているだけだ。
>>11
細かい話だけど、RustはいまC++20のメモリモデルに従っている。最近気づいて自分がつまずいた顕著な違いの一つは、以前のバージョンと違って『リリースシーケンス』がそれ以降の書き込みによって拡張されない、という点だ。
細かい話だけど、RustはいまC++20のメモリモデルに従っている。最近気づいて自分がつまずいた顕著な違いの一つは、以前のバージョンと違って『リリースシーケンス』がそれ以降の書き込みによって拡張されない、という点だ。
>>18
*(本物のポインタ)と&(『参照』と呼ばれているけど、正直に言えば再代入できないポインタ――ただしUB(未定義動作)を使えば“完全に”再代入できてしまう)を忘れないでほしい。
*(本物のポインタ)と&(『参照』と呼ばれているけど、正直に言えば再代入できないポインタ――ただしUB(未定義動作)を使えば“完全に”再代入できてしまう)を忘れないでほしい。
>>34
これで笑ってしまった。
これで笑ってしまった。
>>22
『ここから何を結論づけるべきか…C++は複雑で奥が深い』。そう、それがまさに言いたいことだ。ゼロから再設計できるなら、同じことを実現するためにこの複雑さの多くは必要ないはずだ。
『ここから何を結論づけるべきか…C++は複雑で奥が深い』。そう、それがまさに言いたいことだ。ゼロから再設計できるなら、同じことを実現するためにこの複雑さの多くは必要ないはずだ。
>>37
委員会はISOの一部だ。より大きいISOが、より小さいISOを否決したということ。両方とも同じ体制の中にいる。WG21は単にISOのC++サブグループにすぎない。
委員会はISOの一部だ。より大きいISOが、より小さいISOを否決したということ。両方とも同じ体制の中にいる。WG21は単にISOのC++サブグループにすぎない。
>>38
BDFL(慈悲あるべき終身独裁者)は規模にも耐久性にも向いていない。人には時間と注意を奪い合う色々な物事がある。年を取るし、たぶんいつかは引退したくなるし、最終的には死んでしまう。10年や20年を超えて続けたいなら、BDFLは良い選択ではない。
BDFL(慈悲あるべき終身独裁者)は規模にも耐久性にも向いていない。人には時間と注意を奪い合う色々な物事がある。年を取るし、たぶんいつかは引退したくなるし、最終的には死んでしまう。10年や20年を超えて続けたいなら、BDFLは良い選択ではない。
>>43
それで言うと、Pythonは8年ほど前にBDFLをやめている。
それで言うと、Pythonは8年ほど前にBDFLをやめている。
>>43
Linusは90年代後半から2000年代にかけてスケールしなくなった。その頃に『中尉』たちがより大きな権限を持つようになり、非公式な継承ラインが多少なりとも形成された。BDFLは、自分のビジョンを共有する信頼できる協力者の中から、自分の後継者を育てることができる。
Linusは90年代後半から2000年代にかけてスケールしなくなった。その頃に『中尉』たちがより大きな権限を持つようになり、非公式な継承ラインが多少なりとも形成された。BDFLは、自分のビジョンを共有する信頼できる協力者の中から、自分の後継者を育てることができる。
他サイトの新着
>>38
WebGPUはまだ初期段階だ。Safariはバージョン26でようやく有効にしたばかりだから、ウェブの大部分にとってはまだ1年しか経っていない。もう少し時間をあげよう。
WebGPUはまだ初期段階だ。Safariはバージョン26でようやく有効にしたばかりだから、ウェブの大部分にとってはまだ1年しか経っていない。もう少し時間をあげよう。
>>38
『あるいはPython、D、Zig、Odinなどのように、BDFLモデルを採用する手もある』。PythonにBDFLはいないし、それ以外のものはおもちゃレベルだ。[1] Guidoは2018年に退任し、PEP 572を巡ってコミュニティと長く対立した末、2020年には完全に関与をやめた。
『あるいはPython、D、Zig、Odinなどのように、BDFLモデルを採用する手もある』。PythonにBDFLはいないし、それ以外のものはおもちゃレベルだ。[1] Guidoは2018年に退任し、PEP 572を巡ってコミュニティと長く対立した末、2020年には完全に関与をやめた。
>>45
『PythonにBDFLはいない』――ありがとう、その点は認めて、むしろBDFLの『継承』がうまくいった成功例として受け取ることにするよ。
『PythonにBDFLはいない』――ありがとう、その点は認めて、むしろBDFLの『継承』がうまくいった成功例として受け取ることにするよ。
>>39
標準こそが言語だ。これもやっぱり言葉の問題にすぎない。
標準こそが言語だ。これもやっぱり言葉の問題にすぎない。
>>46
標準というのは、言語の理想化されたバージョンを概念的に説明したものにすぎない。実装こそが言語そのものだ。標準に準拠しているはずの自分のコードがコンパイルできなかったときに、それを学ぶことになる。
標準というのは、言語の理想化されたバージョンを概念的に説明したものにすぎない。実装こそが言語そのものだ。標準に準拠しているはずの自分のコードがコンパイルできなかったときに、それを学ぶことになる。
>>50
『Pythonは30年以上の歴史があるのに問題なく回っている。誰もGuidoを叩き続けたりしていない』。Guidoはその役職を8年前に退いている。今は5人からなるスティアリング・カウンシルと、コア開発者たちが主な維持・意思決定者になっている。
『Pythonは30年以上の歴史があるのに問題なく回っている。誰もGuidoを叩き続けたりしていない』。Guidoはその役職を8年前に退いている。今は5人からなるスティアリング・カウンシルと、コア開発者たちが主な維持・意思決定者になっている。
>>53
それに、Guidoの退任には『周りから叩かれ始めたこと』も大きく関係していて、それは以前は自分が拒否していた言語機能(PEP 572)を後になって承認したことと結びついている。とはいえ、『デザイン・バイ・コミッティーはひどい』という元の意見には同意するし、スティアリング・カウンシルがそれ以降に下したいくつかの判断にも感心していない。
それに、Guidoの退任には『周りから叩かれ始めたこと』も大きく関係していて、それは以前は自分が拒否していた言語機能(PEP 572)を後になって承認したことと結びついている。とはいえ、『デザイン・バイ・コミッティーはひどい』という元の意見には同意するし、スティアリング・カウンシルがそれ以降に下したいくつかの判断にも感心していない。
この話題の背景と論点
ここで言う「Contracts」はC++26に向けて議論されている事前条件・事後条件の検査機能で、Bjarne Stroustrup氏は「保証された強制(guaranteed enforcement)」の仕様に性能や実装面の欠陥があるとして反対の論文を公開した。スレが割れたのは、ISOの国家代表投票で委員会案が否決された経緯をどう評価するかという点で、一部は「設計は是々非々で健全」と見る一方、デザイン・バイ・コミッティーの限界を指摘する声もあった。あわせて、BDFL(終身の慈悲ある独裁者)モデルの比較としてPythonのGuido van Rossum氏が2018年に退任した経緯や、RustがC++11以降のメモリモデルを引き継いでいる点も語られたが、これらは今回の対立とは別の論点であり、混同しないよう注意したい。
※本記事は海外掲示板 Hacker News のスレッド「Herb Sutter: When a language’s creator and its owners strongly disagree [pdf]」から抜粋し、編集部で日本語に意訳したものです。訳文の責任は当サイトにあります。
この記事のリアクション
まだコメントはありません。