ニコニコ大百科

記事立て乙です。誰も書き込んでないのに何故ほんわか推奨テンプレートをつけるしw
といいつつ早速釣られてみる。
関数型である以上、関数本体がファーストクラスなので名前付き関数は単に無名変数を名前に束縛したものだ、という視点は欲しいであります。今ではC++やJavaですらlambdaを持つ時代になって隔世の感あり・・・。

関数は入力のみで定まり隠れた状態を持つべきでないとする考え方自体は関数型以前からあるんだけど、それを徹底するとI/Oとかグローバルな副作用がどうしようもないやんけ、というのが現代関数型とそれ以外を分ける決定的なとこよね。OOPでもローカル変数は静的単一代入に限るとか、フィールドアクセスとその他の処理をきちんと分離するとかを守ると割といい感じのプログラムになる。

書き込みありがとうございます。いろいろ教えてください。
>何故ほんわか推奨テンプレートをつけるしw
いや、ちまたのブログとか読んでいると必要かなと...w

>名前付き関数は単に無名変数を名前に束縛したものだ、という視点は欲しいであります。
ラムダ計算の話をしたいということでしょうか。

>現代関数型とそれ以外を分ける決定的なとこよね。
「それ以外」というのが、古典的(?)関数型を指すのか非関数型を指すのかということを確認させていただければと。

>それを徹底するとI/Oとかグローバルな副作用がどうしようもない
この対策が
モナドで分離する: 純粋関数型言語
限定的に許容する: 関数型言語
プログラマの自主性にゆだねる: 非関数型言語
ようなイメージなんですが、ほかに対策方法はあるでしょうか。

> OOPでも～とかを守ると割といい感じのプログラムになる。
これができれば必ずしも関数型プログラミングにこだわらなくてもいいようにも思えるのですが、実際のところどうなんでしょうか。

>>名前付き関数は単に無名変数を名前に束縛したものだ、という視点は欲しいであります。
>ラムダ計算の話をしたいということでしょうか。
無名変数じゃないですね。無名関数でした。
ラムダ計算というか、関数オブジェクトのファーストクラス性ですかね(相互に関連はしますが)。クロージャ生成なりカリー化なりの関数->関数演算みたいなものが宣言なしに右辺値的に使えて、どこでも必要なら束縛を持ち込める感覚は関数型センスだと思います。それを文法として切り出すためのラムダと。

>>現代関数型とそれ以外を分ける決定的なとこよね。
>「それ以外」というのが、古典的(?)関数型を指すのか非関数型を指すのかということを確認させていただければと。
自分としては純粋関数型 <> 古典関数型+非関数型ぐらいのイメージです。
隠れた状態を持つなという発想は確かダイクストラの頃にはもう言われてて、必ずしも関数型固有のスローガンではないはずなんですよ。ただあらゆるプログラミングでそれをやるのは現実的じゃないので、文法などで強制するという話にはなりませんでした。ML辺りの古典関数型だと「書きにくく」することでなるだけ副作用を閉じ込めるようにはしてると思いますが、それでも全面的に禁止はしてませんしね。

>この対策が~
>ようなイメージなんですが、ほかに対策方法はあるでしょうか。
詳しくは知らないんですが、多分純粋関数型はモナドに限らないと思います(cleanはやり方が違うと聞いたことがあるんですけど、使ったことないので)
最近だとC++でもconstexprが付いたことで、部分的な関数型要素になったりしてますね。

>> OOPでも～とかを守ると割といい感じのプログラムになる。
>これができれば必ずしも関数型プログラミングにこだわらなくてもいいようにも思えるのですが、実際のところどうなんでしょうか。
というか、これを詰めていくと「関数型プログラミング」という呼ばれるスタイルに近づいていくんじゃないですかね。とはいえ型安全のレベルでカバーしたい等の要請を考慮すると、文法レベルのサポートがあるに越したことはない訳で現代言語がそちらに近づいているのは必然的な流れだと思います。
職業プログラマの主観としては、nil値の扱いと再代入への意識なんかは影響大きいのかな。Swiftのletとか個人的に萌えポイントなんですがw

>>3
ありがとうございます。
ファーストクラス性という専門用語を用いるとファーストクラス性の説明が必要になると思い、
>関数オブジェクトのファーストクラス性
= 関数を数値などと同じように関数に受け渡しすること
としてすでに書いたつもりなのですが、束縛が可能という点を強調したほうがよいということでしょうか。

>自分としては純粋関数型 <> 古典関数型+非関数型ぐらいのイメージです。
現代関数型 = 純粋関数型言語
古典関数型 = 非純粋関数型言語
ということでしょうか。

>これを詰めていくと「関数型プログラミング」という呼ばれるスタイルに近づいていくんじゃないですかね。
これはたぶんそうなんだと思って、関数型言語とは別に当記事を立てました。

横からですけどほんわかテンプレはつけない方がいいと思いますよ
注意喚起の他にこの記事は荒れてますよって意味合いもあるので
少なくとも私はこの記事を開いたときギョッとしましたね
本当に荒れてから付ければ良いんじゃないですか？

SQL がわかれば高階関数も怖くないｗ

>>5
>>2でお答えしたとおり、この話題についてのよそでの議論を見てからの結果ですのでさしあたって変更するつもりはありません。あしからずご了承ください。
> ギョッとしましたね
それは仕様です。記事を読むとき、掲示板に書き込むときは、荒れている記事を扱うときの注意と警戒をもって接していただければと存じます。

関数型プログラミング言語の派閥で争ってるとか想像しながら掲示板見たらほんわかしてて草

日本における関数型の第一人者毛の壁さんについても少しは触れてあげて

>>7
うーん。俺も正直「ほんわかレス推奨です」は不要だと思う。
というかこれが原因で荒れることも十分考えられる訳だし。ほんわかレスを推奨してても荒れる時は荒れるので、総合的なリスクを勘案すると、今は除去したほうがいいと思う。

多数決とか採る？

>>10
関数型プログラミングに関する議論に造詣の深い方か、自治の精神に燃えていらっしゃる方かで、こちらとしては違う受け止め方をしますが、後者の方でしたらお引き取り願います。

えぇ…ただの意見表明なんだけどこれが「自治の精神に燃えている」扱いになるんですかね？

十分なるでしょ
それも今までネットに存在してきた中でも最高レベルのに当てはまる

ワロタ

ほしかった情報が結構書いてあり助かった。
取り消し線はギョッとしたけど読了したら納得感あった。

経験則で極力イミュータブルにしておくとヒューマンエラー減らせる、というのがあるんで、
その観点から関数型プログラミングのいろんな概念を
取っ掛かりなりともつまみ食い読みできたのはありがたい。

>>15
ありがとうございます。
構想・下書きの段階からかなり手間をかけて作った甲斐がありました。
お褒め頂けて嬉しいです。