-
FRP は標準的なプログラミング言語で書かれた単純なライブラリとして提供され、Observer パターンのリスナーを置き換える。リスナーはコールバックとも呼ばれる
-
FRP により、物事を行う方法は大きく変わる。コードが改善され、あなたの思考がよい方向に変わる。さらに、経験してきたコードの書き方に意外に通じるものがあるため、既存のプロジェクトに段階的に取り入れるのも容易である。
- FRP は、複雑さの主な要因の1 つとなっている領域のコード、つまり「イベントの伝播」のコードを改善するためのプログラミング手法である
- 広く利用されているObserver パターンに代わるもの。「リスナー」や「コールバック」とも呼ばれる。
- イベント駆動型ロジックをコーディングするための、合成可能なモジュール型の手法。
- プログラムをその入力に対する反応として表現する。つまり、データフローとして表すという発想の転換。
- プログラムの状態管理に秩序をもたらすもの。
- 何か基礎的なもの。私たちが思うに、問題をObserver パターンで解こうとすると、最終的にFRP が生み出される。
- 通常は軽量なソフトウェアライブラリとして、標準的なプログラミング言語で実装される。
- ステートフルロジックに対する完全な組み込み言語と見なすことができる
Elliott の回答※1からの抜粋である。 実装よりも先に仕様について尋ねることから始めてくれて何よりです。FRP とは何かについては、さまざまな考えが広まっています。私にとってはずっと、（a）表示的、そして（b）時間的連続の2 つのことを意味しています。多くの人は、これらの特性をどちらも外してしまい、さまざまな「実装上」の概念にFRP を重ね合わせています。私の視点からすれば、それらはすべて的外れです。 「表示的」とは、明確で、単純で、実装に依存しない、合成的意味論の上に成り立っていることを意味します。そうした意味論は、それぞれの型や構成要素の意味を厳密に規定します。意味論の合成
（… Elliott の説明よくわからない…）
DEFINITION : 表示的意味論（denotational semantics）は、プログラミング言語の形式意味論の数学的な表現である。FRP システムでは、それにより、システムの形式仕様が提供されると同時に、合成性（compositionality）という重要な特性がいかなる場合もすべての構成要素に当てはまることが証明される
表示的意味論参考：http://mandel59.hateblo.jp/entry/2016/05/11/002356
ナトリウム（独: Natrium [ˈnaːtriʊm]、羅: Natrium）は原子番号 11、原子量 22.99 の元素、またその単体金属である。元素記号は Na。アルカリ金属元素の一つで、典型元素である。医薬学や栄養学などの分野ではソジウム（ソディウム、英: sodium [ˈsoʊdiəm]）とも言い、日本の工業分野では（特に化合物中において）曹達（ソーダ）と呼ばれる[※ 1]。毒物及び劇物取締法により劇物に指定されている[2]。
関数型ププグラミング（functional programming）の知識は前提としていない。さらに、FRP を使用するために必要な関数型プログラミングの概念はごく一部であり、読者が知っておかなければならないことについてはそのつど説明する。FRP により、関数型プログラミングの利点の多くを短期間で習得できる。そして、既存の言語でFRP を使用できる
図1-1：FRP は関数型プログラミングとリアクティブプログラミングの共通集
-
概して、「リアクティブプログラミング」と称されるシステムが分散処理を重視するのに対し、FRP はより粒度が細かく、最初から強い整合性が確保される。分散システムにおいてスケーラビリティを確保するには、整合性を緩めなければならない。その理由については、「11.3 分散処理」で説明する。FRP とリアクティブプログラミングとでは、この課題に対するアプローチが異なる。FRP を分散処理に役立てることは可能だが、それはFRP の設計目的ではない
-
Microsoft の Rx（ Reactive Extensions）※ 4 は、 本書 の 執筆 時点 では「 真 のFRP」ではなく、Akka と FRP の中間に位置する。Rx とFRP とでは、設計目標が異なっている。Rx は主にイベントハンドラの連鎖に関するもので、その方法としてさまざまな選択肢を用意している。FRP では、動作がより厳しく制御されるものの、その見返りとして強い保証が得られる。本書の内容のほとんどは、Rx にも応用できる。第6章では、Rx においてFRP に似ている部分を取り上げる
-
プログラマーはコンピュータで実行できるようにプログラムを書かなければならないが、それで終わりではない。コードの量が少ないか、ずば抜けた記憶力の持ち主でなければ、すべてのコードを同時に記憶しておくことは不可能である。このため、プログラムを簡単に変更できるような構造にすることがプログラマーの主な仕事となる。あるいは、プログラマーは複雑さに対処することに主眼を置く、と言ってもよいだろう
-
ステートマシンは本質的に推論するのが難しい
-
本書の内容は、強力で非常に一般的な抽象化に関連している。そしてこの抽象化を、ステートマシンの複雑さへの対処という問題に直接取り組むためのツールの1 つに加えることができる
- 私たちが解決しようとしている問題には、さまざまな困難が内在している。これは事実である。しかし、ほとんどの問題はそのやり方に原因がある。 ハイカーはよく、「悪天候などというものは存在せず、装備が不十分なだけである」と言う。それと同じで、まずいコードというものは存在せず、インフラストラクチャが不十分なだけである。 イベントベースのプログラムで発生するバグの大部分は予防できる。それが本書からのメッセージである
- 昔、壁がオレンジ色だった頃、そこに住んでいたネズミ（マウス）は現在私たちが知っているようなイベントソースではなく小動物であり、リストボックスなんてこの世に存在していなかった
(???)
- FRP では、通常のミュータブル（可変）な変数を使用しない。というのも、そうした変数は実行順序の変化に敏感だからだ。一般的なバグの1 つは、変数が更新される前、または更新された後に変数を読み取ろうとして、それを逆にしてしまうことである。 FRP は、状態をセルと呼ばれるコンテナに保存する。セルは更新通知と順序管理を自動的に行うため、順序の問題が解決される。状態は常に最新であり、状態が変化するタイミングは予測可能である
(セルという名前の由来はスプレッドシートからきている）
(サンプルプログラムを動かして見たかったけど動かなかった...)
mvn test -Pairline1 または ant airline
メモ[ERROR] Plugin org.apache.maven.plugins:maven-resources-plugin:2.6 or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.apache.maven.plugins:maven-resources-plugin:jar:2.6: Could not transfer artifact org.apache.maven.plugins:maven-resources-plugin:pom:2.6 from/to central (https://repo.maven.apache.org/maven2): sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target -> [Help 1]
本書では、あなたの前提のいくつかを疑ってもらうことになる。それにより、興味をかき立てられ、能力が試され、解放感を覚えるかもしれない。このプロセスを通じて、自分の信念を変えることになるか、自分の信念をさらに強めることになる。どちらにしても有益だが、一筋縄ではいかない。 ここからは、FRP で考えるための基礎を築いていくことにする。この作業は本書が終わるまで続くので、そのつもりで