ハクソク

世界を動かす技術を、日本語で。

ソフトウェアの劣化

2025年8月6日原文(permacomputing.net)

概要

  • Software rot は環境変化によるソフトウェアの劣化を指す概念
  • 継続的なメンテナンスが前提となる文化の問題提起
  • 安定した環境 への依存が長寿命ソフトウェアの鍵
  • 古典的プラットフォームは 保守不要 な場合が多い
  • 新しい環境では メディアアーキオロジー 的な対応が必要になることも

ソフトウェアロットと環境信頼性

  • Software rot とは、ソフトウェアが依存する環境の変化によって動作不良や劣化が発生する現象
  • 例として、10年前に作成されたプログラムが ライブラリの後方互換性欠如 により動作しなくなるケース
  • この考え方は「 継続的な保守が必須」という文化を助長
  • より良いアプローチとして、ソフトウェアが依存する 環境自体の信頼性 に着目する視点の提案
  • 不安定な基盤（例:頻繁に更新されるプラットフォーム）への構築は 沼地に家を建てる ことに例えられる

安定したプラットフォームの重要性

  • 実際には、 沼地（アクティブな開発環境） に構築せざるを得ない場合も多い
  • それでも、 静的で堅固な仕様 を持つ「ベッドロック」プラットフォームとの互換性確保が有効
  • ゲームやデモなど、リリース後の 保守を前提としない ソフトウェア文化では特に重要

古典的プラットフォームと現代環境の違い

  • DOS や NES 等のクラシックプラットフォーム向けプログラムは、リリース後の 追加保守不要 が一般的
  • 一方、 Linux のような現代的環境では、10〜20年後には 動作不能 となるケースが多発
  • その結果、 特定バージョンの古いライブラリ を探し出すなどの メディアアーキオロジー的作業 が必要になる場合も

まとめ：ソフトウェアの長寿命化戦略

  • 安定した環境への依存 が、ソフトウェアの長期安定運用の鍵
  • 継続的保守が難しい分野では、 仕様固定・環境固定 のアプローチが有効
  • ソフトウェア文化や用途に応じた 環境選択の重要性

Hackerたちの意見

これとリンディ効果は、プロジェクトで何を使うかを選ぶ際に大きく影響してるんだ。メンテナンスフリーにしたいプロジェクトでは、特別なASCII/txtのサブセット、SQLite、Perl、Bash、PHP、HTML、JS、CSSを選んでる。選んだサブセットは、これらの言語の中で最も長く残っている部分なんだ。リンディ効果を参考にして、20年間の異なるバージョンで動くスタック/フレームワークを作ったから、今後20年間も壊れずに動き続ける可能性が高くなってるよ。

└

同じような理由とコードサイズやハッカビリティを考慮して、最近はほぼ常にLuaエコシステムを選んでるね。: https://akkartik.name/freewheeling

└

このドグマ的なアプローチは、BashやPerlのような使いにくいツールを使うことでエルゴノミクスを失うことを意味するんだ。だから、将来のためにほとんど得られない小さな利益のために、常にそのコストを負担しなきゃいけないんだよ（結局、その効果は広い仮説に過ぎないからね）。

└

プロジェクトが複雑になるにつれて、完璧な選択をするのが難しくなってきてるね。シンプルな製品でも、iOS、Android、ウェブ、バックエンドなど、いろいろなものを構築する必要があるから。html/jsに頼れる部分もあるけど、実際にはモバイルアプリは数年ごとに書き直されることが多いよね。私の考えでは、早めに問題を浮き彫りにすることに焦点を当てる方が有益だと思う。バグや遅延、リグレッションがユーザーに影響を与える前に知りたいから、私たちが書くものはすべてTDDを使って書いている。でも、ユニットテストは環境に結びついているから、一緒に「腐る」んだ。だから、プロジェクトがオンラインの間は、モニタリングや統合テスト、ブラックボックステストを早い段階で設定して、ずっと動かし続けるようにしているよ。

└

PHPが大好きなんだけど、7.4あたりから言語に破壊的な変更を加えるのがかなり好きになってきたみたい。最近では、古いバージョンと新しいバージョンのランタイムを同時に満たすことができないような変更もあるし。毎回のメジャーリリースの後に、何週間もかけて修正作業をする羽目になってる。

ソフトウェアのユーザーであり教師として、ソフトウェアの劣化についてよく考えるんだ。心配なのは、劣化が置き換えではなく追加によって進行する傾向があること。新しい機能が追加される一方で、アーキテクチャの根本的な限界は放置されている。Blenderが内輪のジョークから本物の競争相手に成長した理由は、2009年から2011年の間に行われた痛みを伴うリファクタリングなんだ。それに対して、After Effectsのコードが今や30年以上も前のものだってことを実感するよ。ネイティブトラッカーは遅くて古くて、最もシンプルなタスク以外には使えない。トラッキングは、実に不格好な統合ハックを通じて、サブライセンス版のMochaに外注されて「改善」された。すべてを捨てて再スタートするのも良いことだと思う。AppleがOSXで成功したように（スティーブ・ジョブズがAppleを離れてNextを始めた時のように）。でも、Blackberryが似たようなことを試みて、ほとんどの魔法を失ったことも覚えてる。

「工業用海洋グレードのコード劣化耐性」に関して、Microsoftより優れたエコシステムはないよ。20年前にコンパイルした同じ.NETウェブアプリのコードを新しいServer 2025で動かせるのは、他にはない素晴らしい体験だし、30年前のVBAマクロがExcel 365で今もちゃんと動いてるのもすごい。後方互換性をうまくやってる会社だね。

└

IBMメインフレームで働いている者として、私は違う意見だ。IBMはおそらく、前方アプリケーションの互換性に関しては最高だよ。笑われるかもしれないけど、ちゃんと見てほしい。

└

私は逆の経験をしたよ。ある年のグローバルゲームジャムでXNAを試してみたんだけど、まあまあ満足してたんだ。でも、次の年にはなくなっちゃった。

└

これが多くのソフトに当てはまると思う。現代のJVMは、20年前のJavaを変なことをしなければまだ動かせるし、Linuxもその頃から大きく変わってない。ウェブは、1996年のスペースジャムのサイトが今でもちゃんと動いてるように、最も広くサポートされている標準化されたプラットフォームの一つだよ（画面が大きくなっただけ）。ソフトウェアの劣化って本当にあるの？確かにあると思うけど、ランタイムの中にはないんじゃないかな。依存関係の可用性や互換性、主にNodeエコシステムに問題があると思う。

└

.NETの経験はないんだけど、信頼できる環境があるって聞いて嬉しいよ。でも、Microsoftに関しては、あんまりいい思い出がないんだ。Windows 95からXP時代の古いプログラムが動かせなくて困ってる。先週も2002年のポイント＆クリックゲームをインストールしようとしたんだけど、ネットのアドバイスは「XPをインストールしろ」っていうのばっかりだった。Windows 7で動かす方法はあったけど、10や11では見たことないな。

Python 2の状況は、私の目を開かせたよ。今でも、特に職場環境ではpy2のものがたくさん残ってるのを見かける。実際、2.7.18のソースを自動で引っ張ってきて、最小構成でビルドするスクリプトを作らなきゃいけないほどだ。

Hacker Newsで議論の続きを見る