プログラミング言語
つまりRichのいう「シンプル」というのは、「ひとつのものに、複数のことがらを混ぜ込まない」ということなのです。
シンプルというのは、まっすぐの糸のようなもので、シンプルでないものというのは、糸が絡まっている状態です
Complect
複数のものが絡み合い分離できないくらいに結びつくこと
Simpleなものを組み合わせることでcomplectなものを実現する
Simpleなものは結合、分離、が簡単にできる
complectなものはそれが難しい
テストや型システムは強力なガードレールのようなもので、シンプルさを保証してくれるものではない
抽象化というのは複雑さを隠すことではなく、実装の詳細を取り除くこと
命令型(手続き型)
計算とは、状態を変化させることである。
関数型
計算とは、式を簡約することである。
論理型
計算とは、命題を証明することである。
クラスとは集合、オブジェクトはその元であり、それぞれが名前を持つ(変数名とか)
例えば、インスタンスなんて作らずに全部 static メソッドでベタ書きされた方がよっぽどわかりやすいのに、それができてしまうからという理由で要らぬ副作用、すなわちオブジェクトの状態の変化が入りこんで、おかしなことになっている様子に出会ったことは何度となくあります。
階層構造のモデルで、問題を表現しきるのが難しいというのはリレーショナルデータベースを使ってたら知っているはずなのに、どうしてオブジェクトの関係を階層構造で表現したいと思うのでしょう。継承なんていらない。処理だけ欲しければ関数の方がいい。
巨大JSON vs 正規化されたRDB のような比較？
データに対する整理が正規化していくことだとすれば、プログラムに対する整理はtraitや型クラスによる整理？
機械翻訳？
入門向け
大学で応用代数を履修していれば読めそう
ギリギリわかる気がする
モノイドの定義は満たしてそう
Actris - Session-Type Based Reasoning in Separation Logic
面白かった。Actorモデルは表現力が足りないという仮説の下mutationなどを入れたモデルを開発。メッセージパッシングにsesstion type、mutationにseparation logicを使ってる。結果、actorにrefを渡してmutateするプログラムのreasoningができる。実装はIris。
https://www.youtube.com/watch?v=BDnbxBmwNyQ&list=PLyrlk8Xaylp5ojq0AVVXHrzvVb9zURgHd&index=5&t=0s
アクターモデルとメッセージパッシングの概要
Erlangのやつという理解
非同期、順序保証、信頼性
それらの問題
メッセージパッシングは銀の弾丸ではない
15個の大きなメンテされているScalaで書かれたプログラムを調査したところ、8割が別の並行モデルと組み合わせていた
dependent
以前にやり取りしたメッセージに対する依存
high-level
参照、チャネル、高階関数のやりとり
Key idea
Session types
チャネルのための型
安全性とセッションの忠実度の保証
Concurrent sepatration logic
状態を変更する並行プログラムについての推論のためのロジック
関数的な正しさを保証
Actris
Session type
わからん、断念
nominal subtyping (nominative; 公称型)
派生型であると宣言されたもののみを派生型とする
structural subtyping (structural; 構造型)
必要なメソッドを全て実装していれば継承関係無しに派生型とする
派生型関係が明示されたものの間でのみ成り立つのがnominal subtypingで、暗黙に（型の構造に基づいて）成立するのがstructural subtyping
検査例外
例外を適切に処理しないとコンパイルエラーになるタイプの例外
Javaでは開放/閉鎖原則に従い抽象化をしておかないとつらくなる
Rust の メソッド
code:a.rs
impl Rectangle {
// This is an instance method
// &self is sugar for self: &Self, where Self is the type of the
// caller object. In this case Self = Rectangle
fn area(&self) -> f64 {
...
}
}
第1引数である、 self は Erlang の gen_server の handle_call の state みたいなものだとみなすとすごくスッキリした
Erlang のように Smalltalk 的な オブジェクト指向 をやっていけということかもしれないと思った
プロセス間メッセージのやり取りの方式について
アクターモデルだと、各アクターがメールボックス(とそのアドレス)を持っている考え方
CSP(Communicating Sequential Processes)だと、バッファ的なキューがあって、そいつをchannel として扱うようにしている