存在論的プログラミング：時間と存在を記述する

/* Dark slides */
.reveal section[data-background-color="#000000"] h1,
.reveal section[data-background-color="#000000"] h2,
.reveal section[data-background-color="#000000"] h3,
.reveal section[data-background-color="#000000"] p,
.reveal section[data-background-color="#000000"] li,
.reveal section[data-background-color="#000000"] div,
.reveal section[data-background-color="#000000"] span,
.reveal section[data-background-color="#000000"] code {
    color: #f5f5f7;
}
.reveal section[data-background-color="#000000"] .epigraph,
.reveal section[data-background-color="#000000"] .dim,
.reveal section[data-background-color="#000000"] .layer-label {
    color: #a1a1a6;
}
.reveal section[data-background-color="#000000"] pre {
    background: #1d1d1f;
    border-color: #424245;
}
.reveal .slides section.overflow-visible {
    overflow: visible !important;
}
.reveal .tree-diagram {
    background: none;
    box-shadow: none;
    border: none;
    text-align: left;
    transform: scale(1.25);
    transform-origin: top center;
}
.reveal .callout {
    font-size: 1.2em;
    margin-top: 1.5em;
}
</style>

# Be, Don't Do

## 存在論的プログラミング
### 時間と存在を記述する

<div style="margin-top: 2.5em; font-size: 0.75em;">
Akihito Koriyama (@koriym)
</div>

Note: ⏱ 0:30 冒頭｜タイトルをみてください。こんな大袈裟なタイトル。宇宙創造？PHPで時間と存在を書きたかったって人いますか？

集まった皆さんはソリューションの話を聞きにきたのではなくて、耳にしたことのない考え方に興味をもってる人たちじゃないですか。

---

## パラダイム

<div style="font-size: 1.4em; margin: 1em 0;">
物の見方・考え方の枠組み
</div>

Note: ⏱ 0:30 冒頭｜今日はパラダイムのお話をします。パラダイムというのは、ものの見方や考え方の枠組みのことです。たとえば天動説。空を見上げると天体が動いてますよね。実際、この天動説は1400年以上にわたって科学の最先端でした。ところが「実は地球の方が回っているんじゃないか」という人が現れる。そこから宇宙の捉え方、つまりパラダイムが入れ替わって、天体がより深く理解できるようになったわけです。
実はプログラミングにも「パラダイム」があります。プログラムをどう作っていくか、その根本の考え方が時代とともに変わってきました。ここから本題に入るんですが、その前にひとつお願いがあります。新しいものの見方って、最初はどこか居心地が悪いんですね。今までの延長でみると奇妙にみえます。馴染んだやり方に人は引っ張られます。けどそれじゃ面白くないです。古い枠組みで新しいものを評価しても、本質がみえない。
ここからの話は、一旦頭を空っぽにして可能性だけに目を向けて聞いてみてください。

---

## プログラミングパラダイム史

```asm
LDA #$01       ; Aレジスタに1をロード（6502）
CLC            ; キャリーフラグをクリア
ADC #$02       ; 2を加算
STA $00        ; メモリに保存（1+2=3）
```

<span class="dim">50s アセンブラ：マシンの言葉で考える</span>

</div>

```php
for ($i = 0; $i < count($data); $i++) {
    process($data[$i]);
}
```

<span class="dim">60s 手続き型：手順で考えられるようになった</span>

</div>

```php
$user->validate();
$user->save();
```

<span class="dim">70s- オブジェクト指向：モノとして考えられるようになった</span>

</div>

Note:
これは6502アセンブラです。ファミコンやMac以前のAppleに使われた伝説のCPUで1950年代に登場しました。1たす2を計算するだけで、これだけ書きます。

次が1960年代に登場した手続き型。データとロジックを分離してデータ操作の手順をかきます。

1970年代に登場したのがオブジェクト指向。データとデータ操作をするロジックを統合してオブジェクト、つまりモノとして記述できるようになりましたた。

---

## 世界認知の拡張

```asm
LDA #$01       ; Aレジスタに1をロード（6502）
CLC            ; キャリーフラグをクリア
ADC #$02       ; 2を加算
STA $00        ; メモリに保存（1+2=3）
```

<span class="dim">50s アセンブラ：マシンの認知</span>

```php
for ($i = 0; $i < count($data); $i++) {
    process($data[$i]);
}
```

<span class="dim">60s 手続き型：世界を手順で認知</span>

</div>

```php
$user->validate();
$user->save();
```

<span class="dim">70s- オブジェクト指向：世界をモノとして認知</span>

</div>

Note: 振り返ると、パラダイムの変化は世界の認知方法の拡張だった。アセンブラは世界を機械の目で見たとおりをコーディングしてた。1,2,3,4..9の次は10じゃなかった。

手続き型はレシピや作業手順のように記述できた。世界を手続きで認識した。

オブジェクト指向は世界をモノとその関係で捉えられると認識した。

オブジェクト指向以降も宣言型、関数型など新しいパラダイムは生まれたがOOPほどのインパクトはなかった。

私はこのインパクトに匹敵するようなパラダイムをつくる挑戦がしたいと思い、Be Frameworkというドメインフレームワークをつくりました。

人間は認知できないものは考えることができない。新しい認知のは新しい可能性を引き出すはずです。そこで認知拡張の鍵とするのが、タイトルにある—存在と時間——です。時間的存在を世界認知ができないか、これから考えて行きます。

---

## 見慣れたコードの、奇妙さ

```php
$user = new User('Alice');
$user->delete();
// $user ?
echo $user->getName();  // "Alice" ? null ? exception ?
```

Note: ⏱ 5:00 第1層：亀裂｜new User('Alice')でアリスユーザーを作った。$userはアリス。delete()でアリスを消した。getName()はAliceを返すべき？nullを返すべき？——どちらも納得いかない。$userは何を表している？...答えがない。$userはuserを表してたのではなく、userに対する操作を束ねたシンボルにすぎないのでは？っとも思えてくる。

おかしく思えてきませんか。視点をあたえることで皆さんの認知が変わったとしたら、それがパラダイムです。

---

## User クラスのメソッド

```php
interface User {
    public function register(); 　　   // すべてが、常に利用できる
    public function verifyEmail();
    public function login();
    public function logout();
    public function updateProfile();
    public function changePassword();
    public function addAddress();
    public function removeAddress();
    public function addPaymentMethod();     
    public function removePaymentMethod();
    public function addToCart();
    public function removeFromCart();
    public function addToWishlist();
    public function removeFromWishlist();
    public function checkout();
    public function trackOrder();
    public function cancelOrder();
    public function requestRefund();
    public function writeReview();
    public function deleteReview();
    public function subscribePrime();
    public function cancelPrime();
    public function enableTwoFactor();
    public function disableTwoFactor();
    public function linkSocialAccount();
    public function reportAbuse();
    public function contactSupport();
    public function exportData();
    public function suspend();
    public function reactivate();
    public function closeAccount();
    public function delete();
}
```

Note: Amazonのシステムにユーザークラスというものがあったら、一体いくつメソッドが必要でしょう。神クラスができたかんじですよね。

そしてメソッドはいつでも利用可能です。login()してなくてもlogout()を呼ぶことが可能です。

その時、利用可能な動作を「アフォーダンス」って言いますけどHTMLはうまくできてすよね。そのときに利用できるときにしかリンクやフォームは現れない。GUIは本質的に利用できない操作を呼べてしまう問題がありません。

---

<div class="layer-label">第2層：WHETHER?</div>

## 問いの転換

```
HOW?      どうやるか（手続き型）
WHAT?     それは何か（オブジェクト指向）

WHETHER?  そもそも存在できるか(Be)
```

</div>

Note: ⏱ 9:00 第2層：手続き型はどうやるか、つまりHOWです。

---

<div class="layer-label">第2層：WHETHER?</div>

## それは存在可能か

```
年齢がマイナスの人はいない
生まれる前に死ぬことはできない
```

</div>

Note: どちらも真実です。しかし「年齢がマイナス」は防御プログラミングやVOでもできる。だが「生まれる前に死ぬことはできない」は？

このアフォーダンスの問題をうまく解決していたのがHTMLですよね。AタグやFORMタグではそれが可能なところでしか出てきません。（HTTP APIが台無しにしてしまいましたが...）

——WHETHER?ではこれらの問題を解決して、一級市民にすることを考えます。

---

<div class="layer-label">第3層：見え始めるもの</div>

## `$email` と書いたのに

```php
public function register(string $email) {
    if (!filter_var($email, FILTER_VALIDATE_EMAIL)) {
        throw new Exception("Invalid email");
    }
    // ...
}
```

Note:  $emailをfilter_varしています。けど例えば$emailという変数はemailが必ず入っていたらどうでしょう？

---

<div class="layer-label">第3層：見え始めるもの</div>

## 意味変数

```php
final class Email
{
    #[Validate]
    public function validate(string $email): void
    {
        if (!filter_var($email, FILTER_VALIDATE_EMAIL)) {
            throw new InvalidEmailException();
        }
    }
}

// $email という名前があれば、どのコンストラクタでも自動検証
public function __construct(string $email) {}
```

<div class="epigraph">
存在するものは必然的に存在し、存在しないものは必然的に存在しない——スピノザ（1677）
</div>

Note: それを解決するのが意味変数です。変数が意味と制約を持ちます。一度定義すれば$emailという名前の全コンストラクタで自動適用されます。$emailに入っている値はたまたま正しいのではなく必然的に正しい。正しくないものはそもそも存在できない。——スピノザの「必然的に存在する」、難しく聞こえますが、皆さんが今ここで私の話を聞けているのは、心臓が動いて、呼吸して、生きているから。存在の前提が満たされている。意味変数も同じで、$emailが存在しているなら、それはもう正しい。

---

<div class="layer-label">第3層：見え始めるもの</div>

## 名前を装飾する

```php
// $ageは0-150歳
public function __construct(int $age) {}

// #[Teen]で13-19歳に
public function __construct(#[Teen] int $age) {}
```

Note: $ageは「年齢」の制約を持つ。#[Teen]で装飾すると13-19歳に絞られる。同じ$ageでも文脈で意味が変わる。名前＋属性で存在の条件をさらに細かく定義できる

---

<div class="layer-label">第3層：見え始めるもの</div>

## 名前が関係になる

```php
public function __construct(
    string $email,
    string $confirmEmail, // 自動で一致検証
    int $min,
    int $max,             // 自動で min < max
) {}
```

Note: $confirmEmailと書いただけで$emailとの一致が自動検証される。$minと$maxも同様。名前が制約になるとはこういうこと

---

<div class="layer-label">第3層：見え始めるもの</div>

## 名前に制約が宿る

```php
public function __construct(
    public string $email,          // フォーマット制約
    public float $bodyTemperature, // 値の範囲制約
    public string $inStockItemId,  // ビジネスルール制約
) {}
```

<div class="epigraph">
言霊——言葉に宿る霊力。名前が現実を規定する——日本
</div>

Note: 単なるフォーマット検証ではない。名前の力は値の範囲からビジネスルールにまで及ぶ。まさに言霊。

---

<div class="layer-label">第3層：見え始めるもの</div>

## 万物流転

卵 → 幼虫 → さなぎ → 蝶

</div>

<div class="epigraph">
同じ川に二度入ることはできない——ヘラクレイトス（紀元前5世紀）
</div>

Note: 「川が流れている」と言いますが、流れるのが川で、川の存在そのもの。存在と変化は分離できない。だから同じ川に二度入ることはできない——常に変化しているから、元には戻らない。さなぎは卵に戻れない。変容したものは変容前に戻らない。

---

<div class="layer-label">第3層：見え始めるもの</div>

## <span class="accent">`$being`</span>——運命の地図

```php
public Success|Failure $being;
```

```php
public Delivered|Returned|Lost $being;
```

</div>

<div class="epigraph">
アリストテレスはこれをデュナミス（可能態）と呼んだ——紀元前4世紀
</div>

Note: Success|Failureと書いた瞬間、この処理がたどりうる運命が宣言される。アリストテレスはこれをデュナミス——可能態と呼んだ。注文はキャンセルという可能性を内に持っている。$beingも同じで、なりうるもの全てを自ら宣言する。

---

<div class="layer-label">第3層：見え始めるもの</div>

## <span class="accent">`$been`</span>——存在の自己証明

```php
final readonly class EmergencyCase
{
    public BeenProcessed $been;

public function __construct(
        #[Input] float $bodyTemperature,
        #[Input] int $heartRate,
        #[Input] Emergency $being
    ) {
        $this->been = new BeenProcessed(
            actor: 'triage-system',
            evidence: ['temp' => $bodyTemperature, 'hr' => $heartRate]
        );
    }
}
```

<div class="epigraph">
あなたは私ではない。どうして私が魚の気持ちを知らないと分かるのか？——荘子（紀元前4世紀）
</div>

Note: 荘子が池を泳いでる魚をみて「魚は楽しそうだ」と言うと、友人が「お前は魚じゃないのになぜわかる？」と返した。荘子は「お前こそ私じゃないのに、なぜ私にわからないとわかる？」——外から確認しようとすると無限に続く。内側の方がよく知っている。$beenはオブジェクト自身が「私はこう変容した」と証拠を内包する。外部に問い合わせない——自己証明。

---

<div class="layer-label">第3層：見え始めるもの</div>

## 内在と超越

内在 × 超越 ＝ 変容した内在

</div>

Note: 種は土と水に出会って芽になる。子供は先生や友人に出会って成長する。小麦粉は酵母と水に出会ってパンになる。万物は同じパターンに従っている。自分が持つものと、外から出会うものが合わさって、変容した自分になる。変容後にはどこが内でどこが外だったか区別できない。この後のコードで、このパターンがそのまま動くのを見ていきます。

---

<div class="layer-label">第3層：見え始めるもの</div>

## なりたい自分になる

<pre style="text-align: center;">OrderInput → ValidOrder → InStockOrder → PaidOrder → DeliveredOrder</pre>

各クラスは「何をするか」ではなく「何であるか」を定義する

<div class="epigraph">
エンテレケイア——内に目的を持つもの——アリストテレス（紀元前4世紀）
</div>

Note: 変化には方向がある。どんぐりは樫の木になるが、バラにはならない。OrderInputはDeliveredOrderになるが、Userにはならない。アリストテレスはこれをエンテレケイア——内に目的を持つもの——と呼んだ。可能性は無限ではなく、有限で方向性がある。

---

<div class="layer-label">第3層：見え始めるもの</div>

## 運命は分岐する

```php
// 一本道
#[Be(ValidUser::class)]
final readonly class UserInput { ... }
```

```php
// 分岐——$being が型で決定する
#[Be([EmergencyCase::class, ObservationCase::class])]
final readonly class TriageAssessment
{
    public Emergency|Observation $being;
}
```

Note: 一本道だけではない。$beingの型が可能性を宣言し、コンストラクタの中で自己決定する。外部のルーターが振り分けるのではない——存在自身が次の姿を選ぶ。

---

## 例：トリアージ

```php
// 意味変数検証
final class BodyTemperature {
    #[Validate]
    public function validate(float $bodyTemperature): void {
        if ($bodyTemperature < 30.0 || $bodyTemperature > 45.0) {
            throw new LethalVitalException(); // 存在できない
        }
    }
}
```

```php
// 意味例外
#[Message([
    'en' => 'Vital signs indicate non-survivable conditions.',
    'ja' => 'バイタルサインが生存不可能な状態を示しています。'
])]
final class LethalVitalException extends DomainException {}
```

Note: ⏱ 27:00 第4層：回収｜ここからは実例。トリアージ——救急搬送時に患者の緊急度を判定する仕組み。今まで見てきた概念がひとつのコードに集まる。まずは意味変数。$bodyTemperatureという名前が致死的バイタルを存在させない。

---

## 存在の起点

患者がバイタルサインとともに到着する

```php
// 入力クラス
#[Be([TriageAssessment::class])]
final readonly class PatientArrivalInput
{
    public function __construct(
        public float $bodyTemperature,
        public int $heartRate
    ) {}
}
```

Note: 患者が体温と心拍を伴って到着する。これが起点。#[Be]属性がこの入力からTriageAssessmentへの変容を宣言している。bodyTemperatureとheartRateは次のクラスに引き渡される。

---

## 存在の分岐

トリアージプロトコルが運命を決める

```php
// 存在クラス（$being で分岐）
#[Be([EmergencyCase::class, ObservationCase::class])]
final readonly class TriageAssessment
{
    public Emergency|Observation $being;

public function __construct(
        #[Input] float $bodyTemperature,  // 内在
        #[Input] int $heartRate,          // 内在
        #[Inject] JTASProtocol $protocol  // 超越
    ) {
        $urgency = $protocol->assess($bodyTemperature, $heartRate);
        $this->being = ($urgency === 'emergency')
            ? new Emergency()
            : new Observation();
    }
}
```

Note: 到着した患者には内在がある——体温と心拍。そこにトリアージプロトコルという超越と出会い、$beingで自らの運命を決める。

---

## 存在が能力を決める

```php
final readonly class EmergencyCase
{
    public string $priority;  // "IMMEDIATE"
    public string $color;     // "RED"

public function __construct(
        #[Input] float $bodyTemperature,
        #[Input] int $heartRate,
        #[Input] Emergency $being
    ) {
        $this->priority = 'IMMEDIATE';
        $this->color = 'RED';
    }

public function assignER(): string { ... }　// この能力はここだけ
}
```

```php
final readonly class ObservationCase
{
    public function __construct(
        #[Input] float $bodyTemperature,
        #[Input] int $heartRate,
        #[Input] Observation $being
    ) {}

public function assignWaitingArea(): string { ... } // この能力はここだけ
}
```

Note: Emergency $beingを受け取ったからこそEmergencyCaseになり、assignER()という能力を持つ。Observation $beingならObservationCaseになり、assignWaitingArea()。存在の理由が能力を決める。deleteされたユーザーがgetName()できる問題は、ここにはない。——ところで、技術的な名前がひとつもないことに気づきましたか？

---

## 主体が変わっていく

<pre class="tree-diagram" style="font-size: 0.55em; line-height: 2.2; margin-bottom: 4em;">
<span style="color:#86868b">[Input]</span>  <span style="color:#d63384">PatientArrivalInput</span> (<span style="color:#0071e3">$bodyTemperature</span>, <span style="color:#0071e3">$heartRate</span>)
            |
<span style="color:#86868b">[Being]</span>  <span style="color:#d63384">TriageAssessment</span>  <span style="color:#0071e3">$being</span>
            |
<span style="color:#86868b">[Final]</span>  <span style="color:#d63384">EmergencyCase</span>     <span style="color:#d63384">ObservationCase</span>
         <span style="color:#6f42c1">assignER()</span>        <span style="color:#6f42c1">assignWaitingArea()</span>
         <span style="color:#0071e3">$been</span>             <span style="color:#0071e3">$been</span>
</pre>

<div class="epigraph">
言葉は存在の家である——ハイデガー（1947）
</div>

Note: ⏱ 31:00 統合｜言葉は存在の家——メガネがないと世界が見えない人にとって、メガネが世界への窓になるように、言葉を通じて私たちは存在を認識する。ここではクラス名が主体の変遷を記述し、世界を構築している。そしてもうひとつ——患者は処理されていない。患者自身が内在と超越に出会い、変わっていく。Input、Being、Final——到着した患者がなるべき状態になっている。

---

## 複雑な世界も同じ構造

<pre class="tree-diagram" style="font-size: 0.38em; line-height: 1.15; margin-bottom: 8em;">
<span style="color:#d63384">OrderInput</span> (<span style="color:#0071e3">$items</span>, <span style="color:#0071e3">$customer</span>, <span style="color:#0071e3">$payment</span>)
    |
<span style="color:#d63384">ValidationOrder</span> <span style="color:#0071e3">$being</span>
    |
    +--- <span class="final-node">InvalidOrder</span> <span style="color:#0071e3">$been</span>
    |
    +--- <span style="color:#d63384">ValidOrder</span> --- <span style="color:#d63384">InventoryOrder</span> <span style="color:#0071e3">$being</span>
                            |
                            +--- <span style="color:#d63384">OutOfStockOrder</span> --- <span style="color:#d63384">PendingOrder</span> <span style="color:#0071e3">$being</span>
                            |                       |
                            |                       +--- <span class="final-node">BackOrder</span> <span style="color:#0071e3">$been</span>
                            |                       +--- <span class="final-node">CancelledOrder</span> <span style="color:#0071e3">$been</span>
                            |
                            +--- <span style="color:#d63384">InStockOrder</span> --- <span style="color:#d63384">PaymentOrder</span> <span style="color:#0071e3">$being</span>
                                                    |
                                                    +--- <span class="final-node">FailedPaymentOrder</span> <span style="color:#0071e3">$been</span>
                                                    |
                                                    +--- <span style="color:#d63384">PaidOrder</span> --- <span style="color:#d63384">FraudCheckOrder</span> <span style="color:#0071e3">$being</span>
                                                                          |
                                                                          +--- <span class="final-node">SuspiciousOrder</span> <span style="color:#0071e3">$been</span>
                                                                          |
                                                                          +--- <span style="color:#d63384">ClearedOrder</span> --- <span style="color:#d63384">ShippingOrder</span> <span style="color:#0071e3">$being</span>
                                                                                              |
                                                                                              +--- <span class="final-node">DeliveredOrder</span> <span style="color:#0071e3">$been</span>
                                                                                              +--- <span class="final-node">ReturnedOrder</span> <span style="color:#0071e3">$been</span>
</pre>

<div class="epigraph" style="margin-top: 0.5em;">
道は常に無為にして、而も為さざることなし——老子（紀元前6世紀）
</div>

Note: 老子は言った——水を移動させるときに、水を動かすな、谷を作れ。制御を手放して、物事が自律的に動く仕組みを作れ。注文が流れるように、しかるべきところにたどり着く。この図に全てを知る者はいない。それぞれが自分の前後だけを知り、中央の制御者なしに調和が生まれている。無為自然。

---

## 存在の生成

```php
$becoming = new Becoming($injector);
$final = $becoming(new OrderInput(
    $items,
    $customer, 
    $payment
));
```

<div class="epigraph">
生じたものはその刹那に滅する。滅することに他の因を待たない。——大毘婆沙論（2世紀）
</div>

Note: OrderInputはBecomingに入った瞬間に消える。どこにも残らない。次のクラスが生まれ、それもまた消え、また生まれる。ロングショットで見れば変化。クローズアップすれば消滅と生成の繰り返し。2世紀の仏教論師たちが見抜いたこと——生じたものはその刹那に滅する。滅することに他の因を待たない。

---

## DX から AX へ

```
DX: Developer Experience — 人間にとって書きやすいコード
AX: AI Experience — 人間とAIの双方が理解できる構造

👤 何が存在すべきか WHETHER を定義する
🤖 どう実現するか HOW を解く
```

</div>

Note: ⏱ 35:00 宣言＋DX→AX｜さっきの図、AIも理解できますよね。Input→Being→Finalという構造はAIが検証・理解できる制約でもある。人間が存在の条件を定義し、AIが実装を解く——その交差点にBeingがある。

---

Tell, Don't Ask — Object Oriented<br>
<span class="accent">**Be, Don't Do — Being Oriented**</span>

</div>

Note: Tell, Don't Ask——オブジェクトに聞くな、命じろ。データとロジックを一体にして、オブジェクト自身に処理させる。Be, Don't Do——命じることすらしない。何をするかではなく、何であるかを定義する。Be yourself。

---

## 削除も存在

```
$user->delete() // $user?
$deleted = new DeletedUser($user) // $user?

ActiveUser → DeletedUser
```

</div>

Note: `$user->delete()`を覚えていますか？delete()を呼んでも$userは残る。ならばDeletedUserクラスを作ればいい？——でも`$deleted = new DeletedUser($user)`としても、元の$userはまだ生きている。`$user->post('goodbye')`が通ってしまう。BOPのBecomingでは元の存在が消え、DeletedUserだけが残る。DeletedUserにはもうgetName()もpost()もない。消去ではなく変容。これがBe, Don't Doの本質——削除すら存在として記述する。

---

## Doing から Being へ

|  | Doing | Being |
|---|---|---|
| 中心 | 動詞（どう動かすか） | 名詞（何であるか） |
| 変化 | 他者が変化させる | 自己が変容する |
| 時間 | 手順の連続 | 状態の変容 |
| 正しさ | テストによる検証 | 存在していること自体が証明 |
| 開発者 | 実装する人 | 存在の条件を定義する人 |

Note: ちなみに、変化の連鎖ということではUnixパイプも似ている。cat | grep | sort——しかしパイプは外からデータを加工していく。Beはオブジェクト自身が変容する。主語が違う。

---

## 異なる言葉、同じ問い

| 思想 | 概念 | Being |
|---|---|---|
| ヘラクレイトス | 万物流転 | Input → Being → Final |
| アリストテレス | 可能態 | Success\|Failure $being |
| 老子 | 無為 | #[Be] 宣言 |
| スピノザ | 必然的存在 | 意味変数 |
| フッサール | 内在における超越 | #[Input] + #[Inject] |
| 荘子 | 自己証明 | $been |
| ハイデガー | 言葉は存在の家 | クラス名＝世界構築 |
| 仏教 | 刹那滅 | 不可逆な変容 |

</div>

Note: ⏱ 37:00 収束｜時代も文化も言葉も違う人々が同じ場所に辿り着いた。哲学者は真理への問いから、私たちはドメインへの問いから。問いの本質が同じだった。

---

"The world is a system of ever-changing<br>relationships and structures."

</div>

<div class="epigraph">
テッド・ネルソン——5歳の時、湖でボートから手を水に入れた体験から
</div>

Note: 5歳の少年がボートから手を水に入れた。手の動きと水流の関係に心を奪われた。その体験から「世界は絶えず変化する関係と構造のシステム」と結論づけた。この少年が後にハイパーテキストを発明する。哲学者でなくても、問いを持てば同じ場所に辿り着く。

---

<pre style="max-width: 80%;"><code class="language-php">#[Be(NewParadigm::class)]
final class You
{
    public readonly Vision $vision;

public function __construct(
        #[Input]  Understanding $before,  // 内在
        #[Inject] Insight       $today,   // 超越（この後いなくなる）
    ) {
        $this->vision = new Vision($before, $today);
    }
}
</code></pre>

</div>

Note: ⏱ 38:30 締め｜$todayはこのプレゼンそのもの。もうすぐステージも私もいなくなる。でもその影響は$visionの中に生きている。超越は構築後に消える——しかし内在を変える。

---

<span style="color:#0071e3">$being</span>

</div>

Note: ここまで聞いてどう感じましたか？ ——新しい考え方に出会ったとき、人は2つの態度を取れる。手続き型だけの時代にOOPは奇妙に映った。好奇心を持ってトライするか、皆がうまくいったら乗るか。どちらが正しいということではない。でもその選択が明日のあなたを形作る。あなたはどんないうエンジニア、どういうbeingになりたいですか？