2012年12月6日
リッチ・ヒッキーの脳への非公式ガイドの記事の翻訳
部分的には、Rich Hickeyのプログラミングの考え方を知った結果、Clojureを学ぶことができました。 リッチは、プログラミングの基本概念について明確で一貫性のある独自の見解を持っており、すべてのプログラマーがそれを使用して勝つことができると思います。 彼のスピーチの1つを見るたびに、誰かが私の考えを整理し整頓したという感じがします。
この記事（および、おそらく将来の記事）では、ヒッキー氏のユニークな視点を合理化し、カタログ化しようとします。 最終的には、彼のアイデアの簡単な要約をお願いします。 これにより、Clojureで書いている人のための検索可能なリファレンスと、Clojureを使用していない人のためのアクセス可能な紹介につながることを願っています。
以下のすべてのテキストは、Rich Hickey の講演「Are we there yet？」に基づいています。
エントリー
最新のOOP言語-Ruby、Java、Pythonなど -基本的な欠陥を含む-外部世界と現実の不正確なモデルに基づいて、予期せぬ困難をもたらします。 以下の概念の明示的な定義がありますが、これらの定義は正しくありません。
- 価値
- 都道府県
- アイデンティティ
- 時間
- 行動（行動）
以下では、これらの各ポイントについて、OOPと関数型プログラミング（以降FP）の観点を対比します。 しかし、最初に、OOPとFPの根底にある現実モデルを見てみましょう。これはまさに、上記の概念の定義に対する非常に多くの異なるアプローチの適用につながる根本的な違いです。
形而上学、プログラミング、そしてあなた：OOPとFPの比較
原則として、形而上学に関しては、物事は明確な形を失い始めますが、幸いなことに、これはある程度理にかなっています。
ウィキペディアが教えているように、形而上学は可能な限り広く2つの主な質問に答えようとします：
- 何がありますか？
- どのように見えますか？
Rich Hickeyは、「川とは何か？」という質問に対する答えの例を使用して、OOPとFPの形而上学の違いを説明します。
オブジェクト指向プログラミング
OOPの形而上学によると、川は現実の世界に実際に存在するものです。 私は知っています、私はあなたが尋ねるのを聞きます：「はい、そして何？」、しかし、信じてください、この声明の正確さは多くの哲学者を眠らせませんでした。
秘trickは、川が絶えず変化しており、その水が決して流れなくなることです。 PLOの観点から言えば、川には可変状態があり、その（状態）は常に変動していると言えます。
しかし、Riverオブジェクトとオブジェクト全体の状態が現実の世界で決して一定ではないという事実は、プログラムの基本的な構成要素としてそれらを考慮することを妨げるものではありません。 さらに、これは、状態がどのように変化しても、OOPの利点によって公開されます。厳密に記述されたインターフェイスと対話し、すべてが期待どおりに動作します。 オブジェクトは変更できますが、すべてのオブザーバーについて、まったく同じオブジェクトのままです。
これは、世界の直感的な認識と一致しています。 私のコーヒーカップの電子は動きますが、私が予想したように、まだコーヒーの味がします。
結局のところ、OOPでは、オブジェクトは考えます。 彼らはお互いに行動します。 繰り返しますが、これは、変化が他のオブジェクトに対するいくつかのオブジェクトのアクションの結果である世界についての私たちのアイデアに対応しています。 ManオブジェクトはDoorオブジェクトをプッシュし、Houseオブジェクトに移動します。
関数型プログラミング
FPの形而上学によれば、同じ川に2回入ることはできないと言えます。 私たちが目にするのは、変化に関係なく世界に存在し、他の離散的で変化しないものの組み合わせである、不連続で連続性のないものです。
「川」はそれ自体ではなく、それに関連する一連の現象に課せられる概念です。 この概念は非常に便利です-私はこれを説明することを気にしません-これは単なる概念です。
実際に存在するのは、粒子とプロセスです。 川は安定したオブジェクトではなく、特定のプロセスによって作成された一連の結合粒子です。
これらの粒子は相互に作用せず、変更することはできません。 彼らは何もできません。 変更は、あるオブジェクトの別のオブジェクトに対するアクションの結果ではなく、変更は不変のパーティクルに適用されたプロセスの結果です。 何かが変わったと言うのは、「ああ、これはこの粒子の流れの中の新しい粒子だ」というようなものです。 これは、HEADがGitリポジトリ内の新しいコミットを指すと言っているのと同じです。
さて、形而上学で十分です！ 次に、Valueから始めて、より有用なトピックを説明します。
価値
数字3、6、および42が値であることは明らかです。 数値は不変で一定です。
この意味で、OO言語には値の正しい定義がないことも明らかです。 Rich Hickeyが指摘しているように、インスタンスが不変部分で構成されるクラスを作成できますが、一般にクラスを不変値として表現する高レベルの概念はありません。
これは、OOPを使用する際の頭痛の主な原因の1つです。 オブジェクトの属性がどのように変更されたかを把握しようとして、何回髪を引き裂きましたか？ 実際、オブジェクト指向言語には、オブジェクトの状態が安定しているかどうかを判断する組み込みメカニズムがありません。
これが、競合プログラミングが非常に難しい理由の1つです。 シングルスレッドのアプリケーションであっても、これは問題であり、これが広範なテストスイートの作成を余儀なくされている理由です。 Wigオブジェクトでメソッドを呼び出しても、Hipster Pointsオブジェクトが変更されるとは限りません。
対照的に、関数型言語では、不変データの操作に重点が置かれています。 値は変わらないため、問題のクラス全体が単純に消えます。
アイデンティティ
スピーチで、ヒッキー氏は次のように述べています。
「最大の問題は、2つのことを混同していることです。 「時間とともに変化するものが私たちのオブジェクトであるという考えを表明しました。」
FPでは、バインドされたパーティクルのシーケンスを指定した単純な名前で操作します。 「川」は、川の「流れ」のプロセスによって生成されるシーケンスR1、R2、R3などに対応します。 gitのHEADに直接類似しています-それは実際の値を指す単なる名前です。 OOPでは、そのような違いはありません。
または、彼自身が言うように：
「対応とは、架空のオブジェクトと、因果関係のある一連の値（状態）の経時的なつながりです。 これらは、期間に名前を付けるために使用するラベルです。」
都道府県
OOPでは、状態の明確な定義はありません。 たぶん、これは「現在のオブジェクトのすべての属性の値」です。 そして、これは「今」を余儀なくされています。なぜなら、過去を調べることを可能にする言語学的メカニズムがないからです。
これは、FPのIDの概念と比較するとより明確になります。 Hixianユニバースでは、Stateは特定の時点での特定の値です。 （私にとって、この定義は本当にすべてをその場所に置きます。）
時間
OOPでは、時間についての本当のアイデアはありません。 すべてが今起こっています。 これが競合プログラミングの問題につながるものです。
対照的に、私たちが研究しているFPの世界では、時間の概念は明確に定義されています。 時間は、状態の命名（識別）プロセスの副産物です。
振る舞い
最後に、動作。 ここに書くことはあまりありません。おそらくスピーチはまだ見ますが、ヒッキー氏から引用して、考えさせてください。
「動作はありません。 雷があなたを襲ったとき、誰が「振る舞い」ているのですか？」
たぶんこれがスティーブ・イェッジに「名詞の王国での実行」を書くように促したのかもしれません
終わり
さて、今日は以上です。 この投稿がお役に立てば幸いです。 何か提案があれば、私はそれらを聞きたいです！
翻訳者メモ
この記事は完全に新鮮ではありませんが、私にとっては十分に興味深いと思われ、元の投稿へのコメントでは、おそらくより興味深いものです。 残念ながら、議論の翻訳は私の参加の範囲を超えています。