生命としてのソフトウェア

生命としてのソフトウェアに重要なのは設計ではなく耐障害性と相互運用性で、前者はチェインオブレスポンシビリティ、後者はHTTPとJSONでいい気がする

ユーザのニーズを満たすことで人間から動き続けるためのリソースを獲得することができる。つまり人間という生態系から食物を得るのに相当する。

人間とのインターフェースも当面HTMLとJS主体でいいだろう。そのうちセンサー入力をHTTPでタプルスペースに投げるようになる。

Twitterも既存のタプルスペースだと思えば良い

実践の場でもある

既存の有益な働きをしているソフトウェアはオルガネラとして取り込めばよい

ミトコンドリアはそうやって生まれた

コードクローンが良くないのも、コードを抽象化する必要があるのも、そもそも認知能力の限られた人間が理解をしないといけないからであって、それの認知能力のバリアを超えるにはまず人間の認知能力をどうやって増強するかを考えるか、もしくは諦めて自然淘汰に任せるか

コードクローンで何が問題かというと、片方でバグを直してももう片方に波及しないことで、それをまとめるのがなぜ難しいかというと認知能力の乏しい人間には二つのコードが共通化してもよいものかどうか判断できないからだろう、生物は共通化しない

DNAの2か所に書かれた共通の配列に関してはRNAiで両方まとめて抑制できる、ある種の共通化だ

生物はコードクローンがあると交叉が起きやすくなるのでは？

両方を呼んでうまく行った方を取る

値は細胞質というグローバルスコープに書いてもいいし、リソソームみたいに小さく囲ってもよい

関数の引数が変わって呼び出し元が死ぬのは正しくない、メッセージを受け取れなかった呼び出し先が死ぬべきだ

関数が正しく働けなかった場合、それを実装した人に連絡が行けばよい

正しく動かなかった場合は古い実装にフォールバックすればいい

弱分類機を組み合わせて高性能な分類機を作れるように、弱プログラマを組み合わせてすごいプログラムが作れる仕組みが必要だ

エラーで無いが正しくない値を返す時が面倒なのか。多数決で負けたプログラムは縛り首か。

距離が定義できるなら一般化メジアンで正解を選んで、一番遠かったやつを縛り首

遺伝子と細胞質は受け継がれるが、経験は受け継がれない

インポート時にコピーして、呼び出して、エラーが起きたら前にコピーしたバージョンにフォールバックして、それでうまく動くならどういうデータでどのバージョンとどのバージョンの間で挙動が変わったかレポートしてくれるフレームワークがあればいい

「人間はソフトウェア全体を把握できない、自分がやろうとしている変更の影響範囲を把握できない」という前提に基づくプログラミング言語の設計

今のインポートは「手元に特定バージョンをコピー」と「共有の誰かが書き換えるかもしれないライブラリを参照」の二択。後者は最新に追随できるが壊される可能性がある、前者ば勝手に壊れないが最新版にもならない。インポート時に最新版をコピーして実行し、失敗したら以前のコピーへと順次フォールバック

根本的に言えば例外処理のうち、上に伝搬して最終的に死ぬタイプだけがメジャーになったのが間違い、再実行可能な例外が必要、上の例はそれが管理された形で使われている例と捉えられる

メモリの中身のうち、コストのかかるものを保存する、という判断を今は人間がやっているが、デフォルトで一分以上かかった関数の返り値は保存したらいいのでは？

その後、明示的に「メモ化必要ない」って指示したら保存しなくなればよい

レポートを驚きの大きさでスコア付け

フォークがたくさんあると困るのは人間がそれぞれを試すのにコストがかかるせいで、フォークだとわかってるなら自動で切り替えて試せばいい

プロセスを生かしたままモジュールを差し替えたり…erlangを参考に…と考えたけど時間のかかる処理がファイルシステムにメモされるならプロセス再起動してもコスト高くないよな

ソースコードがgitで管理されてることを前提にしたら、自分で履歴を遡って行って適切なバージョンを見つけられるな