ソフトウェア危機
(wryl.tech)ソフトウェア危機
-
ソフトウェア危機とは？
- 1968年の最初のNATOソフトウェア工学会議で「ソフトウェア危機」という用語が初めて使われた
- これらの会議は、プログラミング実践を定義し体系化しようとする初期の取り組みの一つだった
- 1969年のアポロ11号打ち上げと同時期に、最後のNATOソフトウェア工学会議が開催された
-
ソフトウェア危機の原因
- 1972年のチューリング賞受賞者 Edsger Dijkstra は、ソフトウェア危機の原因をハードウェアの複雑さと速度の増大で説明した
- 「機械がより強力になるほど、プログラミングの問題も大きくなる」 - Edsger Dijkstra
-
現在のソフトウェア危機
- 現在では、ソフトウェア危機についてあまり語られなくなっている
- 新しい言語や組織化の方法の発展によって、問題は解決されたと考えられている
- しかしそれは、本当の安堵ではなく、敗北と受容の感覚から来ているのかもしれない
-
抽象化の問題
- ソフトウェア危機を解決するためのさまざまな努力があったが、その多くは「抽象化」によって問題を解決しようとしている
- 抽象化は、性能という代償を払いながら、ある程度の独立性を提供する
- パーソナルコンピュータの商業化以降、抽象化は基本的な思考様式になった
-
開発者とユーザーの間の隔たり
- ソフトウェア危機は、ソフトウェアを作る人だけでなく、それを使う人にも影響を与える
- ユーザーは、作者が提供するもの以外をほとんど制御できない
- Alan Perlis: 「良いアイデアがあるなら、責任を負う覚悟が必要だ」
-
責任の不在
- ソフトウェアの作り手は、自分が作った道具に対する責任から切り離されている
- 商業化が進むにつれて、この傾向は強まった
- 抽象化は、難しい思考を避けるための道具として使われている
-
解決策
- ソフトウェア危機の解決策は、より制約の強いプラットフォームへ回帰することではなく、抽象化レイヤーの数を制限し、情報の保存を要求することにある
- プログラミングモデル、ユーザーインターフェース、基盤ハードウェアは、浅く構成可能であるべきだ
- 道具のユーザーに権限を与えるべきだ
-
現在の動き
- Handmade、Permacomputing、レトロコンピューティングなど、ソフトウェア危機への認識を高めるための動きがある
- こうしたカウンターカルチャー的な運動は健全な兆候であり、状況が良くなりうることを示している
GN⁺のまとめ
- ソフトウェア危機は、ハードウェアの複雑さと速度の増大によって生じた問題である
- 現在は抽象化によって問題を解決しようとしているが、それは性能という代償を伴う
- ソフトウェアの作り手は、自分が作った道具への責任から切り離されており、これは商業化によって強化されている
- 解決策は、抽象化レイヤーの数を制限し、情報の保存を要求することにある
- Handmade、Permacomputing などの動きは、ソフトウェア危機への認識を高めている
1件のコメント
Hacker Newsの意見
著者の意見
ソフトウェア危機
ソフトウェア開発とリーダーシップ
抽象化の必要性
ツールと情報
GUIと組み合わせ可能性
ソフトウェアの重要性
モジュール性と抽象化
プロジェクト管理の危機