代替実装問題（Alternative Implementation Problem）

 (pointersgonewild.com)
2 ポイント 投稿者 GN⁺ 2024-05-13 | 1件のコメント | WhatsAppで共有

代替実装の問題

筆者は、ソフトウェアの世界で繰り返し発生する代替実装の問題について語っている。筆者の経験は主に動的型付けプログラミング言語の最適化に関するものだった。

  • PyPyプロジェクトはPython向けの高度なJITコンパイラを開発したが、実際にはほとんど使われていない。Pythonが新機能を追加し続けて変化していくため、PyPyがそれに追いつくのは難しかった。
  • LuaJITは高く評価されているが、Lua言語が新機能を追加し続ける中で、LuaJITはいくつものバージョン分遅れている状況にある。
  • TruffleRuby JITは最も印象的な性能を誇っていたが、CRubyと比べて機能互換性が不足しており、限定的な展開にとどまった。

教訓: 代替実装は失敗せざるを得ない選択

  • 代替実装を作ると、公式実装の変化に従属せざるを得ない。
  • 公式実装はプロジェクトの方向性を制御し、代替実装はただ追従するしかない。
  • 伝統的にインタプリタ言語のJIT実装を作る場合、インタプリタに新機能を追加するほうがはるかに速いため、公式実装がJITを追い越してしまうことがある。

YJIT: CRuby内部にRuby JITコンパイラを実装

  • YJITはもう1つのRuby JITだが、CRubyそのものの内部に実装することを選んだ。
  • これによりYJITは最初からすべてのCRuby機能と100%互換にできた。
  • 現在ではRubyの公式JITとなり、Shopify、Discourse、GitHubなどで導入されている。

より広い観点での教訓

  • 既存言語と似ているが互換性のないCrystal言語も、限定的な成功にとどまっている。
  • 既存言語に似て見えても互換性がないものは、人々を混乱させるだけだ。
  • 新しいプログラミング言語を作るときは、既存言語のサブセットになろうとするのではなく、自分自身の道を進むのがよい。
  • そうすることで、他の実装の性能や機能、ライブラリに縛られず、自分自身の速度と方向で進化させることができる。

GN⁺の見解

  • この記事で述べられている「代替実装問題」は、プログラミング言語に限らず、各種ソフトウェアやハードウェアシステムを作る際にも注意すべき点である。
  • 安定性と互換性だけを重視すると、イノベーションは難しくなり得る。しかし実際のユーザーの視点では、互換性は非常に重要な要素でもある。新技術とユーザーフレンドリーさのバランスを取ることが重要だ。
  • 長期的な観点から、新しく作るプロジェクトが「誰と互換であるべきか」「どの方向へ進化させるのか」を十分に考える必要がある。
  • 新しいプログラミング言語を作るとき、既存言語と文法だけを似せるのは混乱を増やすだけだ。むしろ自分自身の哲学と方向性を明確にするのが望ましい。
  • 市場での競争よりも、創造的で独創的なソリューションを打ち出すほうが、長期的には成功する可能性が高いように見える。

関連記事

1件のコメント

 
GN⁺ 2024-05-13
Hacker Newsの意見
  • 新しい代替実装を開発する際、既存バージョンとは異なるアーキテクチャになると、既存バージョンでは簡単なことが新バージョンでは非常に難しくなることがある。たとえば proprietary ソフトウェアが section 単位で load/save する一方で、新バージョンが文書全体をメモリに載せる方式なら、添付ファイル追加機能をサポートするために新バージョンのアーキテクチャ全体を修正しなければならない可能性がある。
  • 既存実装の代替として位置付けるのは負け筋の命題である。"Python + X" とマーケティングするプロジェクトは正式版と競争しにくい。しかし、MicroPython のように microcontroller 向けに設計されていて CPython と競合せず、別の microcontroller プログラミング環境と競争するのであれば成功できる。
  • 互換性をうたっていても、実際には古い言語機能に対してさえ互換性が低い場合が多く、これが代替実装が失敗する理由になる。Ruby や Python では native C extension へのサポート不足がその一例である。
  • Startup の創業経験によれば、基本機能の追求ではなく、アーキテクチャがエンタープライズ向け機能をサポートできることを示し、差別化された何かに集中すべきだった。
  • 開発者は JIT よりも言語機能と相互運用性を重視する。既存プロジェクトに貢献するより自分の並行プロジェクトを作るほうが簡単だが、それが誰のためのものなのか自問すべきである。自己陶酔に陥らないよう注意しなければならない。
  • Wrapper コードは標準から外れ、文書化も不十分で苦痛をもたらす。どうしても必要な機能だけを追加し、デフォルトを使うのがよい。
  • MySQL 互換性のために TiDB が経験した問題と似ている。理論上は開かれたプロトコルだが、実際には Chrome が主導している。
  • Kotlin への言及はなかった。