これに加え、身体の上下の保温状態が異なる際に眠れなくなることに気づいた。この改善のためにパジャマとかいう寝具を導入する。あれが上下同じ素材で用意されているのはそういう意味があったのだな...意外と合理性に満ちてるよな周囲...とか思う。太陽の光を浴びて体内時計リセットとかいう謎システム正直あまり納得がいかないのだが、最終的に夜眠れるようになった手段がこれだった。人間は体内時計が25時間であって?それを日光に当たることでリセットし?夜眠気が来るようになる?どんな雑システムだよ。1日の長さに合わせて体内サイクルを設定しないからそんなことが起きるんだ。体内時計リセットするシステム組み込んでおいたからあとは運用でカバーしてくれ、という設計者の雑な思想が透けて見える。バカにしてるのか、ちゃんと直しておけ。いうのは冗談だが、人間というシステムは本当に良くわからない。一応もう少し説明すると、膝の裏に日光(というか強い光)を浴びせると体内時計がリセットされる、という論文が結構前に出たらしい。論文の主張はともかく、朝に膝の裏に30分ほど(時間としては十分すぎるほど長いと思われる)当てるようにしてみたその日から、僕は夜に眠れるようになった。日光を当てるだけなのでもちろん身体的な影響はほとんど認識出来ない。夜ちゃんと眠れるのだ。半信半疑だがあれから問題なく眠れている。いままでどれだけ苦労してきたと。ベトナムに半年ほど居たのだが、そのときやたら生活サイクルが整っており、うまくいっていた。食べ物のせいか?温暖な気候のせいか?と色々考えたが結局そのときはわからなかった。その後日本に帰って来てまた少しずつ睡眠がおかしくなっていったのだが、考えてみればあのとき住んで居た部屋は、朝日が強烈に差し込む部屋だった...まとめ夜食べない血糖値保つ風邪ひかない軽く運動する身体保温適切に室内温度湿度整える眠る際適切に保温する朝に日光を膝裏に当てるはじめに述べたようにこれは個人的な試行錯誤であり、全員に当てはまるとはとても思えない。眠れない原因は人によって異なるという仮説は、個人個人で隠れた(というか自分で気づいていない)睡眠パラメータの探索に役にたつかもしれない。睡眠がうまくいかないと、遅刻もまあ問題だが、そもそも動かない頭で働くのは非常につらいのだ。して社会的に死んでしまうという危機があった。僕みたいに身体的に鈍感な人間はどうやら多いようなので、何かの参考になればと思う。何か具体的な正しいステートメントが存在するときに、それを抽象化する試みは穴あきの文章を考えることから始まる。してその穴の部分にどれだけ一般的な単語を当てはめられるか、どれだけ一般化しても元のステートメントが正しいかを考えていく。いう過程は日常的に行う抽象化手段のひとつと思う。僕はジェネリクス、パラメトリック多相はプログラミングにとってとても重要な機能だと思っている。関数型言語や関数型プログラミングはそれなりに普及して来ている様だが、それらは「もし式の中に一般化したい箇所があるならばそこを変数として関数にしてしまえば良い」という手法を提供する。それを気軽にできる様な機能を提供する。パラメトリック多相はそれと似た様な機能を型レベルで提供する。型シグネチャの中で一般化したい部分があるならば切り取って型変数にしてしまえば良い、ということが気軽にできる様になる。それらは同じ様な動機によって必要になる手段だ。この考えはいろんな箇所で役に立つ。HaskellにはArrowという型クラスがあるが、これは`(->)`の抽象である。*`であるが何も問題はない。いったものが現れるのはそんなに不思議ではない。`mut`を抽象化したいという声をどこかで見た気がするが、実現可能性はともかく`mut`部分を変数化すると言うアイデアは面白い。`mut`とnon-`mut`を抽象化しても型チェック通すには多分`mut`相当の扱いをしないといけないよなー...とかそこから色々考えたりするわけだ。雑な抽象化の試みによってたまに新しい構造が見えたりするのは面白かったりする。02:52パラメトリック多相Tweet広告を非表示にするもっと読むコメントを書く2015-12-30最低限必要な言語機能チーム開発で必要な最低限の機能、条件を見極めたいと以前からずっと思っていた。その後の手法も考えているけど今は省略。polymorphismClosuresnullが存在しないことこの条件を満たすとなると途端にHaskellかOCamlあたりしかなくなるという現実。三番目がなかなかのネックだ。早くnullが無い言語が主流になってほしい。00:11最低限必要な言語機能Tweet広告を非表示にするもっと読むコメントを書く2015-11-25Parametricity最近parametricityについてジャバを書きながらずっと考えていたのだけど、割と便利な結論が出てきたと思う。任意の"デザインパターン"はparametricityを活用して構築出来る継承を用いたデザインパターンはできないだろ、とか突っ込まれそうだけど実質同じ用途だったら同じとする。そこの差異に興味はない。デザインパターンの定義はなんだよ、とかparametricityはなんだよとかも突っ込まれそうだけどまあそのうち。論自体はまだまだ続くのだけど。型クラス拡張版は簡単に導出できる。free!を基に考えてみるとか。あとプログラミングだけでなく一般の思考メソッドとしても用いることが出来る。そのうちまとめてどこかで発表するかもしれない。今まで設計に関する議論で気になってたことは、ドメインに踏み込めないことだ。そこをなんとかしたいとずっと考えていた。parametricityならドメインの問題に踏み込みつつドメイン情報を排除し、問題の構造パターンを正しく構築し、間違えずに再利用することが出来る。パターンを組み合わせても問題なく動く。素晴らしいじゃないか。現在は関数プログラミング周辺が賑やかになっている。polymorphismを活用するには静的型付き関数型言語はOOPLより良いものだ。その理由は関数がオブジェクトに比べて十分に小さいからだ。23:35ParametricityTweet広告を非表示にするもっと読むコメントを書く2015-11-04関数プログラミング交流会で発表したブログに書くという行為を忘れがちな昨今。9/13に関数プログラミング交流会があったので発表してきました。Ruichi関数プログラミングという題目のため、参加者はかなり広いと思われました。そのためわかり易い話題とわかり易い遷移を心がけつつコアな人にも何か持って帰るものがあるといいなーと作成しました。まあしかし発表時間の短さ故にかなり早口で喋ったため、置いて行かれたように感じた方もいたようです...twitterで質問がありましたが、スタックオーバーフローとかネタとしてはもう少しあったのですが流石に詰まりすぎかなと断念。並行プログラミングネタをもっと前面に押し出さないと題名負けかなーと思ったけどこれも色々あって断念。並行プログラミング関係なく継続モナドが便利なだけでは?という心の声を無視しつつスライドを完成させました。Haskell本を読めばわかるでしょう。並行周りは何かもう少しありそうだし色々試したいですね。STM良いですよねSTM。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。