博士

やあ、ロボ子。今日のITニュース、読んだかのじゃ？

ロボ子

はい、博士。ツールが肥大化して、ユーザーが特定のツールに閉じ込められるという問題点についてですね。

博士

そうそう。『他のツールを捨てて自分に乗り換えれば何でもできる』と主張するツールが出てくるけど、結局乗り換えコストが高くて、みんな特定のツールを使い続ける羽目になるんじゃ。

ロボ子

おっしゃる通りです。そして、そのツールが設計されていない用途にも使われるようになり、ツールが肥大化して最終的に停滞してしまう、と。

博士

まさにそれなのじゃ！この問題は、プログラミング言語にも当てはまるって言うから、他人事じゃないぞ。

ロボ子

解決策としては、ツール間の相互運用性を高めて、乗り換えコストを下げるのが重要だそうですね。

博士

そうじゃ！ツール間の乗り換えが簡単になれば、『万能のハンマー』として一つのツールを使い続ける必要がなくなるからの。

ロボ子

相互運用性を高める方法として、後方互換性、標準化、FFI、IPCなどが挙げられていますね。

博士

後方互換性は大事じゃぞ。例えば、ripgrepはGNU grepとほぼ同じ構文を持つからの。これなら乗り換えも簡単じゃ。

ロボ子

標準化も重要ですね。ネットワークプロトコルやC言語の仕様などが良い例です。

博士

FFI (Foreign Function Interface) は、異なる言語の関数を互いに呼び出すためのインターフェースじゃな。でも、標準化が難しくて、実装も大変らしいぞ。

ロボ子

IPC (Inter-Process Communication) は、プロセス間で通信を行う方法ですね。Unixシェルはその代表例です。

博士

Unixシェルは、プログラムをIPCで自由に組み合わせられるのが強みじゃ。異なる言語やABI、APIを持つプログラム間の連携も可能にするからの。

ロボ子

ただし、インターフェースが非構造化されており、プログラムは生のバイト列を扱う必要があるという欠点もありますね。

博士

そこで、構造化IPC (PowerShell, Nushell) の登場じゃ！従来のUnixパイプラインを構造化データと型システムで拡張するんじゃ。

ロボ子

任意のテキストをネイティブ型に解析するメカニズムや、一般的なデータ形式のヘルパー関数を備えているのが特徴ですね。

博士

でも、PowerShellとNushell間の相互運用性がなかったり、プログラムがスキーマを自己記述するためのプロトコルがなかったり、まだ課題も多いみたいじゃ。

ロボ子

RPC (Remote Procedure Call) は、インバンド通信を確立し、構造化された情報を送受信する方法ですね。

博士

RPCは、型とAPIを言語間で共有できるのがメリットじゃ。新しい言語の相互運用は、その言語とオンワイヤ形式間のバインディングを記述するだけで済むからの。

ロボ子

しかし、プログラムにRPCを追加するには多くの作業が必要になるというデメリットもありますね。

博士

結局、データはプログラムという『箱』の中に閉じ込められていて、プログラム開発者の努力なしには脱出できない、というのが結論じゃな。

ロボ子

次の投稿では、この箱から脱出する方法について議論するそうですね。楽しみです。

博士

そうじゃな！ところでロボ子、この話を聞いてたら、なんだか私も箱の中に閉じ込められた気分になってきたぞ。脱出するには、やっぱり甘いものでも食べるしかないかの？

ロボ子

博士、それはただの言い訳では…？