12/08/18 01:36:00.45 .net
なんで日本はRubyオタクばっかなの？
51:uY
12/08/18 02:49:47.77 .net
Ruby会議とかいう謎の宗教活動が頻繁に行われてるからだよ
52:デフォルトの名無しさん
12/08/18 08:09:05.11 .net
Rubyにこだわらず、Haxeでもやればいいのに。
53:デフォルトの名無しさん
12/08/18 11:30:54.68 .net
RubyはHL
54:28
12/08/18 13:54:42.00 .net
(>>49の続き)
二番目の要望は、「可変(mutable)な操作と不変(immutable)な操作の明確化」です
具体的には、Rubyにはオブジェクトの状態を破壊的に更新するメソッドであれば、
そのメソッド名の末尾に !(感嘆符) を付けようという弱いルールが昔から存在していました
(この末尾感嘆符ルールは、Lisp文化に由来すると思われます)
けれどもこのルールは一般にはほとんど普及していませんし、
残念なことに組み込みクラスですらルールが守られていないケースがあります
たとえば、Hashクラスには二つのハッシュを(破壊的に)結合する可変操作merge!と
破壊せずに結合するmergeがある一方で、merge!と同じ可変操作updateが存在します
これはRuby 1.8 -> 1.9 の時点でupdateを廃止するか、あるいはdeprecate(非推奨)を
判断して、リファレンスへ反映させるべきでした
組み込み/標準のクラスですら平気で逸脱しているのだから、ユーザが遵守する訳がありません
関数型プログラミング作法の基本は
「(破壊的代入を含む)副作用を避けた参照透明性のあるプログラミング」
であり、Rubyにおいては
「副作用を極力避けたり、参照透明性のある部分とない部分を意識的に使い分ける、
あるいは副作用のあるコードを隠蔽する」
ことが、高品質コード設計技法では重要になります -- (LLバトルスレ25のレス#255も参照)
一般に普及している手続き型プログラミングでは破壊的操作が基本ですから、
「可変な操作と不変な操作の明確化」への関心はさほど強くなかったことが
現状の背景にあると思いますが、関数型プログラミングによる高品質コード設計では
こんな些細なこだわりも大切になるでしょう
(終わり)
55:デフォルトの名無しさん
12/08/18 14:14:33.06 .net
【関連サイト: Ruby編】
・Functional programming with Ruby
URLﾘﾝｸ(www.slideshare.net)
URLﾘﾝｸ(code.google.com)
・Thinking Functionally In Ruby – A Great Presentation by Tom Stuart
URLﾘﾝｸ(www.rubyinside.com)
・Functional Programming Techniques With Ruby: Part I & Part II
URLﾘﾝｸ(rubysource.com)
・Adventures in Functional Programming With Ruby
URLﾘﾝｸ(www.naildrivin5.com)
56:デフォルトの名無しさん
12/08/18 14:22:49.28 .net
Both support some functional programming constructs,
but Ruby is arguably better suited to a functional programming style.
Lambdas in Python are generally very short, because lambdas in Python are
restricted to expressions and cannot contain statements.
Ruby's lambda support is far more flexible,
allowing for lambda expressions of arbitrary length.
In a similar vein, Python 2.x's closure support is
more limited than Ruby's thanks to its limited support for lexical scope.
Python 3 introduces the nonlocal keyword which addresses this limitation
by allowing assignment to variables in outer non-global scopes.
On the other hand, as of version 1.8, which is still used widely,
Ruby does not support tail-call optimization for recursive functions,
whereas Python uses a decorator to implement tail-call optimization.
Ruby 1.9 ― the current stable release ― can currently be compiled to
support tail-call optimization.
"Functional Programming - Python vs Ruby"
URLﾘﾝｸ(www.wikivs.com)
57:デフォルトの名無しさん
12/08/18 14:57:41.48 .net
>>54
> 可変(mutable)な操作と不変(immutable)な操作の明確化
破壊的な操作を内部に一カ所でも含む関数は破壊的になるから、
まともに明確化して分けようとすると、結局 Haskell の IO モナドみたいになりそう。
58:デフォルトの名無しさん
12/08/18 15:15:03.27 .net
>>50
X: なんで日本はRubyオタクばっかなの？
O: なんで世界はRubyオタクばっかなの？
59:28
12/08/18 17:43:35.94 .net
>>57
>破壊的な操作を内部に一カ所でも含む関数は破壊的になる
これは事実であり、特に純粋関数型言語であるHaskellプログラミングでは絶対的な真理でしょう
ただし、別の切り口による２つの考え方もありえると思います
最初の切り口は「純粋関数型 vs. 不純関数型」です
たとえば関数型言語のML族(F#/OCaml/SML)では、不変(immutable)データを操作する
透過的なプログラミングが基本の作法ですが、「例外」として明示的な参照型宣言や
逐次演算子(SMLの場合は ;(セミコロン))を用いた手続き型プログラミングも可能です
言い換えると、純粋関数型言語パラダイムではあらゆる破壊的操作を拒絶するのに対し、
不純関数型言語パラダイムでは例外を受け入れる寛容な思想です
そして、たとえ不純関数型言語パラダイムであっても、(手続き型言語パラダイムと比較すれば)
コード品質に関する明らかな恩恵を享受できることも事実です
Rubyによる関数型プログラミングもまた「不純関数型パラダイム」になります
もう一つの切り口は「ソフトウェアアーキテクチャレベルでの分離」です
たとえばRailsフレームワークは「MVCアーキテクチャ」をもとに設計されていますが、
ModelはRDB操作が、Controlerはセッション管理があるので破壊的操作は避けられないでしょう
でもViewに関してはRDBから取り出した値からHTMLオブジェクトへの「写像」という
純粋な関数として定義できると確信しています
つまり、(クラス/モジュールよりも粒度の高い)コンポーネント/サブシステムという単位で
破壊的操作コードと非破壊コードを分離することが、現場の開発では可能であると考えています
またMVCアーキテクチャはシステムを水平方向に分割しますが、
垂直方向にシステムを分割する「階層化アーキテクチャ」という発想もあります
つまり、I/O処理を含む下位層のコンポーネントは破壊的操作で設計し、
上位層を非破壊操作で設計することになります
もちろん水平分割と垂直分割を組み合わせることも可能でしょう
こういった(コード設計よりも上流の)アーキテクチャ設計も高品質ソフトウェア開発では重要です
60:デフォルトの名無しさん
12/08/18 18:55:25.75 .net
>>59
例えば Ruby なら、破壊的操作には関数名に ! をつけましょうという、
ハンガリアンと同レベルの命名規則が提案されもしたが、
しっかりと守る人は少なかった。
一方 OCaml などにおいては、参照透過性を保つことを基本としながら、
その中に（明確にマークすることにより）破壊的操作を混ぜることに成功している。
こちらも、破壊的操作はできるが、できるだけ参照透過性を守ろうというのは、
いわば約束であって、そうしなければコンパイルが通らないという話ではないから、
そういう意味では Ruby の命名規則による約束と強制力という点で何ら変わらない。
どちらも約束であるのに、一方で失敗し、もう一方で成功しているのは、
あくまで参照透過性が基本という、関数型言語が培ってきた文化の力が大きいと思う。
LL というカテゴリ名が示すように簡単に軽く書けることを信条としてきた言語では、
約束程度の縛りでは「可変(mutable)な操作と不変(immutable)な操作の明確化」
にはなかなか至れないと思う。
自分はそのつもりで守っても、使ってるライブラリでそれを壊してたら、
逆にデバッグ時にある意味不要な柔軟な思考が要求され、ハマる可能性もある。
せめて、内部で一カ所でも破壊的操作が行われていたら、
関数名の末尾に ! を付ける事を構文化して、ルールを守らなければ
インタプリタやコンパイラから警告ではなくエラーを出すようにしないと
明確化には遠いと思う。
61:uy
12/08/18 19:53:44.14 .net
元々標準で
deleteとか
delete_if に!ついてねーもの
62:28
12/08/19 00:07:56.60 .net
>>60
同感ですね、特に次の一文が....
>どちらも約束であるのに、一方で失敗し、もう一方で成功しているのは、
>あくまで参照透過性が基本という、関数型言語が培ってきた文化の力が大きいと思う。
新しいパラダイムの普及や文化の移行には、長い時間が必要です
オブジェクト指向にしても、Smalltalk-80の日本上陸から現在の繁栄の時代まで20数年を要しました
関数型言語からLLの戦場に対応すべく異常進化した新種が誕生するのか(>>28)、
あるいはLL文化が関数型パラダイムへと移行するのか(>>49,54)、未来は予測できませんが
長い目で見守りつつ自身の技(わざ)を磨いていかなければならないと思います
Rubyに関しては、「簡単に軽く書ける」どころか「楽しいプログラミング」を信条としている訳で、
そのRuby固有のユニークな文化は今後も生き続けるでしょうし、自身もそれを望んでいます
Rubyで高品質設計が求められつつあるといっても、その主戦場の重要性に変わりはないのですから....
(>>49,54で言ってる事と矛盾しているような気がしないでもないけど、たぶん気のせいでしょうw)
だから関数型パラダイムへの移行期間では、
・関数型プログラミング技法を用いてRubyで「楽しく」プロトタイプを開発し、それをML族へ移植
・高品質な部品(コンポーネント)をML族で開発し、それらをRubyで糊付
といったアプローチもありかもしれません
また、現実のRubyプロジェクトでは、以下の施策を適用しています
・[>>49] すべてのメソッド定義の出入り口に専用の動的型検査メソッド呼び出しを入れる
・[>>54] 生の組み込みクラスを包む破壊/非破壊操作を分離した独自クラス
63:デフォルトの名無しさん
12/08/19 00:58:41.44 .net
Pythonの命名規則の定着具合はRubyやPerlみたいなウンコ言語より遥かにマシだからLLと言って一緒くたにすんなよ
64:デフォルトの名無しさん
12/08/19 01:03:40.72 .net
>>63
例えばどのような命名規則でしょうか。
このスレはあくまでLLにおける関数型プログラミングの話なので、
関数型プログラミングに関わりそうな部分だけで結構ですので、
いくつか例を挙げていただけないでしょうか。
65:デフォルトの名無しさん
12/08/19 01:07:43.30 .net
LLにおける関数型プログラミングの話という認識が間違ってる
Rubyしか知らないのに他のLLを巻き込むなよ
66:デフォルトの名無しさん
12/08/19 11:19:49.03 .net
PyhtonでもJavaScriptでも好きなネタを投入すればいいんじゃね？
67:デフォルトの名無しさん
12/08/19 12:09:10.92 .net
>>65
スレの趣旨を認めたくないのなら、ここに来ないでほしいのだが。
68:デフォルトの名無しさん
12/08/20 13:20:16.62 .net
そして誰もいなくなったｗ
69:デフォルトの名無しさん
12/08/20 21:08:34.51 .net
MLは悪くない言語なんだけど、関数型言語としては二流っていうか
関数型モドキのニセモノに過ぎないから
関数型プログラミングで得られるメリットはLLと然程変わらないね
だからMLユーザがしょぼいライブラリしか無いML処理系じゃなく
LLで関数型プログラミングやりたい気持ちは分かるよ、うん
70:デフォルトの名無しさん
12/08/20 21:57:51.18 .net
Pythonは、あまり過度な関数型プログラミングは推奨してないよ。
71:デフォルトの名無しさん
12/08/20 22:11:34.11 .net
「できる」のに推奨しないのと、「できない」から推奨しないとの間には大きな隔たりがある
楽々「できる」のと、苦労すれば「できないこともない」との間にも大きな隔たりがある
72:デフォルトの名無しさん
12/08/20 22:12:29.17 .net
>>69
>MLは悪くない言語なんだけど、関数型言語としては二流っていうか
>関数型モドキのニセモノに過ぎないから
小学生の書いた読書感想文？
73:デフォルトの名無しさん
12/08/20 22:19:52.16 .net
>>69
関数型言語としては二流である根拠をはっきり述べてくれ。
そして、関数型プログラミングで得られるメリットとは何かも述べてくれ。
もし気力が残っているのなら、そのメリットがMLでは得られないのは、
MLの何に原因があるのかも述べてくれると、大変よろしい。
74:デフォルトの名無しさん
12/08/20 22:21:02.41 .net
MLなんてマイナー言語けなされて無視出来ずに反応しちゃうのは
LLスレで暴れてたRuby&関数型マニアのキモイ奴だけだろ
75:デフォルトの名無しさん
12/08/20 22:31:20.32 .net
といふことは、MLをけなしているのはLLスレでプライドをズタズタにされたPythonマニア？
76:デフォルトの名無しさん
12/08/20 22:42:51.57 .net
LLスレでぼろくそに批判されて、ついにこんな糞スレに追放されておいて
プライドがズタズタになっていない>>28は本当に凄い
77:デフォルトの名無しさん
12/08/20 22:52:41.32 .net
図星だったようだね
78:デフォルトの名無しさん
12/08/20 22:57:09.67 .net
MLをゴミだと思う人間がみんなPythonユーザだったら
Pythonはシェア1位を取ってるよ
79:デフォルトの名無しさん
12/08/21 00:36:30.01 .net
根本的に可読性が低くなるから、普通の開発で推奨してる環境なんてないし
関数型プログラミングがやりやすい言語を選ぶなんてこともない
C++でもラムダが使える時代だから関数型プログラミング最高！という短絡思考はやめた方がいい
むしろ、Ruby以外は常識的判断により関数型からは慎重に距離を置いてる
結果としてRubyだけが関数型言語と同様の馬鹿げた真似をしてドヤ顔してるって感じ
本当にLisper得意の見下しって時代から何も進歩してない
まあML＆Rubyの人は好きにやれば良いんじゃないかな
80:デフォルトの名無しさん
12/08/21 02:24:04.28 .net
＞結果としてRubyだけが関数型言語と同様の馬鹿げた真似をしてドヤ顔してるって感じ
例えばどういうRubyコードのこと言ってる？
81:デフォルトの名無しさん
12/08/22 16:21:19.35 .net
ML を dis ってる人は、ML の派生も含めてダメだと言ってるの？
82:デフォルトの名無しさん
12/08/22 19:00:02.22 .net
OCaml使ってると、Haskellと比較して、基本設計が古くさいなぁ、と思うことはある
83:デフォルトの名無しさん
12/08/23 00:23:13.53 .net
ハスケルで組まれたプログラムがスパゲッティすぎてついていけない
84:デフォルトの名無しさん
12/08/23 02:10:44.07 .net
基本Mutableな言語はゴミとまでは言わないが、ゴミだぞ。
85:デフォルトの名無しさん
12/08/23 15:55:51.98 .net
こういう破壊的操作使いまくりのコードが
Rubyにおける関数型プログラミングなの？
def func n , aa , bb
Enumerator.new do | e |
a = aa.cycle
b = bb.cycle
[*[b]*n.-(1),a].cycle { |r|
e << r.next
}
end
end
86:uy
12/08/24 05:46:30.28 .net
質問ですチャーチ数の使い道を教えてください
これって
数値ではないわけで
チャーチ数のみでゲームをつくっても人間には何がおもしろいのかわからないものができあがりますよね
だからチャーチ数をどこかで人間がみて理解できる数値に変換していいんだとおもいますけど
それって途中までチャーチ数で演算した意味は？ってきかれるとまだ僕には答えられません
つまり最終成果物は十進数の数値なんですが
途中演算をλ計算でやる利点はなんですか？
なにがあるんですか？
87:uy
12/08/24 05:49:22.00 .net
あれ、もしかして桁が膨大になった場合ってラムダ計算のほうが高速ですか？
なんかそんな気がします
用途があるとすればそこでしょうか
88:uy
12/08/24 06:08:11.75 .net
はやくおしえて
これ凄いですね
演算速度がどれだけ桁増えても一定である気がします
それであってますか？
89:uy
12/08/24 06:10:55.61 .net
ねえ
レスまだ？
おそくない？
ラムダ計算はこんなに高速だってのにおまえ等は、、
cpu内部にラムダ計算入れるべき
90:uY
12/08/24 14:04:23.57 .net
もういいです
自分で理解した
ラムダ計算は最速の演算方法だ
91:デフォルトの名無しさん
12/08/24 14:19:30.26 .net
言葉先行のどこにでもいるだたのチンピラ？
92:デフォルトの名無しさん
12/08/25 03:04:49.02 .net
は？
93:デフォルトの名無しさん
12/08/28 10:35:52.33 .net
Rubyの設計が失敗してるということ。
94:デフォルトの名無しさん
12/08/28 10:49:11.57 .net
どこが失敗している？>ruby
95:uy
12/08/28 16:39:35.13 .net
何カ所か盛大にミスってる
nilの扱いと名前空間
けどｊａｖａにくらべたら全然余裕
96:デフォルトの名無しさん
12/09/01 14:32:43.71 .net
【関連サイト: JavaScript編】 -- Pyhton編: >>4, Ruby編: >>55
・JavaScript 第6版 - O'Reilly Japan
URLﾘﾝｸ(www.oreilly.co.jp)
-- 第5版からの改訂として、節「8.8 関数型プログラミング」が追加された
・Javascriptで学ぶ Functional Programming
URLﾘﾝｸ(www.slideshare.net)
・JavaScriptで始める関数型プログラミング 1-1 - サイバーエージェント公式クリエイターズブログ
URLﾘﾝｸ(ameblo.jp)
・エレガントな JavaScript を作成するための関数型プログラミングの使用 - IBM dw
URLﾘﾝｸ(www.ibm.com)
・A Modern Introduction to Programming with JavaScript and jQuery - Open Book Project
URLﾘﾝｸ(www.openbookproject.net)
・JavaScript as a Functional Language
URLﾘﾝｸ(www.ajaxprojects.com)
97:デフォルトの名無しさん
12/09/02 15:39:25.83 .net
死ねｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗカスｗｗｗｗｗｗｗｗｗｗｗｗ
98:28
12/09/05 00:28:47.76 .net
>>55にある記事の一つを勝手に翻訳してみた
Rubyによる関数型プログラミング -- Functional programming with Ruby
・URLﾘﾝｸ(www.h6.dion.ne.jp)
・URLﾘﾝｸ(www.h6.dion.ne.jp)
>>80
>>79のいう「関数型言語と同様の馬鹿げた真似をしてドヤ顔してる」とは、
たとえばこんな記事(および、記事に含まれるコード群)を指しているのだと思われ.....
99:デフォルトの名無しさん
12/12/10 16:00:53.19 .net
もうrubyの話とか要らん
100:デフォルトの名無しさん
13/05/04 12:59:24.13 .net
add = lambda x, y : x + y
curry = lambda x : lambda y : x + y
curry (1)(2)
add = lambda x, y, z : x + y + z
curry1 = lambda x, y : lambda z : x + y + z
curry2 = lambda x : lambda y : lambda z : x + y + z
101:28
13/06/23 07:15:39.33 .net
スレが停滞してるので、新たなネタを投入してみる
そのネタとは「LLによる関数型プログラミングの実践」であり、
ここまでの関数型プログラミングに関する「理屈」を一歩進めてその「実践」に着手してみた
まず、最近までRuby初心者スレPart52では「ブログアンテナのデータ管理」を題材にして
手続き型プログラミングスタイルでRubyコードを設計してきた（詳しくは初心者スレの#43等を参照）
URLﾘﾝｸ(www.h6.dion.ne.jp) -- UMLクラス図
URLﾘﾝｸ(www.h6.dion.ne.jp) -- 自動生成ドキュメント
URLﾘﾝｸ(play.island.ac)
このコード、>>54で書いた「末尾感嘆符ルール」に従い破壊的操作を伴うメソッドの末尾には
必ず ! (感嘆符)を付けるようにしていたけど、これを関数型プログラミングスタイルで書き直してみた
URLﾘﾝｸ(www.h6.dion.ne.jp) -- UMLクラス図
URLﾘﾝｸ(www.h6.dion.ne.jp) -- 自動生成ドキュメント
URLﾘﾝｸ(play.island.ac)
見れば分かるように、両者間には全体的なモジュール構造/クラス階層の設計に変更は無く、メソッド定義だけが異なる
また、>>59で書いた(垂直方向にシステムを分割する)「階層化アーキテクチャ」に従い、
下位層のPStoreデータベースをアクセスするクラス Store では破壊的操作メソッド update_blog! を定義した一方で、
その上位層では破壊的操作を一切用いない「純粋関数型パラダイム」で設計している
ただし純粋関数型と言いつつも一部では破壊的代入を(しかたなく)用いているけど、
操作対象をローカル変数に限定しているので、矛盾や問題には該当しないと思う
なお、>>62末尾で書いた施策の一つ「専用の動的型検査メソッド呼び出し」について、
実際に自作のアサーションライブラリ 'assertion.rb' を利用してコードを書いている（例: ASSERT.kind_of ....）
102:デフォルトの名無しさん
13/06/23 08:23:29.20 .net
2ちゃんはもうすっかり人居なくなったな
103:デフォルトの名無しさん
13/06/23 09:13:04.69 .net
>>102
みんなどこに行ったん？
104:デフォルトの名無しさん
13/07/14 NY:AN:NY.AN .net
大規模規制で半減したつうし、前プロバイダで規制やればあっさり消滅すんでねぇの？w
105:デフォルトの名無しさん
13/09/24 02:46:24.05 .net
rubyでcurry化は簡単便利
f=->x,y{2*x + 3*y}.curry
g=f[3]
puts g[4] #=>18
106:デフォルトの名無しさん
13/09/24 09:11:08.81 .net
そのくらいデフォでやれよ
その程度で簡単便利とか超わらえるわ
107:デフォルトの名無しさん
13/10/28 19:56:35.40 .net
それで自己参照できるん？
108:デフォルトの名無しさん
14/01/16 13:47:04.51 .net
ゴミ
109:デフォルトの名無しさん
14/01/20 01:07:25.28 .net
こんな本でた
JavaScriptで学ぶ関数型プログラミング
URLﾘﾝｸ(www.amazon.co.jp)
なんか面白そう
110:デフォルトの名無しさん
14/12/10 03:20:00.54 lFxVBhH5.net
そう思うなら脱アルゴリズムしたらいいんじゃない？
まあ頑張れ。
無駄な努力だと思うがな。
111:デフォルトの名無しさん
14/12/10 07:41:04.02 8efWXp1v.net
無名関数とクロージャの区別すらつかない
馬鹿(>>110)がいるスレはここですか？
112:デフォルトの名無しさん
14/12/10 09:24:15.87 GPUWLQKM.net
>>110
関数型言語全部敵に回して何が楽しいのか、さっぱり分からん。
113:デフォルトの名無しさん
14/12/10 18:52:40.21 naCNbx5k.net
関数をステートメントで書けるから関数プログラミングに適してると言いたいのかこの初心者は
114:デフォルトの名無しさん
14/12/11 04:18:01.16 fpObf9hC.net
馬鹿はクロージャスレでも散々に叩かれてたのに、頑なにオレオレ定義を振りかざしてたからな
しまいにゃ「真のクロージャ」だのよく分からないことを言い出す始末
115:デフォルトの名無しさん
14/12/15 12:38:25.66 ZETjn4CW.net
なにこれ、脱アルゴリズム君なの？
彼についてなら専用スレあるからそっちで。
116:デフォルトの名無しさん
14/12/23 18:15:43.45 ATuB6kuL.net
関数型には car/cdr は必須ですかね？haskell をみていてもそんな感じだけど
117:デフォルトの名無しさん
14/12/23 18:49:48.75 pWRQK/2A.net
むしろcar・cdrのような部分関数（空リストに対して定まらない）はなんだかんだ面倒。
使いやすいパターンマッチを導入して、car・cdrみたいなのは廃止、ってのが良い、と
いうのがほぼ確定した見解だと思う。
118:デフォルトの名無しさん
14/12/24 21:17:05.57 +1mcRXwz.net
map/reduce 等で car/cdr を隠すってこと？
119:デフォルトの名無しさん
14/12/24 21:30:06.24 kKJ427gL.net
パターンマッチって書いてあるじゃない
120:28
16/06/02 21:56:19.82 khWGy11Q.net
・関数型プログラミングにおけるクイックソート・アルゴリズムの実装
URLﾘﾝｸ(www.h6.dion.ne.jp)
121:デフォルトの名無しさん
17/02/09 13:52:49.36 Lyr2GEHi.net
LLってなーに？
122:デフォルトの名無しさん
17/02/10 23:52:57.41 5MVdS2z+.net
Lonely Lovely
孤独を愛する、孤高のプログラマのことさ
123:デフォルトの名無しさん
17/04/15 18:58:59.13 RhESs+iK.net
Lovely Lolita 幼女好きのことさ