【プログラミング】何故フレームワークやエンジンが嫌いなのか

この記事を始める前に、ちょっとしたお知らせがあります。
本来この記事は昨日公開する予定でしたが、あたしのゲームエンジンをNintendo Switchに移植していました。
この作業には2週間掛かりましたが、思ったよりも早く動作させる事が出来ました。
又、このエンジンをWindows、macOS、Linux、FreeBSD、OpenBSD、NetBSD、Haiku上でもテストコンパイルして実行し、全てのOSで動作する事を確認しました。
ゲーム自体はNintendo Switchとその後継機にのみ公開する予定ですが、若しPC向けの小規模なサイドプロジェクトを作る場合に備えて、全ての環境で動作するのは良い事です。
尚、このエンジンはPlayStation 5では動作しません。
PlayStation 5はVulkanを全く対応していないからです。
あたしのエンジンはVulkan APIを使用しています。
macOSとiOSではMoltenVKを介してのみVulkanを対応しています。

2日前に私のロードマップで書いた様に、あたしはゲームエンジンやウェブフレームワークを使うのが好きではありません。
今日はその理由をお話しします。

抽象化は複雑さ、単純さは理解

あたしは主にC、C++、PHP、Goで開発します。
又、MIPSアセンブリに非常に精通しており、RISC-Vアセンブリもそこそこ得意です。
これらを使う事で非常に生産的に作業出来ます。
然し、あたしはJavascriptやPythonでは完全にダメで、これらは「初心者向け言語」として常に評価されています。
同様に、あたしはPhpStormでSymfonyやLaravelのコードを書くよりも、Neovimで通常のPHPコードを書く方が遥かに生産的です。

あたしが働いている会社では、PhpStormを使う様に言われました。
これにより生産性が向上すると言われていたからです。
然し、あたしのパソコンでは全く動作しなかった為、結局Neovimを使う事になりました。
別のパソコンではPhpStormを動作させる事が出来ましたが、今度はIDEがあたしのコードを奇妙な形に自動整形したり、使用しないクラスを自動でインポートしたり、開き括弧を入力する度に勝手に閉じ括弧を追加したりと、正にあたしの生産性を妨げる事ばかりでした。
その為、再びNeovimに戻り、それ以来ずっと使い続けています。

その理由は一貫して抽象化のレベルにあります。
多くの人々は、抽象化が生産性を向上させるという宗教的な信念を持っています。
然し実際には、抽象化は生産性を阻害します。
それは、読まなければならないドキュメントの層を増やし、学習曲線を高くし、簡単には解決出来ない驚くべきバグを引き起こし、何が起きているのかを理解する方法がなくなるからです。

あたしは必ずしも抽象化に反対しているわけではありません。
libc（glibc、musl、dietlibcなど）も抽象化層の一種です。
限られた抽象化はボイラープレートを減らし、より少ないコード行数で多くの作業を行う事が出来ます。
然し、抽象化の量が多過ぎると、最終的にはより多くの作業をしなければならなくなります。
あたしはこれについてよく怒っています。
何故なら、現在のプログラミング分野は、自分達が他人よりも技術を向上させ、理解していると思い込んでいる無責任な馬鹿者達に寄って運営されており、実際にはベテランにとって悪化させ、初心者にとって参入の障壁を大幅に高める結果になっているからです。
RustやZigの様に抽象化を減らす事を目指す新しい言語で冴え問題があります。
それらは完全なエコシステム（パッケージマネージャを含む）を目指している為、自由にやりたい事が制限され、頂点にいるエゴを持った人が貴方を嫌うからです。

異なる視点

ソフト開発の分野では、2種類のプログラマーがいます。
1つ目のタイプは、プログラミングを仕事と見なしている人達で、只給料を稼ぐ為にコードを書き、オンライン検索結果からコードをコピーしたり、AIに生成させたり、他人が書いた依存関係に大きく頼ったりしたり、仕事が嫌いな人です。
2つ目のタイプは、プログラミングを芸術の一種と見なしている人達です。
これらの人達は、効率的で安全なコードを書く事に大いに気を配り、仕事中だけでなく自由時間にもプログラミングを楽しみ、出来るだけ多くのコードを自分で書く事を楽しみ、内部で何が起こっているのかを本当に理解したいと考えます。
勿論、初心者に当てはまる3つ目のタイプもありますが、それは1つ目と2つ目の混合タイプです。

あたしはプログラミングを芸術の一種と見なしているタイプで、常に全ての仕組みを理解する事を優先し、製品を迅速に出荷する事を目標とはしていません。
その為、抽象化を生産性ツールではなく障害物と見なしています。
然し、現在の殆どのプログラマーは仕事としてプログラミングをしているタイプなので、抽象化はツールであり、単純さは彼らにとって障害物です。

抽象化が必ずしも悪いわけではない

時には抽象化が役立つ場合もあります。
2024年11月に、LinuxとOpenBSD上で動作するVulkanを使ったゲームエンジンを作り始めました。
然し、あたしが作りたいゲームはNintendo Switchとその後継機向けだったので、エンジンを移植する必要がありました。
Switchの開発では、NintendoがVSI拡張機能を提供している為、Visual Studioを使用する必要があります。
移植作業中に次から次へと問題に直面しましたが、保々完全に動作させる所まで到達しました。
然し、printfデバッグではもう簡単に解決出来ないエラーに直面しました。

GDBでデバッグするのが大嫌いですが、Visual Studioのデバッガは非常に役立ち、問題の原因を正確に特定する事が出来、最終的に修正する事が出来ました。
これは抽象化が役立つ一例です。

モダン開発の問題点

この話題に関連する現代開発の最大の問題は、初心者にJavascriptやPythonで学び始める様に教えられている事です。
それだけでなく、それらを巨大なフレームワークの中で学ぶ様に指導され、コードの8部が他人が書いた依存関係で構成され、製品を動作させる事だけを気にして、コードが実際に何をしているのかには興味を持たない様教えられます。
これはプログラミングの方法を教える物ではなく、特定のエコシステムに閉じ込められる罠です。
そのエコシステムから抜け出すのは非常に困難です。

この結果、コードが何をしているのか理解する事が出来ず、結果的に悪いコードが生まれ、それがバグだらけのソフトに繋がります。
今日の初心者は全てこの方法で学ぶ様に教えられている為、より低レベルな理解を得る事が非常に困難になります。
そして企業は経験豊富な開発者よりも安価な若い開発者を雇いたいと考えています。
その結果、フレームワークを使い、全ての依存関係をダウンロードし、技術がどう動作しているのか気にしないという考え方が常識になり、年々ソフトは衰退し続けています。
その為、初心者は一生初心者レベルに留まり続ける事になります。
何故なら、雇用主は知識やスキルを重視しないからです。

Z世代がファイルやディレクトリが何であるか理解していないという報告があります。
彼らの多くはHTTPサーバーが実際にやっているのは、ファイルシステム上のファイルを見つけて開き、その内容を読み取り、ブラウザに表示に変換し、TCP又はUDPプロトコルを介して送信するだけだという事を理解していません。
これは非常に深刻です。
何故なら、これはソフトが崩壊の段階に達している事を示しているからです。

特に、現在の技術の全てを作り上げたベビーブーマーやX世代の人々が引退していく中で、あたし達は若者達が快適な環境から引きずり出される必要があるのか、それとも近い将来、社会を暗黒時代に陥れる必要があるのかの岐路に立っています。
最終的には、あたし達が依存してきた全てのレガシーシステムが崩壊し、NPMやPIPの依存関係が機能しなくなり、1つの依存関係の失敗が数千もの大規模な製品を同時に倒させる様な状況に陥るでしょう。
これは過去に起こった事があり、同じ様な事が更に大きな規模で再び起こる運命にあります。

以上