ソフトウェアの抽象化は文明を破壊するのか？（2021）
(datagubbe.se)- Jonathan Blowの「抽象化が不可欠なソフトウェアを保守する能力を弱める」という問題意識は、知識継承の観点では有効だが、根拠として挙げられた事例の多くは歴史と文脈を取り違えている
- 「five nines」、堅牢なソフトウェア、技術進歩の停滞、生産性低下をめぐる議論は、消費者向け機器と高可用性システムを区別していなかったり、選択的な事例に依存していたりする部分が大きい
- 低レベル知識の喪失への懸念には一部妥当性があるが、C、アセンブリ、Rust、OSの移植、コンパイラ教育、オープンソース活動は、いまもシステム能力を維持する経路として残っている
- OS、ファイルシステム、ネットワーク、マルチタスク、フレームワークのような抽象化は複雑性を増すが、ハードウェアの変化とユーザーの期待に対応しながら、移植性・生産性・創作へのアクセス性も高める
- 抽象化そのものより、継続的なchurn、ロックされたプラットフォーム、広告・トラッカー・テレメトリ、プライバシーと自由の弱体化のほうが大きなリスクであり、重要なシステムを維持する技術基盤は今後も保存し続ける必要がある
Blowの主張に対する基本的な立場
- Jonathan Blowの講演は、ソフトウェア抽象化が低レベルプログラミング知識の喪失を招き、最終的には不可欠なソフトウェアを保守できなくなって文明崩壊につながり得る、という流れになっている
- 知識継承の重要性には同意するが、その主張を支えるには事例と歴史的文脈が正確でなければならない
- 中心的な反論は、Blowの事例が誤解、選択的な事例、逸話的証拠に大きく依存しており、コンピュータ史の一部を見落としているという点である
「five nines」と堅牢性をめぐる議論
- Blowは、過去のコンピュータシステム販売では「five nines」、つまり99.999%の稼働時間が品質を示す宣伝文句として使われていたが、今日のノートPCはそれに達していないと主張する
- five ninesが年間ダウンタイム約5分を意味する点は正しいが、この指標が消費者向けノートPCやワープロソフトの販売に使われていたという主張は誤りだと見る
- five ninesは通常、911のような緊急対応交換台、病院システム、金融取引処理といった領域に適用される
- ダウンタイムに含まれない状況を詳細に定めた長期契約とともに使われることが多い
- IBMやAmazonのような企業はいまもこうしたシステムとサービスを販売している
- 堅牢なソフトウェアは何十年も登場していないという主張にも反例がある
- iPhoneは数週間から数か月、再起動なしで動作できる
- Novellのファイル・プリントサーバーには16年の稼働時間という事例がある
- Unix、Windows、VMSの機器やIBM iのようなターンキーシステムも、長期可用性の事例として言及される
技術進歩と生産性への反論
- 「テクノロジー企業はもはや技術を押し進めていない」という言葉には一部同意するが、金銭をより重視する企業は過去にも存在した
- ファイルシステム、Webサーバー、データベース、プログラミング言語のような「退屈な」領域も、継続的に開発され改善されている
- Blowが嫌う抽象化、仮想化、コンテナ化のレイヤーも多くの努力によって改善されており、嫌いだという理由だけで技術進歩ではなくなるわけではない
- Facebook社員の生産性がゼロに近づくという主張は、Facebookの製品をソーシャルプラットフォーム機能としてだけ見る前提に依存している
- Facebookという会社の社員には、法務、会計、グラフィックデザイン、システム管理、研究、人事、中間管理職など多様な職種が含まれる
- Instagram、WhatsApp、Oculus VRのような別事業もある
- Facebookの実際の製品は広告配信プラットフォームであり、プライバシー情報と私的データを収集してターゲティング広告に変える作業は、ユーザー機能としては見えなくても売上として現れる
低レベル知識と抽象化の両面性
- 多くのプログラマーがメモリ割り当てやポインタを扱わずに済む環境を好むという点は事実として認める
- 不要なJavaScriptフレームワークで単純なブログをレンダリングしたり、バンドルされたブラウザ内で遅く動くデスクトップアプリのような過剰な抽象化は問題だと見る
- しかし今日、Cを扱える人や、C・アセンブリコードの記述量は過去より多い可能性がある
- LinuxとNetBSDは、CPUのように見えるさまざまな対象へ継続的に移植されている
- Rustは堅牢性に注力しながらも、ポインタとメモリ管理を提供する
- Harvard CS50は、メモリレイアウト、ポインタ、
malloc()、free()のような内容を公開講義で扱っている
- ガベージコレクションと関数型プログラミングは新しい抽象化ではない
- Lispは1950年代後半にその両方を提供していた
- LispはNASA Jet Propulsion Labのような「ハードコア」な環境でも使われた
- COBOLはBlowの講演では抜けていたが、銀行と金融インフラの基盤をなす高水準言語として、現在の文明水準に重要な役割を果たしている
Ken Thompsonの「3週間Unix」事例
- Ken Thompsonが3週間でアセンブラ、エディタ、基本カーネルを作ったことは、非常に優れた成果として評価される
- ただし、その時点のソフトウェアがどれほど堅牢だったのか、ユーザーフレンドリーだったのか、どのような機能を備えていたのかは明確ではない
- 当時の作業条件と今日の開発者の条件は大きく異なる
- ドキュメント化、コードレビュー、デイリースタンドアップ、バックログ整理、ユーザーストーリー、単体テスト、顧客要件、A/Bテスト、コミットメッセージ、企業のコーディング標準といった要素が、今日の開発には付随している
- オープンオフィスで妨害を受ける環境と、Bell Labs式の個人作業環境も異なる可能性がある
- Thompsonの事例一つは、過去のプログラマー全体がより生産的だったという証拠にはならない
- Thompsonは遅延で有名なMulticsにも参加していた
- IBM OS/360のような大型プロジェクトも長期間遅延し、Frederick P. Brooksはこうした経験をもとに1975年に『The Mythical Man-month』を書いた
ソフトウェアの発展とユーザーの期待
- コンピュータは全体として数十年前より堅牢になっており、プログラマーも少なくとも過去と同程度には生産的だと見る
- ただし一部の場合には、始めることがより複雑になり、初期生産性を下げることがある
- 現代のユーザーは、単純な算術のためにRPNを学んだり、チラシを作るためにtroffの指示子を書いたりしたいとは思わない
- 便利なインターフェースと高度な機能は、抽象化とは無関係に複雑性と開発時間を増やす
- 古いAmiga OSでファイルコピー中にクラッシュし、ハードドライブのパーティションが破損した事例は、過去のシステムが必ずしもより安定していなかったことを示している
- 現代の家庭用コンピュータOSはメモリ保護とジャーナリングファイルシステムを備えており、同じ問題ははるかに起きにくい
- Windows 10 Homeにも欠点はあるが、こうした進歩を含んでいる
「昔はただできた」という主張
-
プログラムのコピーと実行
- プログラムをあるコンピュータから別のコンピュータへコピーして実行することは、同じ対象アーキテクチャとコンパイル条件であれば今でも可能である
- Goでビルドした
slack-termの静的リンクバイナリがRaspberry Pi群で動作した事例がある - ただし、スタンドアロンプログラムが一般的だった時代はC64やPC/XTの頃までさかのぼる必要があり、AmigaのDeluxe Paint IVも複数の補助ファイルとサードパーティ関数ライブラリに依存していた
- 一部のAmigaゲームはファイルシステムを迂回するtrack-loadedフロッピーを使い、当時式のコンテナのように動作していたが、ハードディスクへのインストールとマルチタスクを妨げる欠点があった
-
CPUさえ同じならコードは動くという主張
- 同じCPUで機械語をメモリに載せ、プログラムカウンタを向ければ実行できるという話は、理論上は可能である
- しかしグラフィック出力、サウンド再生、入力処理、ディスク書き込みのような実作業では、ハードウェア差が大きな問題になる
- 過去のZ80ベースのホームコンピュータもCPUは同じだったが、周辺ハードウェアが異なり、実際の移植は難しかった
- むしろBasicのような、より高い抽象化レベルのプログラムのほうが、複数のマシン間でより簡単に移植できた
- AppleがARMベースのデスクトップラインを発売したことで、ベアメタルに直接張り付く方式より、抽象化に依存するほうが新CPUへの移植負担を減らせる可能性がある
-
OSとハードウェアアクセス
- OSはCPUの能力を奪うだけではなく、ファイルシステム、ネットワーキング、マルチタスクのような能力を追加する
- Twitchストリーマーのように、ゲームと他のプログラムを同時に実行する必要があるユーザーは、ハードウェア資源を管理され予測可能な形で分け合うマルチタスクを必要とする
- AmigaとAtariの一部ソフトウェアは、メーカーが提供した仕様と抽象化に従わず、ハードウェアやメモリへ直接アクセスしていたため、メモリやハードディスクのような小さなアップグレードでも動作が壊れた
- 仕様と抽象化に合わせて書かれたソフトウェアは、ハードウェア変更後も販売され続けることができた
-
グラフィック、署名なしプログラム、LSP
- ピクセルを画面に描くことは複数の言語で今でも可能であり、Mode 13hもVGA BIOSという初期のハードウェア抽象化レイヤーを通じてアクセスしていた
- 特定のVGAハードウェアに依存したコードは移植可能ではなかったが、Windowsの抽象化を使ったグラフィックプログラムは、Herculesからtrue-color XGAまで多様な環境で動作できた
- 署名なしプログラムの実行も可能であり、WordGrinderを自分でコンパイルして使う事例がある
- Blowの不満の一部は、抽象化よりも、ハードウェア・ソフトウェアベンダーがシステムをロックし、ユーザーの権限を減らす問題により近い
- Language Server ProtocolについてはBlow側に概ね同意するが、LSPは「メソッドをクリックして定義へ移動する」以上の問題を解決する
ゲーム、性能、マルチタスク
- 現代の生産性アプリには、性能低下と深刻な入力遅延を示す事例が多い
- 原因の一部は抽象化だが、より大きな問題は悪いコードと、作業に合わないツール選択にある
- 同じプラットフォームとUIツールキットを使うプログラム同士でも、同じマシン上で体感性能は大きく異なることがある
- Blowが挙げた、ゲームでAlt-Tab後に解像度が復元される問題は悪い体験であり、改善されるべきである
- しかし過去のDOSゲームは、他のプロセスを気にしなくてよかったため単純だった
- Windows 3.1でDoomを遊ぶには、作業を保存し、プログラムを閉じ、Windowsを終了してからゲームを起動する必要があった
- Amigaゲームもフロッピーから起動してマシンを完全に掌握し、OSへきれいに戻れない場合が多かった
- 今日のゲームのマルチタスクは完璧ではなくても、過去より良くなっていると見る
知識喪失と変化の速度
- Blowは、Unityのスプライト管理のような知識が、深い理解ではなく雑学へ変わっていくと見ている
- 現代のソフトウェアとハードウェアの変化速度は、有意義に追随するのが難しいほど速い場合が多いという点には同意する
- しかしこれは抽象化そのものより、時間に対する一貫性とソフトウェア配布モデルの問題により近い
- 4週間ごとに何かを出す流れは、ユーザーが安定した体験を得ることを難しくし得る
- UIを頻繁に変えれば、ユーザーは実際の作業ではなく、変わり続けるインターフェースの細部と戦い続けることになる
複雑性は人が作った問題
- Blowは、複雑性は減らすと決めれば減らせるものであり、抽象化を追加して時間を節約していると錯覚しているのだと主張する
- 適切なフレームワークを適切な用途に使えば、Web開発者にとって大きな助けになり得る
- 同時に、ブラウザでワープロからゲームまであらゆることをしようとしたり、新しいフレームワークが出るたびにすぐ乗り換えたりする姿勢には懐疑的である
- ソフトウェアの複雑性はプログラマーだけの問題ではなく、市場と組織環境も一緒に作り出す
- 社内政治、無意味な会議、難解な時間報告ソフトウェア、外部から定められた締切、厄介な顧客要件、奇妙な管理判断、抽象的要件の工数見積もり、レガシーコードのデバッグなどが、開発者の選択に影響する
- 複雑性は人が作った問題であり、職場内の複雑性を減らせば、長期的にはソフトウェアの複雑性も減らせる可能性がある
若い開発者とエンジン制作能力
- 若いゲーム開発者は自分でエンジンを書いたことがなく、まもなくその能力を集団として忘れてしまうかもしれないというBlowの主張は、滑り坂論法に近い
- C64、Amiga、286 PCを持っていた人の大半は低レベル開発者にはならず、プログラマーにならなかった人も多かった
- 抽象化と既製のゲームエンジンは、低レベルのメモリ管理、ポインタ、アルゴリズムを学ばなくても創作を可能にする
- 今日の子どもたちは店で買うAAAゲームに似たものを作りたいと思っており、現代ゲームへの期待値はC64やAmigaの時代よりはるかに高い
- 低レベル技術を学ぶ道は今も存在する
- Linuxはオープンソースコミュニティを通じて若い開発者を引き込み、Rust、C、C++のようなシステム言語への関心を誘導する
- dwmはCソースコードを修正して設定するウィンドウマネージャである
- CとZ80アセンブリを使う若い開発者、Linuxディストリビューションをゼロから作る人、自分でハードウェアを作る人、研究用OSを現代ハードウェア上で動かすC開発者が存在する
- コンピュータ科学と電気工学の課程は、C、アセンブリ、コンパイラ設計のような基礎を教え続けている
- プログラミングツール、文献、教育動画、MIT OpenCourseWareのような資料へのアクセス性は、過去より安価で良くなっている
最終判断：抽象化より大きな問題
- Blowの結論は技術に適用したサバイバリズムに近く、停電したときに火の起こし方を知っている人が必要だという比喩には共感できる
- 社会は一部のプログラムをほぼ継続的に実行できる能力に依存している
- 失敗すれば世界経済の崩壊や国家保健システムの失敗のような深刻な結果が起こり得る
- 歴史的・現代的記録がますますデジタルで保存されているため、未来にもアクセス可能でなければならない
- 複雑性は脆弱であり、抽象化は有害な無知を作り得る。単純なブログのレンダリングにshadow DOMは必要なく、画像付きIRCクライアントにブラウザの殻を使う必要もない
- しかし、人為的で継続的なchurnも脆弱性を作る大きな原因である
- 「Agile」開発は、本来はきちんと完了しテストされていないものを出さないようにする意図だが、現実には未完成のリリースが出続けている
- 広告、トラッカー、テレメトリシステムは、事実上、設計上のバックドアのように動作し、脆弱性と不安を増やす
- デジタル世界のより大きな問題はプライバシーと自由である
- ハードウェアと直接インターフェースできなくなる理由は、抽象化を選んだからではなく、ますますロックされリモート制御されるプラットフォームだけが残る状況のためかもしれない
1件のコメント
Hacker Newsの意見
Montana Stateでトランジスタから実際のコンピューティングシステムまで扱うシステムの授業を教えているが、授業を始める時点でファイルシステムが何かをきちんと知らない学生もいる
Blowは細部では間違っている部分もあるが、技術系の学生には高校からNAND-to-Tetris式の教育を真剣に検討すべきだと思う
Little Man Computerや簡単な視覚的MIPSエミュレータのような「古い」モデルを使っているが、現実的ではなくても、普通の人が理解できる複雑さで、私たちがどこから来たのかという感覚を与えてくれる
最近勧められる64ビットアーキテクチャの教科書を見ると、ただ笑ってしまうし、技術を根っこまでつなげるのは難しい問題だ
問題は、モバイルOSとソフトウェア会社がユーザーデータをできるだけアプリ内の囲い込まれた庭にしようとしている点にある
すでにファイルで作業していても、既存データを自分のストレージへ「インポート」させ、修正版は新しいコピーとして自分で「エクスポート」または「共有」しなければならない
Montana Stateで産業工学の修士課程にいるが、簡単な偏微分もできない博士課程の学生を毎日相手にしている
前学期の400番台の数学科目では、2つの行列の足し方を知らない学生もいた
コンピュータサイエンスの4年生がファイルシステムを知らないのも変だが、ここで見たとんでもない出来事に比べれば、むしろ控えめに見える
2000年代に初めて大学に通っていた頃とは雰囲気がかなり違って憂鬱だが、来年春の就職市場の見通しについては、むしろ自信が湧いている
名前とは違って、コンピュータサイエンスはコンピュータそのものに関する学問ではなく、コンピュータは必須の道具ではあっても、核心は領域の抽象化と言語モデリング、そしてその応用にある
天文学者が望遠鏡を必要なだけ扱えればよいのと同じように、コンピュータサイエンティストは必要なだけコンピュータを扱えればよい
コンピュータを宇宙の中心に置き、コンピュータサイエンスの出発点にするのは大きな誤りであり、歴史的にも多くの混乱の源だ
「低レベル」プログラミングでさえ結局は抽象化と言語であり、単に議論対象領域の抽象化をシミュレートするためにコンピューティング装置の言語を使っているにすぎない
余暇にMIPSアセンブリを逆コンパイルしているが、小さな関数なら他のツールなしでも、手作業で対応するCコードに戻せる
だが希薄化しているわけではない。教える仕事があり、本とコンピュータがあるからこそ、教師を吟遊詩人と呼ばなくて済むのだ
結局これはブログ記事についての別のブログ記事であり、そのブロガーたちがどれほど「重要」なのかは分からないが、ブログのためのブログという匂いがする
年配のWeb開発者が抽象化を批判するとReact開発者を狙い、Python開発者が批判すると年配のWeb開発者を狙い、C++アプリケーション開発者が批判するとPython開発者を狙う
ファームウェア開発者はアプリケーション開発者を、電気工学者はファームウェア開発者を狙う
自分が知っている水準を基準に過度な抽象化の線を引き、それ以降をすべて「文明を殺す」と呼ぶのは、なかなか大した態度だ
良い指摘が多く、私もその発表を見たので批判は重要だと思う
ただしBlowが「ただ画面にピクセルを描くことができない」と言ったのは正しい
中堅ゲーム会社でゲームエンジンプログラマーとして働いているが、グラフィックスコードを扱える人を採用するのが非常に難しくなっている
DX12のような世代のAPIは、前世代のDX11に比べてプログラマーに要求する水準が途方もなく上がっており、このAPIで何かをすること自体が大きな作業だ
Microsoftも以前のグラフィックスAPI経験なしにDX12を学ぶのは極めて難しいと認めたことがあるが、今は文書の中でその引用を見つけられない
「この種のAPIはグラフィックスカードの限界を押し上げ、ごく低レベルの最適化をしたい開発者向けだ」という反論も一部正しいが、今や業界標準になっており、以前の経験がない人にはほとんど教えられないレベルだ
何かが変わらなければ、採用可能な人材プールは縮小し続けるだろう
ソフトウェアアプリケーションを作るとき、画面にボタンを1つ描くことさえ難しすぎて、ほとんどの人は可能な性能より100倍遅いプログレッシブWebアプリをそのまま使っている
2025年にGUIアプリケーションの最善が本当にJava SwingとQtなのかと思う
全体を束ねる大きな概念があるのに、文書ではほとんどほのめかされず、教育セッションに参加するか、すでに知っている人と話さなければ学べない
サーバー側 JavaScript や React のようなものは、実際にやっていることに比べて、Web ソフトウェア開発を本当にめちゃくちゃにしたと思う
最近の若い人の中には、ブラウザにレンダリングされるものが HTML だという事実すら知らない場合がある。React そのものをブラウザがレンダリングしていると思っている
そのうえ Vercel の CEO は、React を開発における Linux カーネルだと考えるという、まったく馬鹿げたことを言っている
https://news.ycombinator.com/item?id=42824720
vanilla js、jQuery、Knockout、Angular 1 の時代を覚えているくらい長くいるが、当時も基本的な混乱は常にあった
React、場合によっては JSX だけでも、十分合理的に使える
むしろ Vercel、Next、Apollo、Prisma のようなベンチャー投資ベースのツールや、金をもらって Web をゴミで埋めている Web 開発インフルエンサーたちを責める
考えてみると、Notion ボードから疑わしいデータベース選択に至るまで、ソフトウェアを作るあらゆる部分が肥大化している
ただ、ライブラリなしでも十分作業できる人間として、DOM は人類が発明した最悪の API の一つであり、「リアクティブプログラミング」は昔ながらのやり方より優れたモデルだ、と付け加えたい
NextJS は何年分ものツール改善を巻き戻してしまい、Vite よりずっと遅い
静的にビルドした NextJS で、インタラクションがまったくないページが、何もしないために JavaScript 100KB をダウンロードする
Facebook は、そもそも不要にコンポーネントを再レンダリングしないようにすればよいだけのことを、React 用の「コンパイラ」で解決しようとしている
ほぼそのまま置き換えられる Preact と比べると React は巨大で、Facebook がどれほど気にしていないかを示している
HTML はシリアライズ形式であり、ブラウザはそれを使ってメモリ内に DOM を構築する
React は何も HTML にシリアライズせず、DOM に直接レンダリングする
これが間違っているのに高く推薦されているのを見ると、このスレッドが「雲に向かって拳を振り上げる老人」的な性格であることがよく分かる
私の理解では、HTML はブラウザへの入力であり、ブラウザがそれを DOM に変換したうえで、画面描画や入力処理などにつながる
この違いは重要で、React や仮想 DOM 系の JavaScript ライブラリは HTML を作っているのではなく、JavaScript による DOM 操作命令を作っているのだ
Blow の指摘には良い部分も多いが、多くの退行が世代間の漂流や情報エントロピーではなく、意思決定者たちの露骨な 悪意から来ているという点を見落としていると思う
Blow は開発について本当に優れた点を突くことも多いし、完全に的外れなことも多い
成し遂げたことも大きく、聞く価値のあるアイデアもあるが、それと区別がつかない形で提示されるたわ言も多い
文明崩壊の話はそうしたたわ言の一つだと強く感じたし、二度聞いたがほとんど無視した
元記事がより原則的な反論をしてくれてありがたい
Casey Muratori は Blow のまねをしているが、良い部分すらきちんとできていないと思う
Muratori は 10 年前に始めたゲームすら完成させていない
一方、現代のゲームエンジン、Raylib のようなものまで含めれば、週末のゲームジャムでもかなり見栄えのする成果物を作れるし、Blow の Sokoban ゲーム程度なら、特に 10 人ほどのチームなら 6 カ月前後で作れるはずだ
彼のコンテンツを一部見たが、知っているテーマについては謙虚でありながら意見は明確なほうに見えたし、Handmade Hero も見事にやったと思う
Jira がチケットを 1 件表示するのにかかる時間、Slack がチャットルームを切り替える時間、VSCode が普通のタイピング速度についていけないことは、本当に狂っている
彼は広範な批判的発言だけを投げておいて、また何もしに行かずに消えてしまうように見える
すごい業績を成し遂げたとも言いにくく、そこそこ良い仕事をした程度だと思う
リリースしたゲームは 2 本だけで、ゲームというよりパズルに近い。一度クリアすれば、再びやる必要はほとんどない
Braid は悪くないし、The Witness はただの Flow のようなものだ
その後は 10 年間プログラミング言語を作っているが、「まだ完成していない」という理由で公開していない
運よく金を稼いで以降、自分を実際よりはるかに才能のある人間だと見なしているようだ
現代のソフトウェア環境には確かに問題が多く、過度な抽象化も問題だと思う
しかし反対側の極端も良くないし、過去を過度にロマン化する傾向もある
クラッシュや再起動も問題だったし、Amiga のようなシステムにはハードウェアバージョン間の互換性問題があり、互換性を重視したシステムでさえ非互換性から自由ではなかった
最も不安定な現代システムである Windows 11 でも、私のコンピュータは 2010 年以前に使っていたどのコンピュータよりもはるかに安定しており、Windows 95 用ソフトウェアも実行できる
日常的に使えるコンピュータのほうが、そうでないコンピュータより良い
すべての単純化が抽象化というわけではなく、すべての抽象化が単純化というわけでもない。
ただし、単純化を追求するうちに抽象化が生まれることは多い。
抽象化がソフトウェアや文明を殺すとは思わないが、短期的な単純化を名目に作られた粗悪な抽象化は、柔軟性、敏捷性、アクセシビリティを低下させる。
ほぼすべての言語のシンタックスシュガーを見ると、ある時点で、その特定のニュアンスから得られる局所的な単純化が、ツール全体の複雑さの増加を正当化できなくなる地点が来る。
構文の多い言語で人々がミスをするのは、特定の要素一つのせいではなく、複雑な問題をうまく解くためにツールを使うこと自体が難しくなるからだ。
Kotlinでasyncとコルーチンが「スレッドっぽい」コードを扱うときに自分の経験へ加える複雑さと、Elixir/Erlangで同じ種類の問題を扱う方法はまったく違う。
どちらも並列・非同期計算という古くからある問題に対して抽象化と単純化を提供しているが、前者は単純さを何層にも重ね掛けして再び複雑なものを作り、後者はただ動く本当に単純な抽象化に近い。
筆者はより若い世代に属しているように見え、そのためBlowの要点を理解しないまま見落としているようだ。
皮肉なことに、その記事自体がBlowの言っていた例のように見える。
FigmaがFigma自身の悪いUX、UI、プロダクト管理のやり方を標準化して、デザインの世界を前例のない規模で台無しにしていると言うと、若いデザイナーたちから「何も問題ないのに」と困惑した反応が返ってくるのに似ている。
その知識はその環境で育ったからこそあるもので、彼らはそうではなく、文化や経験に相当するものをどこかで学ぶのも簡単ではない。
こうした人格攻撃では、議論に何も付け加えられない。
「ソフトウェアが進歩しているという主張は明白に誤りだ」という言葉とは違って、私は今でも愛用しているAmigaコンピューターをよく使っている。
数週間前、Amigaのハードドライブにファイルをコピーしていたら突然コンピューターがクラッシュしたが、それは私が何か間違えたからではなく、古い家庭用コンピューターのOSがそれほど安定していなかったからだ。
その結果、ハードドライブのパーティションが破損し、OSはファイルシステムを再検証できず、結局パーティションを再フォーマットするしかなかった。
デザインに詳しいわけではないが、Figmaに関する主張がBlowの主張と同じように完全に間違っていることは分かる。
それはノスタルジーが語っているのだ。ユーザーインターフェースには常にひどいものが多かったし、ソフトウェアもあらゆるものも同じだった。
過去の最上位の事例が持つ長所だけが記憶され、ゴミのようなものや、よく設計されたものの失敗までもが忘れられているのだ。
問題は、深く考えられていない抽象化だ。
初稿や最初の試みだと分かるのに、テック業界のスピード崇拝と傲慢さのせいで、何度も磨き込まれる前にそのままリリースされる抽象化が多い。
そうした抽象化が人気プロジェクトの一部になると、他の人たちは「ベストプラクティス」という曖昧な旗印の下、模倣心理でコピーする。
この過程を10〜20年繰り返すと、巨大な混沌が生まれる。
さらに悪いのは、技術によって逆説的に過剰に社会化された社会では、「詐欺師」だと見抜かれまいとする社会的合意が、未熟な解決策を広め続ける点だ。
Jonathan Blowのあの発表が好きで、少なくとも年に1回は見返している。彼は挑発的なことを言っているのではなく、多くの開発者が内心では、自分たちが最善を尽くしてリリースしているわけでも、若い世代をきちんと導いているわけでもないと分かっているから、怒ったり痛いところを突かれたりするのだと思う。
私たちは、新しさの追求が日常的で、時には称賛される文化に到達した。
以前は十分に検討された解決策が文化的な基準だったが、今では実際に良いかどうかに関係なく、新しいものが基準になっている。
Blowの議論の細部を延々と掘り下げることはできるが、証拠は至るところに真正面から現れている。
そして十分に長い時間軸では、それが文明崩壊につながる可能性があり、世の中にある壊れたものの量を見ると、すでにそうなりつつあるとも見なせる。
欠陥のある論旨をここまで詳しく解体しなければならないのは残念だ。
純粋な経験主義者は純粋な理論家と同じくらい現実から離れており、Blowは自分の経験に合うという理由で議論を作り出し、自分の不満に合う例だけを選んで、例外を規則のように押し通している。