すごいH本の勉強終えた

amzn.to

すごいHaskellたのしく学ぼう!

を全てではないですが写経もしながら進めて、終えたので、読書感想文を書きます

そもそもなんでやってたの

なんとなく、

97 Things Every Programmer Should Know - Kevlin Henney (2010) にも「関数型言語の原則を適用せよ」とありますし、

関数型言語は一度は/一つは学んだほうが良いという共通認識があると思っていて、それは私にとっては大きな関心事ですし、強迫観念でもありました。

会社でもそんな話をしていると、「すごいH本」が良い、と何人かから聞いたので、とりあえずやってみるかー、と始めた次第です。(一応補足すると、『すごいHaskellたのしく学ぼう!』が日本では通称「すごいH本」とよばれているようです。)

完璧超人エンジニアになった?

入門も入門ではありますが、実際に関数型言語を勉強してみて、今後の成長曲線にプラスの影響はあると思います。

非線形の成長が得られた、とかではないです。

入門本を一冊通して読んだ(写経もしたが全部ではない)くらいでおこがましいですが、現時点では、普段のコーディングが飛躍的に改善するわけではなさそうです。

普段から map とか filter とか lambda はもちろん使っているし、関数型のような書き方はところどころでしているので、新しい武器を手に入れた、という感じではないです。

関数が副作用があるかどうか、とかも個人的には意識していると思ってます。(多くの場合は副作用があるとよみづらくなるんじゃないだろうか)

「関数型バンザイ」というよりは、 Kevlin Henney が言うように、関数型言語の考え方を知って、その原則を意識して適用できるようになることが大事なんだろうな、と思います。

なので、これからは関数型言語風の実装を意識的に扱っていこうと思います。そのうち、より洗練されたコードが当たり前に書けるようになっていると期待して。

雑多に感想

誤解していたのが、 純粋な関数言語なので、制約が厳しく、書き方が一通りしかない(あるいは少ない)と思っていた点です。 golang のように、誰が書いても似たような実装になる(これが正しいかどうかは立ち入らない)のでは、と勝手に思っていました。

ただ実際は1つのことを実現するのにも複数の書き方があり、制約が多いとかは全く関係ない視点の話でした。

あとやってる中でしょっちゅう思ってたのが、競プロの問題を解いてるときに、関数型だったらパッとかけそうだなー、とか。 先日ある問題をbacktracking でとく必要があって手間取ったのですが、普段から関数型を書いてる人ならこのあたり、あとは再帰とかも、日常的に考えるんだろうなーと妄想してました。

そういえば新しい武器も一応ありました。モナドをしれたのも良かったです。モナドも単語として聞いたことがあったものの、中身は全くわかってなかった(解説記事を読んでも理解できなかった)ので、これを機に一つ腹落ちしました。なお、厳密には数学的なモナドHaskellモナドは異なるらしいです、まぁいいでしょう。

Maybe 型コンストラクタも面白いですね。何かが失敗したかもしれない状態の表現を言語レベルで(というか標準ライブラリで?ファンクターで?)サポートしているのは新感覚でした。 世の中の言語はそれぞれ何かの課題を解決しようとしていて、一長一短なんだなと改めて感じました。短は別に書いてないですが。

このあとどうするの?

ここから Haskell を使って何か実装してみたいのですが、残念ながら他に優先して学びたいことができたので、そちらをやっていきます。 きっとまた戻ってきます

おわりに

深夜の殴り書きです。お手柔らかにお願いしますmm