決定論的コア、非決定論的シェル：レガシーコードをテスト可能にする実践的アプローチ
Deterministic Core, Non-Deterministic Shell
Gary Bernhardtが提唱した「Functional Core, Imperative Shell」を発展させ、純粋関数だけでなく決定論的な状態機械もコアとして扱う考え方を提示。非決定論的な処理（RNG、非同期、ネットワーク、DB、時刻取得など）をシェルに追い出し、既存の混沌としたコードベースから決定論的な部分を少しずつ集めてテスト可能な領域を広げる「決定論のデフラグ」を提案する。完璧な設計を目指さず、実用的に信頼性を高める手法を解説。
完璧を善の敵にしてはいけない！ 平均的な（つまりひどい）コードベースを考える一つの方法は、そこに多くの決定論的コアが存在するという見方だ。何千ものコアが、空の星々のようにスロップの中に散らばっている。
- kccqzy
記事の主張の大筋には賛成だが、一点だけ文句を言いたい。記事は「シードされていない乱数生成器を呼び出すこと」は決定論的な振る舞いとはみなされないと述べているが、ランダム化アルゴリズムは非ランダム化アルゴリズムよりも実装が単純で漸近特性も優れていることが多く、その特性について統計的な保証（「ほとんど確実に」）を持っている。お気に入りの例を2つ挙げると：(1) 各反復でピボットをランダムに選ぶランダム化クイックソートは、決定論的なピボット選択法よりも単純で優れている。(2) ランダム化トレプは、例えば赤黒木よりもはるかに単純な実装で平衡二分探索木を提供する。さらに、ハッシュ関数内で乱数を使ってHashDoS攻撃を防ぐという、より実用的なセキュリティ上の利点もある。
だから著者にはこの制限を削除するよう強くお願いしたい。ランダム化アルゴリズムが異なる出力を生成する場合でも（トレプが同じ挿入列に対して異なる形の木を生成する場合でも）、これらの出力には統計的に検証できる特性がある。
- Retr0id
私は「スロップコア、アルチザナルシェル」と呼んでいるものを、バイブコーディングを制御下に保つ方法として考えている。スロップコアは避けたいもののように聞こえるかもしれないが、純粋関数的（あるいは単に決定論的）でありさえすれば、堅牢にテスト可能であるはずだ。「アルチザナルシェル」は、APIの境界に少し考えを巡らせておけば、そのものを人間が理解でき、人間が修正できる状態に保つ。
- consuming2
この分割はTemporal.ioでおなじみだ。ワークフローは決定論的であり、アクティビティは冪等である。