2026/03/23 4:32
「パーソナル・コンピューティング」（2022）
RSS: https://news.ycombinator.com/rss
要約▶
Japanese Translation:
記事は「自分のためにコンピューティングする」ことが、企業スタイルの活動へと変貌した様子を観察しています。趣味人たちは今や業界レベルの生産感覚でコードを書き、オープンソースツールによってほぼプロフェッショナルなソフトウェアが家庭ユーザーにも手軽に提供されるようになっています。
著者は個人的プロジェクトは堅牢性やスケーラビリティよりも創造性、ダイナミズム、自由を優先すべきだと主張しています。メタプログラミングは個人領域では歓迎されますが、その複雑さから専門的にはしばしば勧められません。
手頃で普遍的なコンピューティングは一般市民を力づける一方、監視や産業基準にさらすこともあります。この作品では、自動化が最終的に人間の創造性を置き換える可能性があると警告し、「ウォーリー」のような社会――娯楽が完全に自動化される世界―を想起させます。
Paul Graham のリスプ（ダイナミック）対 Java（スタティック）の比較、Knuth が早期最適化に警戒した点、Ted Nelson の Computer Lib に対する憧れは、表現力豊かなコーディングと性能重視の実践との歴史的な緊張を示しています。
著者は個人的逸話として、コードを公開せずにプライベートリポジトリに保管した経験を挙げ、個人作業におけるオープンネスとプライバシーの緊張点を強調しています。
最後に記事は、技術が制約ある環境であっても、人間の表現や美しさへの導管として残り続けるべきだと訴え、デモクラティックコンピューティングはテクノロジーとの創造的関与を維持する責任も伴うことを読者に思い起こさせます。
本文
2022年9月19日 — ジョシュ
写真は叔父さんが撮ってくれました :)
実際に体験したことはないですが、自分のために「遊びながらコンピュータを使う」という考え方が存在していた頃を懐かしんでいます。
私たちは個人として常に何かを計算していますが、ここでは別の意味で言っています。
コンピュータには魔法があります。そしてプログラムのおかげで、その魔法を一時的に呼び出せると信じています。
グラフィカルインターフェースは粒度が足りず、他人の呪文を使うようなもので、自分で書くべきなのにそれができていない感覚です。そこで今やコンピュータ利用は「（1）消費主義的な未完成の実践」か「（2）エンジニアリング」のどちらかにしか収まらず、ソフトウェアをただの泡として扱う余地がなくなっています。
結論として言いたいことは、プログラマとしてプロフェッショナルとアマチュアの境界線は存在しないという点です。
自分用であっても、最も堅牢で拡張性のあるプログラムを書かなければならない―それがベストプラクティスです！
仕事で使うインフラを家庭でも活用する――そういうことです。
どこで読んだか覚えていませんが、映画や音楽といった芸術分野ではプロフェッショナルとアマチュアの格差が大きいと言われています。
プロ向けカメラは巨大な機械であり、家庭で動画を撮るアマチュアはほとんど使いません（高級マイクや照明も同様）。音楽スタジオも同じですが、DAWやVSTの登場により一部が変わりました。
それでもメディア制作体験（ガレージでバンドを組むか、プロのスタジオでエンジニアが作業するか）と結果への感覚（面白い猫動画か、ウォン・カーウィー映画か）の差は明確です。
従来、アマチュアとギルド（プロフェッショナル）はほぼ別物でしたが、最近になってコンピュータがこの構造を揺るがし始めています（我々のポスト・スカーシティ世界はこれであるのでしょうか？）。しかし本題に戻ります…
これは良いことなのでしょうか、それとも悪いのでしょうか。
一方では、コンピュータ技術の勝利と言えるでしょう：小さな人も大きな企業と同じ生産手段を持ち、平等なフィールドで競うことができます。
他方では、小さな人は今やコーポレート化しています。業界と同じ制約に直面し、単なる楽しみではなく監視され、ベストプラクティスに従わないと許されません。
「自宅で何も意味のないスパゲッティコードを書く」ことを推奨しているわけではありませんが、「BadCode™」に陥るのは健康的な朝食の一部だと言えます。
むしろ、自宅での優先事項―楽しさ、魔法、個人コンピューティング―は異なるものです。堅牢な静的シロや大聖堂を求めず、動的な繊維を望みます。夜に美しい網を作り、朝にはそれを片付け、翌日また同じことをする――そんな生き生きとしたイメージです。
（詩的に言い表すのが苦手なので、ご容赦ください）
業界では「メタプログラミングは悪いアイデアだ」と共通認識があります。レガシーコードベースを掘り下げると、読みやすさと信頼性を最優先にした理由が分かります。しかし、自宅で自分のためにコンピュータに魔法を使わせる際、チームで何年も保守するものと同じ手法を使う必要はありません。
個人用メタプログラミングは完全に合理的です。この種のプログラムは楽しく、機知に富み、望む限り自由であるべきです。「何でも生産性があるべき」という資本主義精神が浸透しています。
ソフトウェアは泡として存在できます。
自分だけのため、単なる楽しみのために書くことも可能です。捨てるものを書けば誰にも見られません！ 初めて何の目的もなく何かを作ったときの解放感――それが自由です。
G. Branden Robinson がグロフ・メーリングリストで示した姿勢が好きでした：
公開リモートに git リポジトリはありますか？
すみません、ありません。私のホームディレクトリにだけあり、インターネットへ複製はしていません。
個人用 dotfile リポジトリを公開ウェブに置く人もいますが、私は露出主義者でもなく、自作のクラックを誇示することもせず、サポートサービスを提供したくもありません。
オープンソースの台頭は、個人コンピューティングの衰退につながっています。社会インフラ（業界・個人が共通で使うベーシックなオープンソースプログラム）に統合されると、プロフェッショナルとアマチュアのギャップは縮まり、同じ機械を時間共有するようになります。クラウドは差別しません。
これらの思考から何を得るべきかは不明です。一方で安価なコンピュータは階級闘争における進歩を促し、すべての人の指先に力を与えます。年々、電話やオンラインで無料・オープンに利用できる生産手段が増えていくからです。しかし古いことわざのように「大きな力には大きな責任が伴う」ので、生きているということを忘れないようにしなければなりません。
技術は魂への導管であり、代替ではありません。制約ある環境で美しいものを作る努力は、先進技術によって完全に置き換えることはできません。
人類が Wall‑E の登場人物のようになることを本当に心配しています。
すでにほぼオンデマンドで食べ物や娯楽を得られます。今は誰かがその娯楽を作っていますが、将来自動化できれば――「近くの劇場へComingSoonToATheatreNearYou」――私たちは自分自身を死に至るまで楽しませ続けるでしょう。
Ted Nelson の Computer Lib を読みたいです。
それがいくつかの疑問に答え、新たな問いを投げかけてくれると信じています。
コンピューティング関連注釈
この投稿の種は、実際に自分のコンピュータを使う方法を願っていたことから始まりました。静的 vs. 動的言語についての継続的な議論もここでは重要です：
Paul Graham が指摘したように、Lisp と Java の違いは、Lisp は計算概念と表現で作業するためのもの、Java は完成したプログラムを表すためのものです。James が言うように、Java では早期に決定を固定しなければならず、一度固定するとシステム（型宣言、コンパイラ、ランタイム）はその仮定を変えることを極めて難しくします。すべての変更は誤りであるとみなされるからです。
[...] ソフトウェア開発における欠陥のある手法は、プログラミング言語で何かを行った結果です。例外を除けば、コンパイラやコンピュータ向けにプログラム記述を最適化することに重点を置いてきました。興味深いことに、「Premature optimization is the root of all evil in programming」という結果はよく説明されています。Knuth は性能より正確さを先に心配すべきだと指摘しましたが、定義は「パフォーマンスや最適化が最終的な懸念事項となる設計問題」にも当てはまります。このケースでは、開発者とデザイナーが探求・発見を続けられるようにするプログラミングメディアを作ることが課題でした。しかし、コンピュータプログラミングメディアで大規模システム設計と実装の影響を理解するまで待つ代わりに、性能最適化を早期に行い、結果として「プログラム記述（またはプログラミング）言語」を作ってしまいました―それがすべての悪の根源です。