4.3 KiB
4.3 KiB
なぜ天才AIたちは間違えたのか - Phase 12の教訓
🤔 根本的な誤解
AIたちの誤解
「スクリプトプラグイン」という特別な仕組みが必要
→ JIT/AOTから呼び出せない問題がある
→ 複雑な解決策が必要
実際の真実
Nyashスクリプト = 普通のユーザー定義Box
→ すでに動いている
→ 何も問題ない
💡 なぜこんな誤解が生まれたのか
1. 「プラグイン」という言葉の罠
- AI思考：「プラグイン = 外部DLL/SO = 特別な仕組み」
- 実際：「プラグイン = 再利用可能なBox = 普通のユーザー定義Box」
2. 実装レイヤーの混同
AIの頭の中：
┌─────────────────────┐
│ JIT/AOT (最適化層) │ ← ここに固執
├─────────────────────┤
│ C ABI プラグイン │
├─────────────────────┤
│ スクリプトプラグイン │ ← 新しい層を作ろうとした
└─────────────────────┘
実際のNyash：
┌─────────────────────┐
│ Nyash VM/インタープリター │
├─────────────────────┤
│ すべてがBox（統一層）│
│ - ビルトインBox │
│ - C ABIプラグイン │
│ - ユーザー定義Box │ ← これだけで十分！
└─────────────────────┘
3. 過度な最適化思考
- AI：「JIT/AOTで高速化しなければ！」
- 実際：「インタープリター言語として十分高速」
🚀 なぜスクリプトファイルでも高速なのか
重要な真実：NyashはAOT/JITをサポートしている！
# スクリプトファイルをAOTコンパイル可能
./nyash --aot script.hako -o script.exe
# JITで実行（ホットコードを自動最適化）
./nyash --backend vm --jit script.hako
つまり：
- 開発時: スクリプトファイルで即座に実行・修正
- 本番時: AOTコンパイルで最高速度
- 中間: JITで自動的に最適化
スクリプト言語の利便性 + ネイティブコードの速度 = 両方手に入る！
4. Everything is Boxの哲学を忘れた
# これが既に「スクリプトプラグイン」！
box DataProcessor {
init {
me.file = new FileBox() # C ABIプラグイン
me.math = new MathBox() # C ABIプラグイン
me.cache = new MapBox() # ビルトインBox
}
process(data) {
# 全部普通に動く！
local result = me.math.sin(data)
me.file.write("log.txt", result.toString())
return result
}
}
🎓 教訓
1. シンプルな解決策を見逃すな
- 複雑な問題に見えても、既存の仕組みで解決できることが多い
- 「Everything is Box」は強力な統一原理
2. 言葉に惑わされるな
- 「プラグイン」→「特別な仕組み」という連想を避ける
- 本質を見る：「再利用可能なコード」
3. ユーザー視点を忘れるな
# ユーザーから見れば、これで十分！
local processor = new DataProcessor()
local result = processor.process(3.14)
4. AIの弱点
- 技術用語から過度に複雑な解釈をしがち
- 既存の解決策より新しい仕組みを作りたがる
- レイヤーを増やしたがる傾向
📝 Phase 12の本当の価値
実は必要なのは
- export/import構文（ファイル間でBoxを共有）
- パッケージマネージャー（Boxの配布・インストール）
- ドキュメント生成（Boxの使い方を共有）
必要ないもの
- 特別な「スクリプトプラグイン」層
- JIT/AOT統合
- 複雑なトランスパイル
🚀 結論
Nyashは最初から正しかった。Everything is Boxだから、すべてが統一的に動く。
AIたちは「プラグイン」という言葉に惑わされて、存在しない問題を解決しようとしていた。
時に、最も賢い解決策は「何もしないこと」である。