LLにおける関数型プログラミング

1 ：2012/08/16 〜 最終レス ：2013/09/24

339 返信：153[sage] 投稿日：2012/08/16(木) 22:16:29.83
>>314
>関数型言語でなければならないという観点は間違ってる気がする
ああ、これについては同感だね
現状のどの関数型言語も文字列、パターン、ハッシュの操作に難があるから、
現行LLであるPerl/Python/Rubyを置き換えるには無理があると思う
ただし、関数型言語にも良い特性がある訳で、実際に(LLを含む)多くの言語に影響を与えている
だから自分は「LLにおける関数型プログラミング」に注目している

2 ：

そうか

3 ：

rubyが最強っていってんじゃん

4 ：

いい加減関数型とかうるさい

5 ：

>>1
> 現状のどの関数型言語も文字列、パターン、ハッシュの操作に難があるから、
その難というのを、もっと明確に言ってほしい。
たとえば、＊＊というプログラムをする上で必要な
文字列に関する＄＄という操作が、
どの関数型言語でもできない、あるいはやりにくい。
など
パターンとハッシュに関しても同様に。

6 ：

【関連サイト: Python編】
・関数型プログラミング HOWTO ― Python 2.7ja1 documentation
　http://www.python.jp/doc/nightly/howto/functional.html
・魅力的なPython: Pythonでの関数プログラミング: 第1回 - IBM dw
　http://www.ibm.com/developerworks/jp/linux/library/l-prog/
・Pythonの技法：関数型言語スタイル「関数の部分適用」 - ZDNet Japan
　http://builder.japan.zdnet.com/script/20364411/
・Pythonの"関数型"の機能の起源 - The History of Python.jp
　http://python-history-jp.blogspot.jp/2009/05/python.html

7 ：

カリー化なんかもRubyで簡単にできる時代
def add(a, b)
　return a + b
end
def curry(f, a)
　return lambda { |b| method(f).call(a, b) }
end
add1 = curry(:add, 1)
p add1.call(2)
Rubyは関数オブジェクトを扱えるので、
置き換えるも何も、既にRubyは関数型言語
当然純粋関数型言語ではないし、関数型言語らしく書かない事もできるけど、
関数型言語としての特性を備えている事に変わりはない
そもそもどの言語でも最近関数オブジェクトの取り入れが盛んで、
関数型言語かどうかという分類が既に成り立たなくなってる
C++11ですらカリー化できる時代、
可能なのはせいぜい純粋関数型言語か否かという区別程度だな
http://ideone.com/H82Pn

8 ：

同意ですよ

9 ：

>>7
それのどこがカリー化だアホめ

10 ：

関数名がカリーだろよく見ろ

11 ：

以降おいしいカレーとチャーハンの作り方のスレ

12 ：

間を取ってドライカレーで

13 ：

>>7
それはカリー化ではなく、部分適用です。

14 ：

http://www.ruby-doc.org/core-1.9.3/Proc.html#method-i-curry
はいはいわろ

15 ：

例えば f (a, b, c) という3引数の関数に対して、これをカリー化した関数というのは、
y (b, c) という2引数の関数を戻り値として返す1引数の関数 g (a) のことだ。
関数 f から関数 g を作ることをカリー化という。
では >>7 の中でカリー化された関数とはどれか、明確に示してみよ。

16 ：

んじゃこれで
1.9では>>14なんてのもあるみたいだが
def add(a, b)
　return a + b
end
def curry(f)
　return lambda { |a| lambda { |b| method(f).call(a, b) } }
end
add1 = curry(:add).call(1)
p add1.call(10)

17 ：

f :: (a, b, c) -> d から
g :: a -> (b -> (c -> d)) を作るのがカリー化

18 ：

>>16
２引数の場合しか動かんようなクソコードなら貼らなくて良いよ

19 ：

ソースコードに全角スペース入れる奴なんなの？

20 ：

お前は黙ってろ

21 ：

>>17
違う
f :: (a, b, c) -> d から
g :: a -> ((b, c) -> d) を作るのがカリー化だ。
-- Wikipedia : カリー化（http://ja.wikipedia.org/wiki/%E3%82%AB%E3%83%AA%E3%83%BC%E5%8C%96）
> 複数の引数をとる関数を、引数が「もとの関数の最初の引数」で戻り値が「もとの関数の残りの引数を取り結果を返す関数」であるような関数にすること。
カリー化された関数の戻り値は「もとの関数の残りの引数を取り結果を返す関数」だ。
(b, c) を勝手に b -> c -> と形を変えることまではカリー化には含まれない。

22 ：

>>21
ごめんねーwikipediaは英語見てたわーww
http://en.wikipedia.org/wiki/Currying
> In mathematics and computer science, currying is the technique of transforming a function
> that takes multiple arguments (or an n-tuple of arguments) in such a way that
> it can be called as a chain of functions each with a single argument (partial application).

23 ：

>>14がそれを満たしてんじゃないの？

24 ：

>>14 のレスはあぼーんされて見えないから無視する。
Ruby でカリー化が本当にできるのかどうかは知らない。
少なくとも、確実に >>7 はカリー化ではないと指摘しているだけだ。
>>16 もなんか怪しい気がする。
カリー化された関数とはどれのことか？

25 ：

>>16はcurry(:add)でカリー化はできてる
ただ、２引数にしか使えない
1.9ではまんまcurryメソッドが用意されてるので変な事する必要ない
http://www.ruby-doc.org/core-1.9.3/Proc.html#method-i-curry

26 ：

Pythonのfunctionalモジュールにcurryがあるけど
自前で定義するとこんな感じか
def curry(f):
    n = f.__code__.co_argcount
    def _(args=[]):
        return f(*args) if n == len(args) else lambda x: _(args + [x])
    return f if n == 0 else _()
@curry
def foo(a,b,c):
    return a + b + c
print(foo(1)(2)(3))

27 ：

そもそもrubyはHLですしおすし

28 ：

>>5
>その難というのを、もっと明確に言ってほしい。
現行のLLにはこれらデータを「簡潔に表現」できる専用の記法/構文がある
以下はRubyの例(これらはPerl(awk?)から影響を受けた(=パクッた)と思われる)
【文字列】　　文字列リテラルには「式展開」や「ヒアドキュメント」がある
　　　　　　たとえば "my name is #{$ruby}" は、format "my name is %s", $ruby よりも
　　　　　　簡潔に書ける
【パターン】　「正規表現リテラル」がある。たとえば /^Ruby is OOPL/ は、
　　　　　　Regexp.new "^Ruby is OOPL" よりも簡潔だ
【ハッシュ】　「ハッシュ式」とハッシュ操作のための構文がある
　　　　　　たとえば {a: 1, b: 2} は Hash.new [:a, 1, :b, 2] よりも簡潔だし、
　　　　　　obj[:a] は obj.fetch :a よりも簡潔に書ける
これらの記法/構文はRuby全体からすればほんの一部であり、
LLの主用途(主戦場)である日常的なテキスト処理に特化した様々な工夫が施されている
これらの多くは関数型言語ではライブラリ関数として提供され、
同等な処理は書けてもLLの専用記法/構文と比較すれば冗長である(=めんどくさい)と考える

29 ：

> {a: 1, b: 2}
この暗号みたいなの何？

30 ：

>>28
× 現行のLL
○ Ruby

31 ：

RubyってPerlが糞だと言われたことと同じ轍を踏んでるよな

32 ：

>>29
Ruby 1.9で導入された新しいハッシュ式の記法
以前の記法 {:a => 1, :b => 2} と同じ

33 ：

糞分かりにくいな

34 ：

>>31
UNIXプログラミング環境に住み慣れた人なら、
sh や awk でなじみがあるから好意的に受け止める人は多いのではないかと思う
少なくともWeb開発の世界では、Perlの記法を引き継いだPHP(と一部でRoR)が主流だし...
まあWindowsプログラマからすれば、これらの記法に違和感があるというのは認めるw

35 ：

PHPが主流なのはCの記法に似てるからだろｗ　何言ってんだコイツは…

36 ：

Rubyの関数型プログラミングスレで良かったんじゃねぇ〜？
元のLL云々ってRuby＆関数型マニアのコイツがLLスレで暴れたいだけの口実だったんだしぃ〜
なんかLLの話するのかと思って釣られてくる被害者が出そうだわぁ〜
まーた関数型言語用のお題ってのを早速コテみたいなのをつけ出したコイツが出してくるんだろぉ〜
都合の良いルールで縛ってさぁ〜、結論ありきの議論は面白いですかぁ〜

37 ：

>>36
>Rubyの関数型プログラミングスレで良かったんじゃねぇ〜？
んー自分はそれでも良かったけど、せっかく>>1がスレを立ててくれたんだから、
Rubyに限定せず、あらゆるLLで関数型プログラミングを語る場になれば....と思う
特に(>>6にあるように)Pythonは関数型プログラミングに関する情報が豊富みたいだから、
Python&関数型マニアの参加は大いに歓迎したいな

38 ：

でも実践的な話は一切出来ないみたいだから隔離して良かった

39 ：

>>28
camlp4使って構文拡張すれば足りるな

40 ：

＞Perlの記法を引き継いだPHP
＞Perlの記法を引き継いだPHP
＞Perlの記法を引き継いだPHP

それ変数につく$だけだろｗｗｗｗｗｗｗ
Perlの汚い部分を引き継いだのがPHP
綺麗な部分だけ選んで引き継いだのがRuby
Rubyでは$変数をあまり使わない
perと同じように $_ 使える部分もあるんだけど、基本的には使えない場所のが多い　使えてもいい気がするんだけどな

41 ：

>>33
実際にはActiveRecord/Rails系列の「キーワード風」メソッド引数の mes(sym1: val1, sym2: val2) のときに*しか*使用されない
これ以外の場面で使うのはなにもわかってないただのバカで早晩自爆するので放置でOK

42 ：

なんていうか
シンボルが
:symbol
こうだから
xx: 4
だといったん、タイプがとまるんだよね
かといって
:xx => 4
だとタイプ数があるし
2.0に期待するしかない

43 ：

>>28
では、逆に関数型言語にはあって、Ruby などの LL には無い機能や仕組みで、
是非 LL にも取り入れてほしいと思ってるものは何？
こちらも詳細にお願いします。

44 ：

Rubyは同じことをやるのに手段を大量に提供するコンセプトなのかもしれないけど
それって人のコード読むときに苦労するよな。そういう用途は対象外なのかもしれないが。

45 ：

>>44
大量の手段あるけど
それはC++みたいにソース見ただけじゃ何やってるかわからない構文は無いんだよ
手段とはいっても
オブジェクト.メソッド　で呼び出す形だから
メソッドの動作さえ覚えれば良いだけ
こういうところの考えからPythonとかのリスト内包表記は入れないんだと思う

46 ：

>>44
DSＬに関しては「読みにくくて書きづらくて覚えにくい」で意見の一致をみている
一時期ライブラリがなんでもかんでもDSLっぽい記述になったりもしたが、これからはそんなことは無いだろう

47 ：

殆どはリテラルの表記の問題ということだな

48 ：

バカには無理

49 ：

>>43
まず各LLにおける関数型プログラミングの適性度には大きな差異があること、
およびLLプログラミングではRubyしか深い経験/知識が(自分には)無いという理由から、
以降で述べる要望は「Rubyだけを対象」にしていることを断っておきます
最初の要望は、理想論であるけど「型推論を前提とした静的型付け」です
LLの主用途は(>>28で述べたように)日常的なテキスト処理であるけれど、
RailsやmRubyなどの登場によって「Rubyで製品を開発する」ケースが増えつつあります
この場合、生産性(効率的な開発)も大切ですが、長期間に渡って運用/開発が継続するという
性格から、品質(バグ発生率や保守性)が最も重要であると考えます
この高品質コード設計においては、生産性(簡潔さ)と高品質(安全性)を兼ね備えた
「型推論を前提とした静的型付け」がRubyに求められることになるでしょう
ただし、サブセットのRuby言語仕様であれば型推論の実験的実装について
いくつかの報告が存在しますが、完全なRuby言語仕様についてはかなり遠い目標でしょう
そこで、これに代わる現実論(=妥協案)として「省略可能な動的型検査構文」を要望したい
これは単純に def hoge(num : Integer, str : String) : MyClass といった構文でもいいし、
typexpr Integer * String -> MyClass のような明示的型式宣言でもいいし、
あるいはPythonのデコレータ記法を応用した型検査手法をパクってもいいと思います
なお、当たり前ですがこの要望は組み込み/標準添付ライブラリに関しても適用されるべきです
この要望は、ドキュメンテーションの改善にも役立てることができます
現在のRubyコミュニティでは、コメントとして記述された型情報を含む解説を抽出するという
JavaDocスタイルの文書化が主流です(たとえば「引数 num は整数、str は文字列 ......」)
ここで、もしも動的型検査構文が導入され、かつ型情報を外部へ出力できるようになれば、
そこからメソッドの型に関する解説を文書の一部として自動生成できるようになるはずです
また「コードとコメントの乖離」というJavaDocスタイル固有の問題(の一部)も解消されます
(続きは、また明日)

50 ：

なんで日本はRubyオタクばっかなの？

51 ：

Ruby会議とかいう謎の宗教活動が頻繁に行われてるからだよ

52 ：

Rubyにこだわらず、Haxeでもやればいいのに。

53 ：

RubyはHL

54 ：

(>>49の続き)
二番目の要望は、「可変(mutable)な操作と不変(immutable)な操作の明確化」です
具体的には、Rubyにはオブジェクトの状態を破壊的に更新するメソッドであれば、
そのメソッド名の末尾に !(感嘆符) を付けようという弱いルールが昔から存在していました
(この末尾感嘆符ルールは、Lisp文化に由来すると思われます)
けれどもこのルールは一般にはほとんど普及していませんし、
残念なことに組み込みクラスですらルールが守られていないケースがあります
たとえば、Hashクラスには二つのハッシュを(破壊的に)結合する可変操作merge!と
破壊せずに結合するmergeがある一方で、merge!と同じ可変操作updateが存在します
これはRuby 1.8 -> 1.9 の時点でupdateを廃止するか、あるいはdeprecate(非推奨)を
判断して、リファレンスへ反映させるべきでした
組み込み/標準のクラスですら平気で逸脱しているのだから、ユーザが遵守する訳がありません
関数型プログラミング作法の基本は
「(破壊的代入を含む)副作用を避けた参照透明性のあるプログラミング」
であり、Rubyにおいては
「副作用を極力避けたり、参照透明性のある部分とない部分を意識的に使い分ける、
　あるいは副作用のあるコードを隠蔽する」
ことが、高品質コード設計技法では重要になります -- (LLバトルスレ25のレス#255も参照)
一般に普及している手続き型プログラミングでは破壊的操作が基本ですから、
「可変な操作と不変な操作の明確化」への関心はさほど強くなかったことが
現状の背景にあると思いますが、関数型プログラミングによる高品質コード設計では
こんな些細なこだわりも大切になるでしょう
(終わり)

55 ：

【関連サイト: Ruby編】
・Functional programming with Ruby
　http://www.slideshare.net/tokland/functional-programming-with-ruby-9975242
　http://code.google.com/p/tokland/wiki/RubyFunctionalProgramming
・Thinking Functionally In Ruby – A Great Presentation by Tom Stuart
　http://www.rubyinside.com/functional-programming-in-ruby-2713.html
・Functional Programming Techniques With Ruby: Part I & Part II
　http://rubysource.com/tag/functional-programming/
・Adventures in Functional Programming With Ruby
　http://www.naildrivin5.com/blog/2012/07/17/adventures-in-functional-programming-with-ruby.html

56 ：

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"
　http://www.wikivs.com/wiki/Python_vs_Ruby#Functional_Programming

57 ：

>>54
> 可変(mutable)な操作と不変(immutable)な操作の明確化
破壊的な操作を内部に一カ所でも含む関数は破壊的になるから、
まともに明確化して分けようとすると、結局 Haskell の IO モナドみたいになりそう。

58 ：

>>50
X: なんで日本はRubyオタクばっかなの？
O: なんで世界はRubyオタクばっかなの？

59 ：

>>57
>破壊的な操作を内部に一カ所でも含む関数は破壊的になる
これは事実であり、特に純粋関数型言語であるHaskellプログラミングでは絶対的な真理でしょう
ただし、別の切り口による２つの考え方もありえると思います
最初の切り口は「純粋関数型 vs. 不純関数型」です
たとえば関数型言語のML族(F#/OCaml/SML)では、不変(immutable)データを操作する
透過的なプログラミングが基本の作法ですが、「例外」として明示的な参照型宣言や
逐次演算子(SMLの場合は ;(セミコロン))を用いた手続き型プログラミングも可能です
言い換えると、純粋関数型言語パラダイムではあらゆる破壊的操作を拒絶するのに対し、
不純関数型言語パラダイムでは例外を受け入れる寛容な思想です
そして、たとえ不純関数型言語パラダイムであっても、(手続き型言語パラダイムと比較すれば)
コード品質に関する明らかな恩恵を享受できることも事実です
Rubyによる関数型プログラミングもまた「不純関数型パラダイム」になります
もう一つの切り口は「ソフトウェアアーキテクチャレベルでの分離」です
たとえばRailsフレームワークは「MVCアーキテクチャ」をもとに設計されていますが、
ModelはRDB操作が、Controlerはセッション管理があるので破壊的操作は避けられないでしょう
でもViewに関してはRDBから取り出した値からHTMLオブジェクトへの「写像」という
純粋な関数として定義できると確信しています
つまり、(クラス/モジュールよりも粒度の高い)コンポーネント/サブシステムという単位で
破壊的操作コードと非破壊コードを分離することが、現場の開発では可能であると考えています
またMVCアーキテクチャはシステムを水平方向に分割しますが、
垂直方向にシステムを分割する「階層化アーキテクチャ」という発想もあります
つまり、I/O処理を含む下位層のコンポーネントは破壊的操作で設計し、
上位層を非破壊操作で設計することになります
もちろん水平分割と垂直分割を組み合わせることも可能でしょう
こういった(コード設計よりも上流の)アーキテクチャ設計も高品質ソフトウェア開発では重要です

60 ：

>>59
例えば Ruby なら、破壊的操作には関数名に ! をつけましょうという、
ハンガリアンと同レベルの命名規則が提案されもしたが、
しっかりと守る人は少なかった。
一方 OCaml などにおいては、参照透過性を保つことを基本としながら、
その中に（明確にマークすることにより）破壊的操作を混ぜることに成功している。
こちらも、破壊的操作はできるが、できるだけ参照透過性を守ろうというのは、
いわば約束であって、そうしなければコンパイルが通らないという話ではないから、
そういう意味では Ruby の命名規則による約束と強制力という点で何ら変わらない。
どちらも約束であるのに、一方で失敗し、もう一方で成功しているのは、
あくまで参照透過性が基本という、関数型言語が培ってきた文化の力が大きいと思う。
LL というカテゴリ名が示すように簡単に軽く書けることを信条としてきた言語では、
約束程度の縛りでは「可変(mutable)な操作と不変(immutable)な操作の明確化」
にはなかなか至れないと思う。
自分はそのつもりで守っても、使ってるライブラリでそれを壊してたら、
逆にデバッグ時にある意味不要な柔軟な思考が要求され、ハマる可能性もある。
せめて、内部で一カ所でも破壊的操作が行われていたら、
関数名の末尾に ! を付ける事を構文化して、ルールを守らなければ
インタプリタやコンパイラから警告ではなくエラーを出すようにしないと
明確化には遠いと思う。

61 ：

元々標準で
deleteとか
delete_if に!ついてねーもの

62 ：

>>60
同感ですね、特に次の一文が....
>どちらも約束であるのに、一方で失敗し、もう一方で成功しているのは、
>あくまで参照透過性が基本という、関数型言語が培ってきた文化の力が大きいと思う。
新しいパラダイムの普及や文化の移行には、長い時間が必要です
オブジェクト指向にしても、Smalltalk-80の日本上陸から現在の繁栄の時代まで20数年を要しました
関数型言語からLLの戦場に対応すべく異常進化した新種が誕生するのか(>>28)、
あるいはLL文化が関数型パラダイムへと移行するのか(>>49,54)、未来は予測できませんが
長い目で見守りつつ自身の技(わざ)を磨いていかなければならないと思います
Rubyに関しては、「簡単に軽く書ける」どころか「楽しいプログラミング」を信条としている訳で、
そのRuby固有のユニークな文化は今後も生き続けるでしょうし、自身もそれを望んでいます
Rubyで高品質設計が求められつつあるといっても、その主戦場の重要性に変わりはないのですから....
(>>49,54で言ってる事と矛盾しているような気がしないでもないけど、たぶん気のせいでしょうw)
だから関数型パラダイムへの移行期間では、
・関数型プログラミング技法を用いてRubyで「楽しく」プロトタイプを開発し、それをML族へ移植
・高品質な部品(コンポーネント)をML族で開発し、それらをRubyで糊付
といったアプローチもありかもしれません
また、現実のRubyプロジェクトでは、以下の施策を適用しています
・[>>49] すべてのメソッド定義の出入り口に専用の動的型検査メソッド呼び出しを入れる
・[>>54] 生の組み込みクラスを包む破壊/非破壊操作を分離した独自クラス

63 ：

Pythonの命名規則の定着具合はRubyやPerlみたいなウンコ言語より遥かにマシだからLLと言って一緒くたにすんなよ

64 ：

>>63
例えばどのような命名規則でしょうか。
このスレはあくまでLLにおける関数型プログラミングの話なので、
関数型プログラミングに関わりそうな部分だけで結構ですので、
いくつか例を挙げていただけないでしょうか。

65 ：

LLにおける関数型プログラミングの話という認識が間違ってる
Rubyしか知らないのに他のLLを巻き込むなよ

66 ：

PyhtonでもJavaScriptでも好きなネタを投入すればいいんじゃね？

67 ：

>>65
スレの趣旨を認めたくないのなら、ここに来ないでほしいのだが。

68 ：

そして誰もいなくなったｗ

69 ：

MLは悪くない言語なんだけど、関数型言語としては二流っていうか
関数型モドキのニセモノに過ぎないから
関数型プログラミングで得られるメリットはLLと然程変わらないね
だからMLユーザがしょぼいライブラリしか無いML処理系じゃなく
LLで関数型プログラミングやりたい気持ちは分かるよ、うん

70 ：

Pythonは、あまり過度な関数型プログラミングは推奨してないよ。

71 ：

「できる」のに推奨しないのと、「できない」から推奨しないとの間には大きな隔たりがある
楽々「できる」のと、苦労すれば「できないこともない」との間にも大きな隔たりがある

72 ：

>>69
>MLは悪くない言語なんだけど、関数型言語としては二流っていうか
>関数型モドキのニセモノに過ぎないから
小学生の書いた読書感想文？

73 ：

>>69
関数型言語としては二流である根拠をはっきり述べてくれ。
そして、関数型プログラミングで得られるメリットとは何かも述べてくれ。
もし気力が残っているのなら、そのメリットがMLでは得られないのは、
MLの何に原因があるのかも述べてくれると、大変よろしい。

74 ：

MLなんてマイナー言語けなされて無視出来ずに反応しちゃうのは
LLスレで暴れてたRuby&関数型マニアのキモイ奴だけだろ

75 ：

といふことは、MLをけなしているのはLLスレでプライドをズタズタにされたPythonマニア？

76 ：

LLスレでぼろくそに批判されて、ついにこんな糞スレに追放されておいて
プライドがズタズタになっていない>>28は本当に凄い

77 ：

図星だったようだね

78 ：

MLをゴミだと思う人間がみんなPythonユーザだったら
Pythonはシェア1位を取ってるよ

79 ：

根本的に可読性が低くなるから、普通の開発で推奨してる環境なんてないし
関数型プログラミングがやりやすい言語を選ぶなんてこともない
C++でもラムダが使える時代だから関数型プログラミング最高！という短絡思考はやめた方がいい
むしろ、Ruby以外は常識的判断により関数型からは慎重に距離を置いてる
結果としてRubyだけが関数型言語と同様の馬鹿げた真似をしてドヤ顔してるって感じ
本当にLisper得意の見下しって時代から何も進歩してない
まあML＆Rubyの人は好きにやれば良いんじゃないかな

80 ：

＞結果としてRubyだけが関数型言語と同様の馬鹿げた真似をしてドヤ顔してるって感じ
例えばどういうRubyコードのこと言ってる？

81 ：

ML を dis ってる人は、ML の派生も含めてダメだと言ってるの？

82 ：

OCaml使ってると、Haskellと比較して、基本設計が古くさいなぁ、と思うことはある

83 ：

ハスケルで組まれたプログラムがスパゲッティすぎてついていけない

84 ：

基本Mutableな言語はゴミとまでは言わないが、ゴミだぞ。

85 ：

こういう破壊的操作使いまくりのコードが
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 ：

質問ですチャーチ数の使い道を教えてください
これって
数値ではないわけで
チャーチ数のみでゲームをつくっても人間には何がおもしろいのかわからないものができあがりますよね
だからチャーチ数をどこかで人間がみて理解できる数値に変換していいんだとおもいますけど
それって途中までチャーチ数で演算した意味は？ってきかれるとまだ僕には答えられません
つまり最終成果物は十進数の数値なんですが
途中演算をλ計算でやる利点はなんですか？
なにがあるんですか？

87 ：

あれ、もしかして桁が膨大になった場合ってラムダ計算のほうが高速ですか？
なんかそんな気がします
用途があるとすればそこでしょうか

88 ：

はやくおしえて
これ凄いですね
演算速度がどれだけ桁増えても一定である気がします
それであってますか？

89 ：

ねえ
レスまだ？
おそくない？
ラムダ計算はこんなに高速だってのにおまえ等は、、
cpu内部にラムダ計算入れるべき

90 ：

もういいです
自分で理解した
ラムダ計算は最速の演算方法だ

91 ：

言葉先行のどこにでもいるだたのチンピラ？

92 ：

は？

93 ：

Rubyの設計が失敗してるということ。

94 ：

どこが失敗している？>ruby

95 ：

何カ所か盛大にミスってる
nilの扱いと名前空間
けどｊａｖａにくらべたら全然余裕

96 ：

【関連サイト: JavaScript編】 -- Pyhton編: >>4, Ruby編: >>55
・JavaScript 第6版 - O'Reilly Japan
　　http://www.oreilly.co.jp/books/9784873115733/
　　　-- 第5版からの改訂として、節「8.8 関数型プログラミング」が追加された
・Javascriptで学ぶ Functional Programming
　　http://www.slideshare.net/todorokit/javascript-functional-programming-10170360
・JavaScriptで始める関数型プログラミング 1-1 - サイバーエージェント公式クリエイターズブログ
　　http://ameblo.jp/ca-1pixel/entry-11144877522.html
・エレガントな JavaScript を作成するための関数型プログラミングの使用 - IBM dw
　　http://www.ibm.com/developerworks/jp/web/library/wa-javascript.html
・A Modern Introduction to Programming with JavaScript and jQuery - Open Book Project
　　http://www.openbookproject.net/books/mi2pwjs/index.html
・JavaScript as a Functional Language
　　http://www.ajaxprojects.com/ajax/tutorialdetails.php?itemid=557

97 ：

Rｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗカスｗｗｗｗｗｗｗｗｗｗｗｗ

98 ：

>>55にある記事の一つを勝手に翻訳してみた
Rubyによる関数型プログラミング -- Functional programming with Ruby
・http://www.h6.dion.ne.jp/~machan/misc/FPwithRuby.html
・http://www.h6.dion.ne.jp/~machan/misc/FPwithRuby.epub
>>80
>>79のいう「関数型言語と同様の馬鹿げた真似をしてドヤ顔してる」とは、
たとえばこんな記事(および、記事に含まれるコード群)を指しているのだと思われ.....

99 ：

もうrubyの話とか要らん

100read 1read

1read 100read
TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲

【TDD】テスト駆動開発【TestFirst】 (271)
「OS自作入門」 (328)
△△もっとStruts2の良さを教えてくださいSsssion6 (659)
【初心者歓迎】C/C++室 Ver.86【環境依存OK】 (103)
HSPだって (193)
Visual Studio IDE環境 (574)
--log9.info------------------
奈良県内の俺的優良店ランキング (802)
【ﾊﾟﾁ43玉】奈良生駒ミユキ系列part10【ｽﾛ8枚】 (391)
【社員】話題のローズガーデン5連目【禁止】 (142)
【相模原】ヤスダ 相模原店情報 part1 (597)
中原区のパチンコ part9くらい (559)
【ホルコン】ニュー今津屋入谷【ぼったくり】 (212)
【養分】プレイスポットドラゴン川崎17【監視】 (879)
【終わりの】君津〜木更津part13【始まり】 (751)
★★府中市のパチンコ店情報�O★★ (164)
スーパーセブン新中野店　その５　モナミもあるよ (579)
[ｾﾝﾌﾟﾛ]江東区ﾊﾟﾁ情報 part4[など] (388)
【大阪】アロー浪速店がひどすぎる件 (153)
アリーナ岩槻店 (836)
★★★★★ 青森、八戸の店PART２ (928)
仙台パチ屋情報スレ60 (328)
【最悪】トップワン宝塚【店員】 (618)
--log55.com------------------
暇だからみんなでゲームやらないか？　18本場
キリ番ゲッター選手待合室34 [集会所]
こんなスジャータに誰がした 愛なき憎しみのるつぼ 16話/31話
■□ murofusisan □■ [隔離病棟]
beポイントください
ぬるぽしてから１時間以内にｶﾞｯされなければ神 in be 33
ID槍投げ＠Be 72投目
がんばったらモリタポもらえるスレ238