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

あなたを幸せにするツールを選ぶことができます

概要

  • 技術選択の理由がしばしば感情や美学に基づく現実
  • ブログ記事の多くが論理的理由を装いながら感情的動機を隠蔽
  • マイナー技術選択が自己表現や憧れの投影である事例
  • 自分の動機を正直に見つめる重要性
  • 最終的には自分が幸せなら好きな技術を選べば良いという結論

技術選択に潜む感情的動機

  • Hacker NewsLobsters でよく見かける「なぜObscure ThingがPopular Thingより優れているか」という記事タイトル
  • 表向きは 合理的・技術的理由 を掲げるが、実際は 感情的要素 が多分に含まれる現実
  • 技術選択の背景には「 心地よさ」「慣れ親しみ」「憧れ」などの 感覚的価値観 が存在
    • 例:NetBSDをThinkPadで使い William Gibson の主人公気分を味わう人
    • 例:LispやSmalltalkなど 歴史的英雄時代 への憧れ
  • ツールの「雰囲気」が使い手の 自己イメージ と重なるケース
    • Ada=「 保守的・重厚」、Rust=「 新進気鋭・スピード感
    • Emacs=「 Gnostic的選民意識」、VS Code=「一般向け」
  • 多くの人が 感情的動機 を認められず、 合理化 に走る傾向

論理的理由の仮装とそのパターン

  • Obscure Thingの利点を誇張し、 欠点は矮小化
    • 例:「Fortran 2023でHTTPサーバ実装に半年かかった」などの苦労を美談化
    • 「Common LispはGCがある」と主張し、 Pythonの存在を無視
  • Popular Thingへの批判は 曖昧 または 社会的要素 に依存
    • 例:「Dockerは複雑すぎる」「コミュニティが有害」「Rustは軟弱になる」
  • 稀に正しい指摘もあるが、 冷静な評価基準では決定打にならない

美学としての技術選択と自己表現

  • Emacs は「Gnosticカルト」だが、それで 幸せなら問題なし
  • 好きなものを選ぶ自由、それが人生の豊かさ
  • 美学や雰囲気 のためにツールを使うことの肯定
    • 例: ZFSをエアフライヤーにFortranで確定申告
    • Tails 利用でサイバーパンク気分、 レザージャケット 着用
    • バンコクでバックパッカー、 Geminiで小説執筆、2003年製デジカメで写真
    • Signalで家族グループチャット、ISDN公衆電話からスタンドアップ参加
  • 人生をアート作品に 仕立てる提案

自己欺瞞の否定と動機の内省

  • 他人や自分に 嘘をつかない ことの重要性
    • 例: SNOBOLが未来の言語 だと主張しない
    • Prologでフロントエンドを書き直す合理的理由 をでっち上げない
  • 自己動機の内省 と、 純粋な執着 だけで突き進む危険性
    • 極端に走ると 孤独な袋小路 で年月を浪費するリスク

結論:幸せなら好きな技術を選べ

  • 合理化せず、自分がなぜその技術に惹かれるか 正直に見つめる
  • 美学・趣味・雰囲気 で選んでも良いという 肯定的メッセージ
  • ただし、 他人や自分に嘘はつかない 誠実さが大切

Hackerたちの意見

ほとんどのことと同じように、ここにもハッピー・ミディアムがあるよね。新しくてキラキラしたuvにポエトリーを捨てたおかげで、日常の体験が格段に良くなった。特に、既存のモノレポにPythonを導入しなきゃいけなかったから。Pythonのコメントとして依存関係をインラインで書けるようになったおかげで、うちの会社の全く技術的じゃない人が、たった一つのCLIコマンドでPandasを使ったAI生成スクリプトを実行できるようになったんだ。もしポエトリーを選んでたら、彼のマシンに適切なPython環境を整えるのに半日もかかってたと思う。逆に、17人しか使ってないJSのウェブフレームワークを選んじゃうと、実際に使われてるReactやVue、Svelteのユーザーが解決済みの問題を解決するのに時間を無駄にしちゃうよ。

自分が理解できるシンプルなツールを使うのが好きなんだ。いつでも拡張できるし、複雑で常に変わるツールよりもいいよね。ほとんどのツールは新しい要素を持ち込むけど、95%の使ってるものを再発明しちゃう。新しくて役立つものを持ってくる真のラテラルツールは珍しいよ(テキストエディタのLSPとか)。大体は機能ベースじゃなくてプロトコルベースだしね。

「自分を幸せにするツールを選べ」という意見には賛成だけど、「マイナーなツールは全て価値がある」っていう暗黙の前提には反対だな。人気のないツールやソリューションをたくさん使ってきたし、今も使ってるけど、その中には自分を幸せにしてくれるものもあれば、そうじゃないものもある。どれも実用的な利点をもたらしてくれるよ。良いツールが必ずしも人気になるわけじゃないし、人気のあるツールが良いとも限らない。

僕はその論文のポジティブな部分には賛成だね。つまり、物事を好きになるのはいいことで、感情を持った人間だからこそ選ぶ理由があって、素敵なものを持つべきだってこと。だけど、データや制約を見たときに、人々が非合理的に行動してるとか、それが詭弁だとかいうのは違うと思う。実際には多くの人がある程度の評価をしていて、それを無視するのは知的に怠惰だよ。僕はニッチなソフトウェアをたくさん使ってるけど、自分の美的好みと、そうする具体的な理由を完全に分けるのは難しい。美的好みや特定のものを使う喜びは、実際にはその具体的な利点から来てることもあるんだ。

実用的な利点があるのは信じてるよ。人気のあるものには、俺がやりたいことには不十分な問題がいくつかあることが多いけど、時々はそれぞれに利点と欠点があって、俺が好きなものは他のと違うってこともある。ファイルフォーマットや文字セット、プロトコル、プログラムにも同じことが言えるよ。> 「良いツールが必ずしも人気になるわけではなく、多くの人気ツールは良くない。」その通りだね。(俺の意見では、良いと思う特徴があったり、逆に悪いと思う特徴があったりすることもあるけど、一般的に良い特徴や悪い特徴もあるよね。)(ただし、何かが特定の目的には良いけど他の目的には悪いこともあるし、明らかにもっと良いものがあるのに、悪い目的に使われることもあるよね。)

ソフトウェアエンジニアリングがどれだけ主観的な感情に基づいた決定が多いか、みんな過小評価してるよね。実際、選択肢がたくさんあって、厳しい制約が少ない分野にいるってことなんだ。ウェブアプリやCLIをJava、Go、Rust、JavaScript、Ruby、Pythonなどで書けるし、それぞれに合理的な理由がある。AWS、Vercel、GCP、Azure、Cloudflareにデプロイもできるし、Postgres、Mongo、SQLite、MySQLも使える。どのスタックが他より優れているっていう実際の証拠はある? いや、あんまりないよね。結局は、自分の脳が好きだと思うものを選ぶだけで、その後に理由を補完するんだ。ソフトウェアエンジニアは、自分たちが完全に合理的な存在だと思いたがるけど、実際は社会の他の人たちと同じように主観的な理由で動いてるんだよ。

特定のプロジェクトに対して、特定のスタックを選ぶ客観的な理由は確かにあると思う。どれも強みと弱みがあるし、スタックの選択に関係なく多くの同じタスクを技術的に達成できるけど、時間枠、エレガンス、利用可能なエコシステム、コスト、スタックの人材確保のしやすさはかなり変わるかもしれない。とはいえ、他の誰かのお金を使ってないなら、自分が楽しめるスタックや生産性を感じるスタックを選ぶよ。自分のプロジェクトにはElixirを使ってるけど、働いているスタートアップには一般的に悪い選択肢だね。人材確保が難しいし、エコシステムも限られてるし、独特で時には賛否が分かれる概念だから。TypeScriptやGoと比べるとビジネスリスクがある。ただ、素晴らしい同時実行モデルとクールなパイプライン機能はあるけどね。 :)

TCLを忘れてるよ。俺はTCLとApache/Rivetでウェブアプリを書いてるんだ。 :)

俺は約6年間、いくつかのPHPの会社でバックエンドインフラチームで働いてきたけど、ダイナミック言語はリファクタリングをしたいときには本当に最悪だよね。:) それで、Goのようなコンパイル言語のありがたみを実感したよ。重すぎず、ダイナミック言語に近い感覚があるのに、リファクタリングも楽にできるからね。

ソフトウェアエンジニアは、自分が完全に合理的な存在だと振る舞いたがるだけなんだよね。これ、めっちゃ同意。合理的に考えるべき要素もあるけど、結局は直感やUXが人々が認めたがらないよりもずっと大きな要因なんだよね。私の経験上、「事実が感情よりも大事」って言う人は、しばしば感情をうまく表現できてないだけの意見を持ってることが多い。自分の感情を理解して、認められる人と話す方が好きだな。

結局、コードは人間のために書かれてるんだよ。そうじゃなきゃ、みんなアセンブラを使ってるはずだし。だから、コードの可読性や管理のしやすさは重要だよね。それに対する意見もたくさんあるし、だいたい「ケースバイケース」って感じ。コメントの核心には反対してないけど、これを単なる職人技として扱うのは厳しいと思う。私の意見としてはね。

AWS、Vercel、GCP、Azure、Cloudflareなどにデプロイできるよ。これが今やデフォルトになってるのは面白いよね。ずっと前からそうだったし。人々がこれらのプラットフォームでの運用が本当に高額(EC2/RDS)か、特定のプラットフォームに依存している(「サーバーレス」、Cloudflareワーカー、ラムダなど)ことに気づく瞬間をまだ待ってるよ。

ソフトウェア開発はエンジニアリングではないけど、完全に任意でもないんだ。これは職人技で、他の職人と同じように経験を通じて直感を育てて、それが意思決定を導くんだよね。これがエンジニアリングじゃないって言うのはちょっと物議を醸すけど、私たちのやってることを橋を作ったりダムを建設したりすることと比べてみて。そういう分野の厳密さは、ほとんどのソフトウェア開発とは天と地ほどの差があるよ。適用することはできるし、特に命がかかってるときはそうする組織もあるけど、ほとんどのソフトウェア開発ではコストと利益の比率を正当化するのは不可能だよ。これが「本物」のエンジニアも直感を育てるって言ってるわけじゃないけど、彼らははるかに高い責任を求められるんだ。いくつかの分野では、ソフトウェア開発ももっと高い責任が必要だと思うけど、それは同時にコストも大幅に上がるってことだよね。世界中の政府がそのお金が有意義に使われることに気づき始めてると思う。

大学の最初の上司が、僕のEmacsの使い方をからかって、「テキストエディタがくっついたオペレーティングシステムだね」って言ってた。僕はただ笑って、Emacsのバッファ内でスネークゲームを始めて、そのままハッキングを続けたよ。

確かに、これはオペレーティングシステムで、かなりしっかりしたやつだよ。ただ、いいテキストエディタがないのが残念…でも、evilモードが本当に良いエディタをエミュレートしてくれるから助かるね。 :)

彼の言ってることは間違ってないよ。EmacsはMITのLispマシンやSymbolicsインターフェースを置き換えるために作られたもので、見事にその役割を果たしてる。Emacsでできることはかなりすごいけど、全てのLispプロジェクトと同じく、「Lispの呪い」にも悩まされてるみたいだね(でもそれは俺的には問題ないけど)。

私たちは、自分たちの素敵なツールで問題を解決することに幸せを感じるべきなのかな? ツールや深い知識は、自己満足のための気晴らしなのか、それとも自己尊重や情熱の表れなのか? 僕は後者だと思う。私たちの素敵なツールは、私たちを幸せにするだけじゃなくて、もっと多くの有用性を提供してくれる。ツールは新しいことを教えてくれて、好奇心や創造性を広げてくれる。私たちの幸せは、もっと多くの問題を解決したり、より良い質問をするための原動力になるんだ。

これは普段は素晴らしい作品を書く著者による残念な記事だね。記事は真実の芽に触れているけど、誤解を招く方向に進んでしまってる。残念ながら、この文章が誰かにもっと注意深く合理的に考えさせるインスピレーションを与えるとは思えないけど、逆に人気がない、普通でない、退屈と見なされることをしている人に対して撃つための考えを止める弾薬を提供しているだけだよね。(最近は「グルグプログラマー」や「退屈な技術を使おう」みたいな風潮があるから、なおさらだね。)俺が思うのは、人はしばしば自分の決定の真の理由や意図を、弱い後付けの客観的な議論の仮面の後ろに隠すってこと。著者が言ってることは、幸せになるために何かを使うのは全然OKだってことだと思う。特に個人や趣味のプロジェクトでは、SWI-Prologが本当に最適な技術的選択だったなんて世界に納得させる必要はないよ。「Prologが好きで、それを使ってCRUDウェブアプリを作った」って言うのは全然問題ない。俺はこの知的誠実さには賛成だよ。著者がずれてるのは、この批判を「不明瞭な」決定をする人々に特に結びつけているところだね。彼は特に、疎外的な風刺を通じてそうしている。記事の潜在的なメッセージは、もし普通でないことをしているなら、最初から詭弁を避けて本当に感じていることを言えってことだよね:それが幸せにしてくれるって。彼は、不明瞭な選択が技術的に正当化される可能性があるという考えには全く信憑性を与えていない。現実には、人気のある技術を選ぶ人たちも、良い理由がないことが多いし、彼らもまた客観的な正当化の仮面を提供している。彼らは著者を怒らせるようなブログ記事(「なぜPythonを選んだのか」)を書いているわけではないけど、決定が挑戦されるときには、自分の弱い後付けの正当化を語っているよ。これはほぼ避けられないことで、彼らの選んだ人気技術が唯一の人気技術ではないからね。彼らは著者の「一般的なLisper」の悪夢と同じように、自分の決定のために同じようなたわごとを作り出すだろう。俺はもっと強い主張をするかもしれない:人々は人気のある技術を使うことを決めるのは、それが彼らを幸せにするからで、これは負荷のかかる状況で週末の技術者よりもはるかに頻繁に起こるよ。さらに、人気はさらなる技術的探求に対する一種の免疫として機能する。これが、週末のAPLerがプロジェクトにAPLを選んだ理由を書くよりも、分野全体に対してはるかに多くの技術的な混乱や損害をもたらしていると思うし、著者が全く提供していない検討を要求すると思う。もっと主観的に言うと、この記事を読んだ後、著者が何かに不満を持っているか、何かを持ち出したいのではないかと感じたよ。彼は不明瞭な技術には慣れているし(元「一般的なLisper」で、今はそれを否定している)、不明瞭なWirthian構文で書かれた自分自身の不明瞭なプログラミング言語を作ったこともある。もしかしたら、この文章は何らかの形での告白を表しているのかもしれないね。

俺はもっと強い主張をするかもしれない:人々は人気のある技術を使うことを決めるのは、それが彼らを幸せにするからで、これは負荷のかかる状況で週末の技術者よりもはるかに頻繁に起こるよ。さらに、人気はさらなる技術的探求に対する一種の免疫として機能する。 その通りだね。これ以上うまく言えなかったと思う。データポイントを追加するけど: https://flownet.com/gat/jpl-lisp.html 説明と観察された結果から、これはあるチームがLispで挑戦的な状況で成功した後、最初はC++、次にJavaという業界標準の言語で失敗したケースだよ。

幸せを定義してみて。長期的な幸福は必須だよ。長期的なゲームのために、より良いトレードオフを持つツールを賢く選ぼう。耐久性、生産性、人、金の観点でね。

著者は、無自覚な動機が誤った結論に導くことを巧妙に使って、私たちの無自覚な動機が誤った結論に導かないようにすべきだと示しているね。

プロジェクトにはC#を選んだのは、他の選択肢がもっと良かったかもしれないと思って、それを defend しなきゃいけないのが怖かったから。Angularを選んだのは、エンタープライズの美徳を体現してるように思えたからで、顧客が求めてたのもそれだった(今は過去の自分が本当に嫌いだよ)。だから、標準技術でも非標準技術でもそういうことがあるよね。(逆に、昔はPythonがマイナーな存在だったこともあるし。みんなが安全な道だけを選んでたら、進歩は見られないよね。)でも、私がEmacsを使う主な理由は、単純にそれが私を幸せにしてくれるからだよ :-)