  |
はてなキーワード: 関数型プログラミングとは
コーンフレークじゃなくて、Haskellだとして、全体のネタを書き直してくださいっていう指示した結果
ボケ＆ツッコミ「お願いしますー ありがとうございますー」
ツッコミ「あー ありがとうございますー ねっ 今Githubでスターをいただきましたけどもね」
ボケ＆ツッコミ「ありがとうございますー」
ツッコミ「ねー 有り難いですよ ほんとにね」
ボケ「入れておきましょう」
ボケ「いきなりですけどね うちのオカンがね 好きなプログラミング言語があるらしいんやけど」
ツッコミ「プログラミング言語の名前忘れてもうて どうなってんねそれ」
ツッコミ「分からへんの？ いや ほな俺がね おかんの好きなプログラミング言語 ちょっと一緒に考えてあげるから どんな特徴ゆうてたかってのを教えてみてよ」
ボケ「あのー関数型言語で、型システムが強力で、遅延評価するやつやって言うねんな」
ツッコミ「おー Haskellやないかい その特徴はもう完全にHaskellやがな」
ツッコミ「すぐ分かったやん こんなんもー」
ツッコミ「いやそうやろ？」
ボケ「オカンが言うには 将来の夢はそれで書かれたOSを使うことやって言うねんな」
ツッコミ「あー ほなHaskellと違うかぁ Haskell製のOSなんてまだ無いもんね」
ボケ「そやねん」
ツッコミ「HaskellはOSを作るのには向いてへんからなぁ」
ボケ「そやねんな」
ツッコミ「な？ Haskell側もOS開発に任命されたら荷が重いよあれ」
ボケ「そやねんそやねん」
ツッコミ「Haskellってそういうもんやから ほなHaskellちゃうがなこれ」
ボケ「そやねん」
ツッコミ「あれほなもう一度詳しく教えてくれる？」
ツッコミ「Haskellやないかい モナドは確かに難しいねんHaskellの でも俺はね あれはHaskellの良いところやと思うねん 俺の目は騙されへんよ 俺騙したら大したもんや」
ボケ「まあねー」
ツッコミ「ほんであれよー いざ使ってみたらね モナドのおかげでコードがスッキリするねん 俺は何でもお見通しやねんから Haskellのモナドなんて」
ツッコミ「そうやろ」
ボケ「オカンが言うには プロダクションで使うにはまだ早いって言うねんな」
ツッコミ「ほなHaskellちゃうやないかい プロダクションでHaskell使ったら 上司がひっくり返すもんね Haskellはねー まだ研究段階やから実務では使いにくいねん」
ボケ「そやねんそやねん」
ツッコミ「な？ Haskell使ってみたらだんだん罠が見えてくるから 最後ちょっとだけ避けてまうねんあれ」
ボケ「そやねんそやねん」
ボケ「そやねんな」
ツッコミ「Haskellちゃうがな ほな もうちょっとなんか言ってなかった？」
ボケ「学生の頃 なんでみんな憧れるんか分からんかったらしいねん」
ツッコミ「Haskellやないかい 学生の頃はHaskellとOCamlとLispに憧れるんやから あとSmalltalkも憧れたな Haskellそんなもんよ」
ツッコミ「そうやろ」
ボケ「オカンが言うには 関数型プログラミングの教科書に必ず載ってるっていうねん」
ツッコミ「ほなHaskellやないかい 教科書のサンプルコードにHaskellのコードが出てこんわけないやん」
ツッコミ「Haskellはね 関数型プログラミングの王道中の王道やねん」
ツッコミ「Haskellや絶対 ほな ほなもうちょっとなんかゆうてなかったか？」
ツッコミ「Haskellやないかい Yesodとかあるやろ な？ RubyとかPythonの次はHaskellが来るって言われてるねん 俺はそう思うよマジで Haskellや絶対」
ツッコミ「そうやて」
ボケ「オカンが言うには ジャンルでいうたら数学やっていうねん」
ツッコミ「ほなHaskellやないかい ジャンルで数学言うたらHaskellしかあらへんやん な？ Haskellは数学の理論がベースになってるんやで ラムダ計算とか圏論とかな」
ボケ「そやねんそやねん」
ツッコミ「ほなHaskellに決まりやないかい ほなもうちょっとなんかゆうてなかった？」
ツッコミ「Haskellやないかい Haskellは変数が不変やから 変数に感謝するのは当然やねん ね？ 状態変更せんと安心して使えるからな」
ボケ「そやねんそやねん」
ツッコミ「Javaとかの変数は裏切るからアカンねん Haskellの変数は一生そばにおってくれるから最高やで」
ボケ「でも分かれへんねん」
ツッコミ「分からへんことない おかんの好きなプログラミング言語はHaskell もぉ」
ボケ「でもオカンが言うには Haskellではないって言うねん」
ツッコミ「ほなHaskellちゃうやないかい オカンがHaskellではないと言うんやから Haskellちゃうがな」
ボケ「そやねん」
ツッコミ「先ゆえよ 俺がラムダ計算の説明してる時どう思っててんお前」
ツッコミ「ホンマに分からへんがなこれ どうなってんねんもう」
ボケ「んでオトンが言うにはな」
ツッコミ「オトン？」
趣味としてのそれら活動を否定するわけではないが、中途半端にWebサービスとかゲーム作ったり競プロやるくらいなら、興味ある分野の本の通読の方がよっっっっぽどためになるし、筋肉のように自分の身に付くよ。
個人によって実装力には差があるから一概には言えないものの、つよつよプログラマは「0.6人月だから大したもの作れないかも」とは言わないのではないかと判断した。つよつよなら、自分のやりたい作業に対して最低限必要な時間くらい分かる。
興味ある分野がないなら、強い静的型付けの関数型プログラミング入門とかどう。浅井健一著「プログラミングの基礎」でも読んだら。演習をやればゲームも作れるし。新刊の「コンピュータを操る」は情報科学的な考え方(プログラミング的思考と言われがちなもの)を押さえつつブロックプログラミングを紹介してるから、自分の勉強だけでなく子供の教育のためにもなるよ。
（私は入門書（象の絵のやつ）を読んだことがあるだけで、使ったことはまだありません。）
で、関数型言語の良さをアピールするひとからは、いい意味でのの宗教性というか敬虔さを
私は感じるんですよね。
本題。「関数型プログラミングが『銀の弾丸』である という非常識な常識 2022」 と題された長い文章をみつけました。
ここ。https://kentutorialbook.github.io/functionalprogramming2022
まるで熱心な信者による経典なので、ほとんどちゃんと読んでないし読む気も起きませんが、
流し読みをしていて、目に入った 次の一節 がとても私の心に刺さりました。
ーー我々が暮らしている「現実世界」はミュータブル（mutable）なのです。
を撤回させていただいて、
( https://kentutorialbook.github.io/functionalprogramming2022/#n0.19337518569281165 )
ちなみに、ミュータブルは「可変」、 イミュータブルは「不変」の意味。
まあ私も世俗的なSEをやってるので、まっさきに、↓くらいのことは、思うわけです。
多分、プログラミングの世界での、世間一般の反応も似たようなものかと。
ところがですね。
ところがですね。これ、意見戦わせても、たぶん議論でどうにもならず、宗教間の対立みたいなものになる気がするんですね。
というのも。上の文章でとりあげられている数学やら物理やらというのは、おそらくレトリックでしかなくて。
そのレトリックで、伝えられようとしているものは何かというと、
ビジネスの世界だろうが何だろうが、本来、世界は不変なものとして記述されるべき」
なぜなら、私が隠し持っている信念が、まさにそれに近しいものだからです。
物理学の法則が成り立たとうが、物理学の通じないアナーキーな世界であろうが
世界は不変であり、私自身による世界への介入なぞありえない、と直観的に思っています。
だから 「やればできる」 「世界は変えられる」 「努力は裏切らない」 みたいな言葉は大嫌いなわけです。
この直観を私は自分で勝手に、「離人症的世界観」と名付けています。
この世界観の持ち主は多分少数派で、社会から見れば異端どころか、害悪とみなされるかも。だから、隠し持っている。
関数型言語が好きな人も、おそらく私が似た直観と似たものを隠し持っているのでは、と、
私は思うのですね。
もし、離人症的世界観に基づくコミュニケーションが社会に浸透し、
「自分の意志や感情」すら、あたかもファーストクラスオブジェクトとしての関数のように、
客観的に表明されるようなコミュニケーションが、もしこの世の中に広まれば
そうでもならないと、関数型言語は流行らないだろうな。というのが私の予想。
ま、宗教てものは、広まるときは、あっと言う間らしいですから。
ひょっとしたら20年後くらいには、手続き型言語が滅びているかも。こればっかりは分かりませんけどね。
以上！
関数型プログラミングが『銀の弾丸』であるという非常識な常識2022のなにがダメなのかわからない人が多いようなので、個人攻撃をまったくせずにダメ出しする。
まず言っておくが、私はあの記事をほとんど読んでいない。しかし、簡単にダメ出しできる。
記事内を「末尾再帰」で検索してみよう。1か所もヒットしない。「末尾」でも1か所もヒットしない。そう、あの記事はめちゃくちゃ長いのに末尾再帰に触れていないのである。では「再帰」ならどうだろう。11か所ヒットした。しかし、具体的な再帰のコードはまったくない。長い記事内にあれだけ多数のコードを書いているにも関わらずである。
「末尾再帰って何？」とか「再帰ってそんな重要なの？」と思う読者も多いだろうから、末尾再帰の重要さだけ説明しよう。
あの記事は、forやwhileを使わないプログラミング手法を前提に書かれている。記事内を「制御」とかで検索すればわかる。
末尾再帰はforやwhileの代わりになるもので、そういったプログラミング手法には欠かせない。forもwhileも末尾再帰も使わないとなると、ツリー探索などのアルゴリズムを書くことが困難になる。(こういったことが苦手な私に思いつく他の方法は、setIntervalを無理やりforループの代わりにするくらい)
そもそも、ほとんどのJavaScript実行環境は、末尾再帰をサポートしていない。つまり、JavaScriptはforやwhileを使わずに込み入ったプログラムをまともに書けるような言語ではない。あの記事に書いてあるようなことをする言語ではないのである。私は別にそれでもいいのでTypeScript使いまくってるけど。classとか好きだし。
あの記事がJavaScriptを使っている理由は、JavaScriptが人気だからだろうか？もしそうだとしてもダメである。あの記事は「JavaScriptは、ほどんどの実行環境が末尾再帰をサポートしていない、このプログラミング手法に適していない言語である」といったこと自体に触れていない。人気のある言語を使いたいなら、他の末尾再帰をサポートしている人気言語を使えばいい。
ろくに読まなくても、他にもダメ出しできる。
関数型プログラミングで気になるのは、言語にもよるが実行速度やコンパイルにかかる時間である。銀の弾丸と言うからには、C言語を使うような場面でも銀の弾丸でなければならない。(Haskellの実行速度はC並に早くできるそうだが)
記事内を「パフォーマンス」で検索したところ、実行速度に関する箇所がヒットした。
記事の実行速度関連の内容を要約すると「最近はAWS・Azure・GoolgeCloudPlatformなどを使って並列計算するので、昔ながらの命令型の順次実行は不適切である」となる。私が嘘を言っていると思うなら、記事内を「パフォーマンス」とか「AWS」で検索してヒットした箇所の前後を読んで欲しい。そんなに長くはない。
@kis (id:nowokay) さんの以下の記事についてです。
https://nowokay.hatenablog.com/entry/2021/09/25/042831
ブコメにもあるようにちょっと内容が雑というかわかりにくいせいで賛否両論になってしまっていて、もしかしたら近いうちにアンサー記事が出るかもしれませんが、自分自身の理解を助けるためにも言わんとしていることを推測しつつ、自分の認識もまとめておこうと思い書くことにしました。明らかに誤読してそうな箇所があれば、指摘してください。
まずは前提を書いておかないと論点がぼやけると思うのでいちおう。
その他の前提:
2000年代に入って関数型プログラミングが脚光を浴び始めたのは、コンピュータ資源が潤沢になりパフォーマンスをそれほど気にしなくってよくなったことが大きな理由ではないか、という認識があります。
関数型プログラミング言語の内部実装を読んだことがないので推測ですが、データを不変にするということはその都度メモリ領域を新たに割り当てることになり、そのオーバーヘッドがプログラムのパフォーマンスに影響を与えるので、パフォーマンス要件がをシビアな場合、どうしてもメモリ割り当てや計算効率を考えるとミュータブルにせざるをえないと思います。が、ウェブアプリケーションに限っていえば、データベースアクセスやネットワークアクセスのレイテンシが大きいので、そうした相対的に細かいオーバーヘッドを無視しても（大抵の場合は）問題にならなくなった、というのが「時代」の流れなんだという認識です。
いっぽうで別の観点もあって、REST API や FaaS が一般化して、関数単位で処理を分割し、アプリケーション外部に配置することが当たり前になってきた現状があり、マイクロサービスのようにアプリケーション自体もモジュールの一単位として考えると、アプリケーション内部のモジュール同士でも関数ベースでやりとりする形になっても不自然ではないと考えられます。
元記事にもありますが、RPC の派生（実装？）として生まれた Java の CORBA や Microsoft の DCOM みたいな振る舞い付きのオブジェクト（コンポーネント）を共有しようという世界観は廃れ、REST API のような単一の振る舞い（エンドポイント）とそれにひもづく JSON のようなデータ構造のみを受け渡すやり方が一般的になったアプリケーション間通信の潮流と、計算機資源が潤沢になって再度脚光を浴びた関数型プログラミングが、レイヤーの違いを飛び越えてひとつになろうとしているのではないか、と。
つまり、元記事に書かれている「時代に合ってない」というのは、「データ構造と振る舞いが一体となったオブジェクト」のような「なにか」は、そうした背景があるために、どこにも存在する必要がなくなってきているのではないか、と解釈しました。
なので、以下のコメントはちょっと論点がずれてると思いました。
はあ？「再利用する方法としてはWeb APIが主流」って、その中身をオブジェクト指向で設計することは、全く矛盾しません。 部品化の単位は、慣習や柵などで大きく変わります。オブジェクト指向とはほぼ無関係です。
https://b.hatena.ne.jp/entry/4708813645995359202/comment/suikyojin
なんでサービスとして外とやり取りする話とサービスの内部設計の話をごっちゃにしてんだ。なんか理解度が怪しくない
https://b.hatena.ne.jp/entry/4708813645995359202/comment/ssssschang
たしかに、アプリケーション単位とアプリケーション内部のモジュール単位とでその表現形式を合わせる必要はないんですが、元記事の言わんとしていることはこの一文に端的に表れていると思います。
ソフトウェアの記述をまとめるという視点では主にステートレスな関数を分類できれば充分で、データと振る舞いをまとめたオブジェクトというのは大きすぎる、システムを分割して管理しやすくするという視点ではオブジェクトというのはライフサイクルやリソース管理の視点が足りず小さすぎる、ということで、オブジェクト指向の粒度でのソフトウェア管理は出番がなくなっているのではないか、と思います。
「オブジェクト指向でなぜつくるのか」という本がありますが、「え、いまどきオブジェクト指向でつくらなくない？」っていつも思います。内容的には、もうほとんどはオブジェクト指向関係ないソフトウェア工学の紹介になっていますね。
当該書籍は読んだので後半はまぁわかるんですが、前半は「え、いまでもオブジェクト指向でつくるのが主流じゃないの？」って思ってしまいます（オブジェクト指向の定義が「データ構造と振る舞いが一体となったオブジェクトの集まりとしてソフトウェアを組織化すること」なのであれば）。
Joe Armstrong が "Why OO Sucks" を書いたのが2000年とのことなのですが、そろそろこうした議論は収束に向かってほしいと個人的には思います（とっくに収束していると感じている方もいらっしゃるでしょうけど）。
わかるわかるwww。
とりあえず、Visual Studio などのIDEでできることは、Emacsは使わない。
普通の「テキストエディタ」の用途だけで使えばいいと思えば気も楽になるよ。
たまに Mac, Linux を使うとき、共通のインタフェースで複雑なカスタマイズが可能なエディタがあることがすごく助かってる。
なにしろ1984年生まれで、マウスが普及する前に生まれたエディタだ。
右手をマウスとキーボードで往復することを前提とした左手のC-c, C-v などのコピーペーストのショートカットの概念がない。
これが辛い。すごく他のアプリとかけ離れてて辛い。ここだけは脳にスイッチを作るしかない。英語と日本語おぼえるようなものだな。
あと考えてみたら、今やEmacsで使う時間の 99%は org-mode だなー。あははは。
org-mode で、Python とか Julia とかをデータと統合したりすると、Jypiter なみに柔軟なノートブックが作れる。
あとは、前のコメントにもあったが、 Lisp系とか、マイナーな関数型プログラミング言語 (Agda2とかね) はEmacsしか選択しないなー。
関数型プログラミングにある程度なれているstaticおじさんだけど
オブジェクト指向なんて今どき使う意味ないし。バインディングとビューモデルとかださくて、ほかはまあ、普通使っていればわかるだろうというかなんというか。
