カリー化、部分適用、クロージャという間違いやすい三種についての簡単なメモ書き - Line 1: Error: Invalid Blog('by Esehara' )
追記 カリー化を間違えてカーリー化という表記をしていたのを修正しました。 そもそもカリー化とは何か 複数の引数を取る関数は、一つの引数を取る、関数を返す関数の連続として表現できるということ、と言葉で表現しても抽象的すぎるので、ちょっと式で表してみる。 まず初めにラムダの導入 例として、ある整数に対してプラス1する関数を定義する。このような関数は、として表現できる。 ここでこの関数はplusoneという名前を与えられているが、このx + 1という関数そのものを表現するような記法があると便利だろう。そこで、をそのような記法として定義する。 この記法を用いることにより、上記のはとして表現できるようになる。つまり、関数それ自体を表す記法を導入することによって、関数の名前と、関数それ自体を区別することができるようになる。 カリー化 このような考え方が便利なのは、関数を返す関数というものを表現できるよ
『マンガでわかる！関数型プログラミング』という漫画を連載することになるようです - Line 1: Error: Invalid Blog('by Esehara' )
近況 ふとした瞬間に虚しくなることがある いきさつ 今年、秀和システムから関数型プログラミングに関する本が出て、良くも悪くも、その本が注目を集めることになってしまいました。そんな中で色々な人が反応していましたし、自分もこのようなかたちで感想を書きました。 一方で、このような本を書かれるくらいであるならば、自分で真っ当な本を書けばいいわけだし、技術書を書くことなんて、そんな敷居の高いことではないというカウンターもあり、個人的にはそれも最もだなあ、という印象がありました。その中で自分なりに関数型プログラミングについて理解したことを元にQiitaに駄文をアップしたりしていました。間違ってたら、誰かが訂正してくれるだろうし、そのほうが自分にとって勉強になるだろう、と思うので。 ですが、「関数型プログラミング」というのは「なんだか難しい」という印象を覚えるのも事実のようです。実際に、最新の『Soft
在宅勤務始めました - Line 1: Error: Invalid Blog('by Esehara' )
この記事について この記事はHeartRails Advent Calendar3日目の筈でした。 趣旨 HeartRailsに入社した。そこで、リモートを通じて受託開発などを行っている。ちょうど1ヶ月ほど経ったので、リモートワークに関しての所感をメモしておこうというのが今回の記事の趣旨。 なぜリモートワークをやろうと考えたの? 割と働き方で体調を崩すことが多くあったので、「これは自分の働き方を見直さないとマズイな」と思い、あまり一般的な働き方に囚われず、自分にあった働き方を見つけようと思ったのがきっかけ。そうなると、現状として二つの働き方があって、「リモートワーク」か、あるいは「短時間勤務」になるかなと考えたので、そのあたりを中心に見直した結果、HeartRailsの働き方がマッチしているかなと思ったので、そういう経路で働き始めたという経路。 リモートワークを中心にすることに関して不安は
Pythonを退職します - Line 1: Error: Invalid Blog('by Esehara' )
Pythonが嫌いになったの? Pythonについて嫌気が差したとか、Pythonが嫌いになったわけではありません。これからも一番好きな言語は恐らくPythonですし、実際のところ、機会があればPythonは書こうと思います。ですので、決して言語としてPythonが嫌いになったわけではありません。 そもそも、職業プログラマとして、ちゃんとしたオブジェクト志向を教えてくれたのはPythonでした。Pythonは、その言語仕様からして、出来るだけ簡潔かつ、綺麗に書けるし、Pythonについて深く知れば、プログラミングとはどういうことなのかについて、詳しく知れるほどの、わかりやすい言語であることは事実ですし、初心者向け言語として、Pythonは強く押したいという気持ちは今も変わりませんし、ずっとPythonならびにそのコミュニティに関して感謝の気持ちはずっと忘れないでしょう。 また、近年ではPy
バブルソートよりも非効率なソートアルゴリズムを探して ―― ストゥージソートとスローソート - Line 1: Error: Invalid Blog('by Esehara' )
はじめに 恐らく、プログラマの中で配列内の要素を整列させたりするソートにお世話にならなかった人、というのは余り考えられないのではないでしょうか。しかし、とはいえ、大抵はソートを自前で実装せず、組み込み関数であったり、あるいは何らかのライブラリで済ませることが殆どだと思う。 車輪の再発明というよりも、バグとか、自分が考慮していなかった挙動などを避けるために、自前でソートを組むことは余りないのですが、とはいえ、自分なりにソートを実装して見ると、それがどういう特徴を持ったソートであるか、というのがわかりますし、また、ソートというのはいったいどういう操作で実現されるのかという洞察が深まってくるなあ、という実感があったりする。 なので、今回はあるソート二つについての話を書くのが趣旨です。 最高のアルゴリズムはある、だが最悪のアルゴリズムは何か 一口にソートといったところで、ソート自体にも銀の弾丸があ
迫り来る「forおじさん」と呼ばれる時代 - Line 1: Error: Invalid Blog('by Esehara' )
はじめに 今となっては、プログラマにとってなんとなく理解して利用できることが当たり前になりつつあるオブジェクト指向ですが、しかし、それこそ今から数年前には、この「オブジェクト指向」というのは、いわばおじさん達が変な方針を打ち出したりして「え、それ変な実装方針じゃねえの」というツッコミが入ったりしていました(ちなみにそのあたりの雰囲気については、この記事を読むと分かりやすいでしょう)。 もちろん、これはこれなりにメリットがあるのかもしれませんが、しかしそれはまた別のオブジェクト指向を利用したモデリングと比較してのことであって、「これだけでいい」と考える人はいないでしょう。 原則: だってそのほうが開発しやすいから まず最初に原則を考える必要があります。まずひとつに、必ずしもオブジェクト指向が正しいモデリングの方法ではないこと。少なくとも自分が思うに、オブジェクト指向を使うべき理由というのは、
ユニットテストを書かないことについて - Line 1: Error: Invalid Blog('by Esehara' )
はじめに 最近は、同じ職場で働いている人に対して、『テスト駆動開発入門』の本を貸したり、自分自身でも全く更地のところにユニットテストを書くという作業をやったり、あるいは実装中にもユニットテストを書かないと、コードを書く手が少し滞ってしまうくらいには、テストに依存している自分がいる。 さて、ここ最近で一連のテストの話が各方面から出ていて、それらの議論について興味深く感じる一方で、たとえば自分はそうだけど、「執拗にテストを書いているけれども、これで前に進んでいるんだろうが」という罪悪感みたいなのを抱えている人というのは、それなりにいるんじゃないかと。特にユニットテストを腐らせて、テスト自体を負債にしてしまった人であるなら特に。 ここ最近の、アジャイル開発であったりとか、あるいはプログラマのための本みたいなのを開いたりすると、たいてい「他のことは良いからテスト書け」と載っている一方で、見回してみ
むしろ数式が苦手だけど統計を勉強したいという人はRをやるといいかもしれない - Line 1: Error: Invalid Blog('by Esehara' )
はじめに なぜか唐突にRブームが俺の中でやってきてしまってどうしようもないので、Rの本を注文しまくってたりしていたら、下のような本の山が出来てしまいました。 これらの本を付箋でペタペタしながら読み進めていくうちに、段々とRというのはどういう言語で、どういう風に勉強するといいのか、という方針が固まってきたので、ここにメモをしておきます。 Rとはどのような言語か 一言で、しかも乱暴に言ってしまうならば「統計に特化したPHP」というのが一番雰囲気を伝えられるかもしれない。いや、PHPの悪評は知っているし、ガチでRをやっている人にとっては嫌がられることもわかっているけど、あえてそういう説明が、あくまで入り口としてはわかりやすいのではないかと。 どういうことかというのを言い訳します。 自分が読んだ感じだと、統計というのは、「何らかのデータ」と「分析するためのツールとしての数式」と「その数式が意図する
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
