【激突】関数型言語　VS　オブジェクト指向言語

一般的には、オブジェクト指向型言語が優勢でが
一部には関数型言語を崇拝している人もいます

どちらが上なのか、この際はっきりさせましょう

このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

皆さん、試しに首を90度傾けてみて下さい。

今まであったはずの上と下
なんと！
右と左になってしまったではありませんか

これが、21世紀最大の偉大なる発見です。

上へ上へと鎬を削る時代は終わりました。
これからは、自由自在に方向を変えてみようじゃありませんか。

オブジェクト指向型言語の圧勝だろ
関数型とか誰が使ってるんだよ

鎬（しのぎ）

OCaml使え、で終了

いずれにしろ関数型言語とオブジェクト指向言語の特徴を併せ持つC#が最強って事。

じゃあC#とC#戦わせたらどっちが勝つん？

F#とC#

ちゃんと将来のコンピューターでも対応してくれるほうが勝つわ！！

オブジェクト指向言語 ・・・ 実用言語
関数型言語 ・・・ 学習用言語

オブジェクト指向言語・・・ドカタ用
関数型言語・・・馬鹿には無理

あちゃｗ
またドカタってうるさいやつが
来たかｗ

実際関数型のほうが適している場面ってどんなときなの？

>>1
不毛。削除依頼出しとけよ

>>15
ボロ負け確実の関数型言語厨必死だなｗｗｗ

>14
入社試験でバカをふり落とすとき。たとえ入ってから使うのがオブジェクト指向のみであっても。

>>16
はい？オブジェクト指向言語しか使わないけど

>>1
目クソ鼻クソを嗤うの類だな

>>14
一度組んだらその後変更が無いシステムで
絶対にバグを出したくないとき
じゃないかな

>>20
それ、仕様言語とかの方じゃないか？

どっちか選べるなら優劣を比較する意味もあるけどさ
ドカタはOOPしか使えないだろ？関数型言語でまともにコード書けないだろ？
だったら悩む必要ないじゃん

関数型言語信者って、差別主義者が多いようだね
根拠もなく優越感だけ持ってる

Common Lispなら手続き型も関数型も出来るから最強じゃん
CLOSでオブジェクト指向もサポートしてるから最強じゃん
そもそも、CLOS無しでもオブジェクト指向っぽく書けるから最強じゃん

staticおじさんと似たような発想だよなぁ

関数型で人のコード読ませられるのはたまらんな。

それは、バッカスの言うところの「一時に1語」のスタイルに頭が慣れてるから。

関数型に慣れたら副作用を考えなくていいのですごく楽なのに。

物覚えの悪いCPUと、思考力の無いメモリとが一言ずつ喋りあいながらやってる、ってやつだっけ？
メモリスタとかで状況が変わるかもな。

本当にオブジェクト指向言語と言い切れるのはどんな言語？

なんて不毛なんだろう。。

すまないがハゲ以外は帰ってくれないか？

>>27
> 関数型に慣れたら副作用を考えなくていいのですごく楽なのに。

副作用のないアプリはないんだよ。

これを思い出した
http://news.mynavi.jp/news/2012/03/06/060/

ビタミンEの限度を超えた摂取は骨粗鬆症を招く可能性あり -慶応大らが解明

関数型言語とオブジェクト指向言語があわさって最強になってる言語ってないの？

F#とか?

Scalaだろうな。

関数型言語 ＋ オブジェクト指向言語 ＋ コンパイラ言語

これでネイティブコードはいて
どのマシンでも動けば完璧なんだが。

D

foldl _ v [] = v
foldl f v (x:xs) = foldl f (f v x) xs

sum = foldl (+) 0
product = foldl (*) 1
reverse = foldl (\ys x -> x:ys) []
length = foldl (\n _ -> n + 1) 0

再利用出来すぎ
LLだって、オブジェクト指向の機能のみではここまで再利用は出来まい

>>35
プログラム意味論あたりの研究で
関数型とオブジェクト指向は完璧には組み合わせられないって
いう結論が出ているらしい

>>32 「考えなくていい」というレトリックがわかってないね。
参照透明性を壊すような副作用がないから、「考えなくていい」ということ。

>>39
Rubyなら再利用できますけど、何か？

def fold(init, xs, &fn)
　　case xs.length
　　when 0
　　　　init
　　when 1
　　　　fn.call(init, xs[0], &fn)
　　else
　　　　result = fn.call(init, xs[0])
　　　　for x in xs[1..(xs.length - 1)]
　　　　　　result = fn.call(result, x, &fn)
　　　　end
　　　　result
　　end
end

def sum(ary); fold(0, ary) { |s, x| s + x }; end
def product(ary); fold(1, ary) { |p, x| p * x }; end
def reverse(ary); fold([], ary) { |xs, x| xs.unshift(x) }; end
def length(ary); fold(0, ary) { |n, _| n + 1 }; end

>>42
なるほど。Rubyで書き直すとクソコードになるって事ですね。

メソッドfoldの定義が冗長だったので、>>42を訂正する

def fold(init, xs, &fn)
　　if xs.empty?
　　　　init
　　else
　　　　result = fn.call(init, xs[0])
　　　　for x in xs[1..(xs.length - 1)]
　　　　　　result = fn.call(result, x, &fn)
　　　　end
　　　　result
　　end
end

def sum(ary); fold(0, ary) { |s, x| s + x }; end
def product(ary); fold(1, ary) { |p, x| p * x }; end
def reverse(ary); fold([], ary) { |xs, x| xs.unshift(x) }; end
def length(ary); fold(0, ary) { |n, _| n + 1 }; end

>>44のメソッドfoldの定義を更に簡潔にしてみた

def fold(init, xs, &fn); xs.inject(init, &fn); end

def sum(ary); fold(0, ary) { |xs, x| xs + x }; end
def product(ary); fold(1, ary) { |xs, x| xs * x }; end
def reverse(ary); fold([], ary) { |xs, x| xs.unshift(x) }; end
def length(ary); fold(0, ary) { |xs, _| xs + 1 }; end

>>45
簡潔というか、foldの実装をinjectに押し込めただけだよね
foldとinjectは機能的に殆ど同じだから

>>46
そのとおりだね
ただし、>>44,45のコードは、>>39の

>LLだって、オブジェクト指向の機能のみではここまで再利用は出来まい

という「関数(メソッド)の再利用性」に対する具体的な反論になっているんじゃないかな？

引数２個程度のメソッドの再利用で再利用性が高いとか言っちゃうのもどうかね。
オブジェクト指向の再利用で典型的なのはＧＵＩコンポーネントなどで、
複数の入力に対して複雑な出力があるものだから比較になってない。

上位クラスに小さなバグがあっても
継承したクラスで関連するメソッドをオーバーライドして修正できるのも再利用性なんだよな。
バグがあるのが悪いというのは論外で、他人が作った資産だったり、すでにオブジェクトファイルに固めてあったり色々な事情がある。

あとね、いくら簡潔に書けてもドカタに理解できないコードは再利用性が低いと言えるんだ。

ドカタ、ドカタと言っている人何者なの？
建設的な議論を妨げてるような気がするんだけど

ドカタが気に障ったのかな？
じゃあ言い方を変えて猿でもわかるコードならば再利用性があると言える。

ほとんどのオブジェクト指向言語のカプセル化は、猿でも簡単に壊せるよね。
たとえばHaskellのIOモナドみたいな堅牢性はどこにもない。

ああ、単なる馬鹿か

どんな堅牢でも外部プロセスからメモリ書き換えればなんでも壊せる

IOモナドがどう堅牢なのかご高説を賜りたいものです。

関数型言語を全く知らずにスレを立てる程のバカであることが判明しましたw

たとえば Int -> Int 型の関数の中から unsafePerformIO を使わずに、
"Hello World" って出力しようとしてみればわかるけど、
それすら知らない程の超弩級のバカですねw

なんか誰に対して何を言っているのか良くわかんないけど、
Haskell信者が傲慢で独り善がりな事だけはわかった。

> どんな堅牢でも外部プロセスからメモリ書き換えればなんでも壊せる

傲慢で独り善がりってこういう主張のことを言うんですよw

Haskellは神
Haskellerは神の使徒

ML厨やLisp厨は異端
煉獄の火の中に投げ入れられるべき

命令形言語厨は異教徒
豚畜生と変わらない

で、具体的な反論は？

>>47
ブロックは確かにSmalltalkでもオブジェクトとして有るんだけど、一般的なオブジェクト指向言語には無いのがなぁ・・・
結局、再利用性を高めるためには継承・隠蔽・多態性よりも、関数を値として渡すという関数型言語的な処理の方が有用なんじゃなかろうか

実際、C++やJavaで再利用性に欠かせないテンプレート（ジェネリック)は、オブジェクト指向とは無関係で、どちらかと言うと関数型言語の型推論に近い（これも関数型言語とは無関係と言われればそれまでだが）
そう考えると、型推論的なものと、関数を値として扱える機能が、再利用性向上に寄与してるとも言える

オブジェクト指向の多態性に当たるオーバーライド、オーバーロードはテンプレート（ジェネリック)を使ってなるべく利用しない方向に向かってるのが何よりの証拠とは言えないだろうか

そう考えると、型を意識するオブジェクト指向と関数型のそれぞれの言語を持ち出した方が、より生産性に有用な機能がどれかを浮き彫りにしてくれそうな気がする

>オブジェクト指向の多態性に当たるオーバーライド、オーバーロードはテンプレート（ジェネリック)を使ってなるべく利用しない方向に向かってるのが何よりの証拠とは言えないだろうか
全く意味がわからない。
(バカだからわかんねーんだよｗｗっていうのはHaskell信者だけにしてほしい)

いや、ブロックというかクロージャでいいだろうし、メソッドを呼び出せるオブジェクトはクロージャとして
使えるから、そのありなしはほとんどどうでもいいと思う。

>>64 おまえが無知なだけ。

>>66
なんだよ。俺が無知だったらお前は無知以下じゃないか。

>>64
嫌マジ
Haskell信者じゃなくても、馬鹿だから分からねーんだよって言われて良いレベル
Javaに最初ジェネリックが無かったのに、何で入ったか考えてみ？

継承はともかく、今や、多態性はオブジェクト指向の機能は補助的なものに過ぎない
多態性指向と言うか、テンプレートやジェネリックは別のプラットフォームのものと考えるべきものだろう
関数型とも違うプラットフォームとも言える。と言うか、オブジェクト指向も、関数型も、元は型が無い前提だったんじゃないかと思える
実行速度、安全性などの理由で型も意識した結果がテンプレート(ジェネリック)や型推論に落ち着いたと想像してる

型でガチガチにすれば安全になるのはわかっている。これはなんでもそう。
（型なしラムダ計算があったりするように、どちらにも型なしの世界はある）
安全になることはわかってるけど、
・いちいち型を書くと、無駄に冗長
・配列とかリストとかのコレクションとか、ガチガチをあえて緩めるか
　組み合わせの数だけ（整数の配列、浮動小数点のリスト、…）型が必要
という問題があるから、それをエレガントに解決するために使われるのが、
型推論やジェネリック型（や型クラス）。

>オブジェクト指向の多態性に当たるオーバーライド、オーバーロードはテンプレート（ジェネリック)を使ってなるべく利用しない方向に向かってるのが何よりの証拠とは言えないだろうか
相変わらずこれの意味がわからない。
オーバーロードを多態性だってのはわかるけどオーバーライドが多態性かっていうと？だし
テンプレートやジェネリクスでオーバーライド、オーバーロードが制限されることもないし
利用しないようになっているというのもわからないし。
それが何よりの証拠になる理屈もわからない。

型による安全性という概念を知らない、ないしわからない、ということはわかった。

>>71
なんだよ〜C++がテンプレートを取り入れた当初から
バリバリつかってた俺は経験的によーく知っているつもりだけどな。
なんか見下す事しか出来ない奴らだなおまえらって。

>>69
そうそう！
それが俺の言いたかった事！

>>63
>オブジェクト指向の多態性に当たるオーバーライド、
>オーバーロードはテンプレート（ジェネリック)を使ってなるべく利用しない方向に
>向かってるのが何よりの証拠とは言えないだろうか

>>64,70ではないがw、自分も何を言いたいのか分からない
動的型付けなオブジェクト指向言語であるSmalltalk/Rubyでは「(>>63の)都合が悪い」から
話を静的型付けな言語(C++/Java)へ持って行きたい、というのなら分かるのだけれど.....

Lisp/Scheme/Logoのように動的型付けな関数型言語も存在しているわけで、
型付け(動的と静的)と計算モデル(命令型と適用型)をゴッチャにして
理解したつもりになっていまいか？

>>69
>それをエレガントに解決するために使われるのが、
>型推論やジェネリック型（や型クラス）。

C++やJavaのジェネリック型が、エレガントにはとうてい見えない件について.....

すまん俺も少しおかしな事を言っていた、
オブジェクト指向においてオーバーライドは多態性そのものだな。
あの一行を除けば>>63の言いいたい事は解るよ。

>>74
> Lisp/Scheme/Logoのように動的型付けな関数型言語も存在しているわけで、
> 型付け(動的と静的)と計算モデル(命令型と適用型)をゴッチャにして
> 理解したつもりになっていまいか？

計算モデルで分類するならLisp/Scheme/Logoは命令型ですよ

関数型言語の一般的な定義からすればLisp/Scheme/Logoも関数型言語だろ
一般的な定義は「関数がファーストオブジェクトである」

さいしょのオブジェクト？

> 一般的な定義は「関数がファーストオブジェクトである」

ファーストオブジェクトって何？
ファーストクラスオブジェクト、ってことなら、PythonとかJavaScriptとか、
最近の言語がみんな関数型言語になっちゃいますけど。

C言語は関数型言語、に類似のデマに惑わされてる人でしょあなたも。

>>75
C++はジェネリックというよりテンプレだから。Javaと一緒にすんな。

よしこれからは依存型のある言語だけを関数型言語と呼ぼう

LLバトスレからコピペ

　82 名前: デフォルトの名無しさん Mail: sage 投稿日: 2012/03/09(金) 12:07:14.32
　実用期を迎えた関数プログラミング 参加レポート
　ttp://sea.jp/?p=937

　> つまり、関数プログラミングを快適に実践するには、関数を変数に格納できるという程度では不十分だということです。
　> 関数プログラミングを支援する言語機能として、以下のようなものが紹介されました。
　>
　> ・関数を変数に格納でき、さらに無名でも定義できること
　> ・関数内部が静的なスコープを持つこと
　> ・関数の引数の一部だけを変数にバインドした別関数を返す部分適用を簡単に利n用できること
　> ・変数は上書きしない。配列、リストの中身も書き換えない
　>
　> これらの機能は、関数を頻繁に定義し、それをいろいろな場所に渡して使用する以上ないと困るし、
　> 変数が上書きされたり副作用があると関数を組み合わせて使用することが難しくなるのだろう、と私は理解しました。
　>
　> 個々の要素、例えば高階関数や部分適用などのみに注目して他言語、JavaScriptやRubyなどを見ていけば、
　> これらの機能を備えた命令型言語はたくさんあると思います。
　>
　> 実際、関数を使ったプログラミングもできると思うのですが、やはり型や変数の取り扱い、
　> 副作用をどのように扱うか、スコープや値の評価方法など、関数型言語としてデザインされた言語でなければ、
　> 関数プログラマーの方々がおっしゃるレベルの関数プログラミングは実現できないのだろうと感じました。

>>82
高階関数、モジュール指向、ラムダ関数、論理型ってこと？
モジュール指向は当たり前だし論理型は余計な感じもする。

手段と目的が逆になってる。

関数型言語を使うことが目的になってる。

関数型言語の本質 ＝ オブジェクト指向と混ぜた時に
絶対実現不可能なこと。

>>85
絶対って言葉をあんま使わん方がいいぞ。
関数型の典型であるLispのオブジェクト指向
http://www.asahi-net.or.jp/~kc7k-nd/onlispjhtml/objectOrientedLisp.html

>>86
プログラム意味論あたりの研究で
関数型とオブジェクト指向は完璧には組み合わせられないって
いう結論が出ている

>>87
証明は？で君はそれを理解しているの？受け売りはいかんよ。

>>86
最近の関数型言語信者はLispは関数型言語じゃないとか言ってるよ
WEB+DBマガジンに関数型言語についての記事があるけど
Lispを関数型言語から排除していた

関数型言語は処理のリストを簡単に作る事ができる。
[処理,処理,処理,処理]
オブジェクト指向言語はこれを実現できないわけじゃない
Operationクラスを作ってoperationメソッドを作って
Operationを継承するクラスを各処理ごとに作ってoperationメソッドをオーバーライドして
それらをOperationリストに突っ込めばいい。

高階関数もFactoryやリフレクションを駆使してムリクリ作る事はできる。
でも高階関数モドキやラムダ式モドキをわざわざ作らない。あまり必要ないから。

ああ確かに不毛だなこのスレ

関数型っていうのは副作用を許さないから、
どうしても関数型の理論だけで完結することはできない。
だからどの関数型言語も、関数型理論とは外れる機能を搭載している。

世の中に必要とされているシステムってのは絶対に副作用が必要だから、
関数型とそれ以外（たいていはオブジェクト指向）を混ぜた言語が使われる。

昔は、関数型にそれ以外を追加した、関数型ベースの言語が使われていたが
最近はオブジェクト指向に、関数型の機能を追加した、
オブジェクト指向ベースの言語が使われてきている。
また旧来の言語も、関数型の理論を取り入れてきている。

もう、それでいいんじゃね？ 関数型ベースなんてもう流行らないよ。

昔：馬鹿はプログラミングしなかった（だから関数型ベースで問題なかった）
今；馬鹿もプログラミングするようになった

オブジェクト指向は流行らないよ、と必死にわめいていたバカにそっくりだーw

>>89
添削
　X: 最近の関数型言語信者はLispは関数型言語じゃないとか言ってるよ
　O: Haskell信者はLispは関数型言語じゃないとか言ってるよ

>WEB+DBマガジンに関数型言語についての記事があるけどLispを関数型言語から排除していた

それは静的型付けな関数型言語に関する記事だからという理由じゃないのかな
その記事で「Lispは関数型言語じゃない」と書いてあるの？


参考として「やっぱり動的型付け言語は大規模開発で効率が悪い 2」スレ(dat落ち)からコピペ

　366 名前: デフォルトの名無しさん Mail: sage 投稿日: 2011/10/26(水) 12:25:43.06
　>>365
　それはハスケラ特有の症例で、心の病の一つ

　ハスケルという言語を使っていると、世の中のあらゆる事柄すべてが
　ハスケルを中心に廻っているように見えるらしい
　従って、あらゆる関数型言語は静的実行かつ静的型付けでなければならないし、
　遅延評価が常識であり、一切の副作用は認めようとしない

　ハスケラにとって関数型言語とはハスケルのことであり、
　その窓から見える世界が彼らのすべて

こういうスレタイにすべきだったな

Haskell VS その他の関数型言語 VS オブジェクト指向言語
Haskeller VS その他の言語使用者

>>1 がそもそも関数型言語について全くわかってなかったんだからしょうがない

実際HaskellとLispは
SmalltalkとJavaくらい違う

Haskellってなんていうか、
人を誑かすのは上手いよね。

正直、副作用問題を放棄してる関数型言語と、最近のLLの機能的な境目が薄くなって来てる感じはする
RubyもPythonもオブジェクト指向言語と言うより、マルチプラットフォーム言語なんじゃないかと

何というか、ちゃんと切り分けていこうぜ
オブジェクト指向の機能と、関数型言語の機能
それらに依存しない機能

マルチプラットフォームっていうとWindows,Linux,Macで動くように聞こえる。

マルチパラダイムって言いたかったんと違うん？

>>102
補足ありがと・・・・
それが言いたかった

>>39
関数型言語の出す例ってその手の toy ばっか。
reverse や length なんていうデフォで提供されてて当たり前な関数を
わざわざ fold から自作してみせて再利用性(ｷﾘ
アホかと

再利用唱えてドヤ顔するなら GoF の例を関数型言語で書き下して
コード一桁減りましたくらい言えって

現在の関数型言語に足りないモノ、それは大規模開発に対応できる開発方法論が存在しない点
Haskellerご自慢のモナド/アローはプログラミング(コード設計)レベルの手法であり、
オブジェクト指向言語であればSmalltalk-80が世に知られ始めた1990年代に近い状況
現在のオブジェクト指向言語と比較すれば、関数型言語は少なくとも10年以上の遅れがある
関数型言語には、アート(工芸)やテクニック(技法)からエンジニアリング(工学)への脱皮が必要だろう

参考として「関数型言語Part5」からコピペ
　351 名前: 283 Mail: sage 投稿日: 2011/10/01(土) 01:25:14.63
　>>347
　>という別の切り口の提案についてはどう思ってるの？

　まず関数型言語に適したソフトウェア開発方法論というものが、
　あれこれ分類を検討できるほど存在していない、という事柄があります。
　もちろん>>345の教科書を含めて「数学的な活動としての関数型プログラミング」や、
　形式的手法あるいは定理証明といった分野で活発な研究が行われているのは知っています。
　ただし自分が求めているのは、現場に提案/適用できる実用的なソフトウェア設計論です。

　たとえばOOPLであれば1992年に国内出版された「オブジェクト指向方法論OMT」があります。
　当時はOOに対して悲観的な意見者が大半を占めていた時代でしたが、
　この本の登場によって、国内でも一気にOOP/OODに関する注目が高まりました。
　そして1995年の「デザインパターン」による設計手法のカタログ化(分類)によって一気に普及しました。
　これに相当するような具体的な設計論が関数型言語に存在しますか？おそらく現状は No でしょう。
　以上のように考えて、>>315で提案されたようなトップダウンな方法論は(今の自分には)無理だと判断しました。

>>105 の言うエンジニアリングって、要するにM蔵とかいう会社あたりで
あれこれバズワードを振り付けてそれっぽく見せてくれればおk、ってこと？

新技術にあれこれ難癖つけているだけの奴って、結局出遅れて損をして、
後からは損をした損をした、って喚くだけに奴になるよね、たいていw

>>106
なんでちゃんと詳細なこと書いてあるのに読まないの？

たとえば、Observer パターンを関数型言語ならどう実装するかってことだよ。

インターフェイスクラスを継承しないで何かを開発するなど悪夢だろう。

Cでもできるが保守の手間が尋常じゃなくなるからC++にしておくんだ。

※注意 ここは突っ込むところです。はい、どうぞ。

JavaにはgotoがないからJavaは使えない、みたいな議論だな。
オブジェクト指向で必要となるデザインパターンが実現できないから関数型は使えない、と言われても、というか。

>>110
やっぱりそのレスが来ると思ったｗ

デザインパターンというのは、問題があって
その問題をオブジェクト指向で解決する場合のやり方。

解決のやり方がオブジェクト指向というだけで
ここで発生した問題は関数型でも発生する。
Observerパターンでいえば、
何かの状態の変化を監視したいという問題。

それを関数型言語で解決してみろ。

純粋関数型言語で、なのか、なんでもかんでも関数型の関数型言語か、
はたしてどっちのことを言っているのだろう？

とりあえずMonadStateとMonadIOのインスタンスにしときゃあいいんだよ！！

Haskellはバカが得意げになるための道具、まで読んだ

このスレは↑のようなバカが得意げになるためのスレです

Haskell は「けいざいがく」と同じにおいがする

現実から目をそらし、夢の世界の幸福に浸る

>>111
関数型言語ではFRPで解決します。

やさしいFunctional reactive programming（概要編） - maoeのブログ
http://d.hatena.ne.jp/maoe/20100109/1263059731

うむ、リアクティブぷるぐらみんぐは気になる。
でもそのためにわざわざ関数型に切り替えるとなると、う〜む

オブしこのほうが自然だよね。

リアクティブとかこの世の地獄が生まれそうな機能だなおい。

逐次処理否定してなんかいいことあんのかよ。プッシュプルみたいなもんなのか？

否定してないからIOモナドがあるんだろうが。

>>120
GCで不要メモリブロック回収を自動化すると回収漏れが減るように、
FRPで同期処理を自動化すると同期漏れが減ります。
GCに対して「この世の地獄が生まれそう」とは言わないですよね？

C#のプロパティで変数との違いを説明するのに使われてるやり方だな。

>>104
>再利用唱えてドヤ顔するなら GoF の例を関数型言語で書き下して
>コード一桁減りましたくらい言えって
>>111
>関数型言語ではFRPで解決します。
>やさしいFunctional reactive programming（概要編）
これらもう全部解決してるよ。

>>122
GUIアプリやWebアプリの設計は非同期に発生するイベントを処理する必要があるため、
イベント駆動方式と呼ばれるコールバック手法が一般に用いられる
ただし、この手法は処理が「ブツ切り」になるから同期漏れが発生しやすいという問題があった
で、これを解決するのがFRPであると言いたいんだと思うけど、それでいいかな？

FRPが何かはよく知らないけど、この「ブツ切り」問題は継続やスレッドを用いることで解決できる
たとえばRubyならば、継続を実現するメソッド callcc があるし、
ノンプリエンティブな軽量スレッド(コルーチン)を実現するクラス Fiber もRuby1.9で追加された

・[ruby-list:34943] Thread by callcc - callcc で Thread みたいなものを作る話
　http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-list/34943

・RubyのFiberを使ってマイクロスレッドでタスクを管理する - Jewel-mmo開発日記
　http://dgames.jp/dan/permalink/20110108
　　==> ゲームプログラミングを題材にして、Fiberを使った同期処理の自動化を解説

別にFRPなんて難解なモノを持ち出さずとも、非関数型言語(なRuby)でも実現できますけど、何か？

Smalltalkだと、SeaSideという継続を使うWebフレームワークが有名だね
これを使えば、Webアプリのブツ切り問題は解決できる
詳しくは "SeaSide 継続" でググってくれ
たとえば、総括的な解説とJavaでの適用法に関してなら、以下がお薦め

・境界を越える: 継続とWeb開発、そしてJavaプログラミング - IBM dw
　http://www.ibm.com/developerworks/jp/java/library/j-cb03216/

Haskellerって何で生きてるの？

継続って要するに「ふっかつのじゅもん」だったのか

そうだよんw
手続き型言語のGOTO文と似ているし、それよりも(使い方を誤れば)凶悪だ
もしC言語のsetjmp/longjmpを知っていれば、直感的に分かるかもしれない

流石に継続に比べたらFRPのほうが扱い易いわ

物事のある側面を取り出してエレガントな解決を提示するのは簡単だが
物事の全体をバランスよく解決することは難しい

>>122
GCが動いてるアプリはいまいち不安定だよ。

富豪プログラミングができる環境に対応したお手軽言語ってことでいいんかね。

出た、FUDの定番「いまいち不安定」

やっぱり市販のコンパイラは信用できないよな！無料なんてもっての他だ！
x86も命令セットが酷過ぎる。あんなものの上で動かすから、いまいち不安定なんだ。

CPUなどという単純なことしかできないハードの上で動かすなんてありえない

それぞれの言語に適した方法で書けよ。これが一番解決する方法だよ。
発想の違いに柔軟になれない奴が、別の言語に手を出した所で、
使いこなせるわけがないし、馬鹿げたプログラムを書くだけになるさ。

>>131
どの発言に対して何を言いたいのかいまいち分からん。
もっとはっきり言ってくれんか？いいこと言ってそうだから。

>>137
FRPに対する皮肉でしょ
確かに特定の領域を解決するにはエレガントな方法だが、
だからといって問題の全体を解決できるわけではないという

>>133
開放されるであろうという不確かな前提をもとに動作するプログラムを作りたいのかと。

GCがない言語のほうが作るの楽だろうに。

このひとこわい

>>139 ガベージコレクションのアルゴリズムを「不確か」というなら、
この世のアルゴリズムは全て不確かだな。コンピュータ使うのやめたら？

メモリが解放されているか否かを事前条件として使用するプログラムならGCがない方が作るのは楽だね
そうでないプログラムならGCがある方が作るのは楽だね

>>139
メモリを動的に確保することが可能な言語なら
GCとほぼ同じものが搭載されてるから、GCが無くても簡単にならないよ。

例えばC言語やC++。これらの言語で、newやmallocで数十バイトの
小さいメモリを確保した時、OSに要求していると思う？

答え。してない。

そんな小さなメモリの確保でいちいちAPI呼んでたら
パフォーマンスが落ちる。

じゃあどうしているかといえば、言語はそれなりの大きさのメモリを確保して
newやmallocに小分けに与えてる。そしてある一定のサイズ解放されたら
まとめてOSに返してる。
GCはこの作業を別スレッドでやってるだけ。

>>143
> 答え。してない。

しますん。

管理をしているコードをOSを呼ぶかどうかってだけの話はどうでもいいんだ。

全コードを意図したとおりに動作させられる方が安定するっつー話なんだよ。

個人的にはerlangの方が断然安定って雰囲気だが
何が安定すると言いたいんだろう？

心・・・かな

>>145 今時キャッシュも仮想記憶もないコンピュータを使ってるのか。ご苦労なことだ。

erlang って個々のタスクとスケジューラを
同じ言語でシームレスに書けるんだよな？

書けないと困るのか？
だったらOSもアウトだろうな
ご苦労さま

メモリ確保ごときになんであんなに時間がかかるのかと思ったらＯＳのせいだったのか。

スレ止まった？

１から３までの数字の重複の無い組み合わせは以下のとおり

[[1,2,3],[1,3,2],[2,1,3],[2,3,1],[3,1,2],[3,2,1]]


これをオブジェクト指向式と関数型言語式でコード比較してみようず

出来れば、これの１から４までとか、５までとかバージョンもお願い

なんかリスト内包ある言語の勝ちに持ってきたいという意図が透けてみえて嫌ぽ

まあ、実際に内包表記は便利なんだけどさ
それは関数型言語特有の機能かと言うと違う訳で、最近の言語なら内包表記か、似た機能サポートしてるっしょ
(pythonも内包表記サポートしてるし、C#も似た機能有ったの見かけた)

ここからは Haskell vs.Python の対決が始まる訳ですね、wktk(棒

包茎表記

何でこういうちょっと難しい（？）問題だと、とたんにコードが出なくなるのｗ
多分、コード自体はどっちも大して変わらんはずなのに

n=3
(1..n).to_a.permutation(n){|a|p a}

>>148
おまえのCPUはハードウェアでガベコレしてんのか。

ガベコレはしったら、メモリ以外のリソースまで
掃除されると思ってる先輩がいるんだが
どうしたらいい？

>>158
待て待てw
組込みメソッド使ったら意味無いだろ

それを言ったら、Haskellも

import Data.List

parmutations [1..3]

で良いわい

お題。

JavaScriptでは、nullとundefinedがありますが
これと同じ物を関数型言語で実装してください。

>>161
OOPLで書くっつーても、それが単に数値でしかない以上
単なる手続き型のコードが最適解になるからなあ
限りなくOOP的なアプローチを取ると冗長だろうし

ようするに、ユーザー視線での問題を
出せばいいんだよ。

たとえば、ドラッグアンドドロップを実装するとかさ。

>>161
組み込みメソッドはプリミティブとして定義されているのだから、
使ってもいいんじゃね？
そのHaskellの例だと、import Data.List はプリミティブではないから、
明らかに反則だけどね

どこで線を引くかで、このスレでローカルルールが必要になると思うけど

>>165
そんなことを言ったら、PHP最強ってことになるぞｗ

関数型言語で、ウェブサイトから
データを取ってきて表示してください。

<?php echo file_get_contents('http://www.example.com/');

完了ｗ

>>163
手続き型のコードでもいいんじゃね？それが最適解であるのなら....
実際にアンチ関数型スレでは、素数生成についてジェネレータを使った
PythonとSmalltalkのコードが示されていたけど、誰からも文句は出なかったし

>>166
アンカを間違えていまいか？

そういったライブラリ利用があるから使っていいのはプリミティブまでにしようぜ、
というのが>>165の主旨なんだけど

>>168
Cだと文字の表示すら出来んがな

そのとおりだね
それどころかHaskellだって、もしリストの畳み込み処理が必要になったら、
組み込み関数のfoldlは使えず、いちいち
　foldl _ v [] = v
　foldl f v (x:xs) = foldl f (f v x) xs
と書かなければ反則扱いされてしまう(>>39)

だから、プリミティブまでは使ってもいいんじゃね？というのが>>165の主旨
また、ライブラリの利用は禁止とまでは言わないが、減点の対象になるだろうね(>>161)

Rubyなんかはどーでもいいんだけど、
Haskell vs. Python の仁義無き闘いはマダー？ チン、チン

>>167
んじゃ俺は再帰で…

def perm(ns)
  return [] if ns.empty?
  return [ns] if ns.size == 1
  ns.inject([]){|r,n| r + perm(ns.reject{|x| x == n }).map{|xs| [n] + xs }}
end
n = 3
p perm((1..n).to_a)

むしろ、一切の組込み関数使わないで、入出力以外の関数作れるのがHaskellやCの強みで、プログラミング学習には最適なんだがな・・・
（と言うか、自分が知らんだけで、ruby/pythonでも組み込み機能を再現できるんじゃないの？）



ライブラリ使ったら、誰かの言葉じゃないが、言語間の違いなんぞ簡単に埋められるさね

>>173
Rubyの場合「組み込みクラスを使わない」となると配列はおろか数値や真偽値すら存在しないことになっちゃうし
演算子も大半のものがメソッド扱いなんで、言語としてほとんど成り立たなくなる

逆に大量の機能が言語本体に組み込まれてるから
上に書かれたようなのは全くrequireを行なわなくても実行できちゃう

なので「ライブラリ使用禁止」が「組み込みも禁止」だと無茶だし
「組み込みOK、require禁止」だとpermutation一発じゃん、となるワケで線引きが難しいと思う

Haskell
ここのpermutationsの使用例で動作確認した
http://rubyist.g.hatena.ne.jp/edvakf/20090416/1239829830

checkPermu xs = and.concat $ check xs
where
check [] = []
check (x:xs) = map (x/=) xs : check xs

permutations 0 _ = [[]]
permutations _ [] = [[]]
permutations n ns = [x:xs | x <- ns, xs <- permutations (n-1) ns, checkPermu (x:xs)]

意図せず、>>161のライブラリVerより自由度が上がった（ruby版の使用例のお陰？）


>>170

ネイティブ関数に関しては、言語によってネイティブ関数を少なめにするポリシーがあったりするからな・・・
（主に言語仕様の軽量化。ライブラリとして追い出して、言語仕様をスリムにするため。Cとrubyはそれぞれ、その極端な例）

たしか、JavaやPythonもどっちかと言うとライブラリに追い出す主義のはず

>>174
それはrubyが異質なだけ
上でも書いたが、rubyは何でもデフォルトに詰め込みすぎなのよ
どっかで読んだが、JavaやPythonは小クラス主義で、rubyは大クラス主義なんだと

小さなクラスの組み合わせでプログラム作るか、大きなクラスに何でもさせるか

この変はパフォーマンスとの兼ね合いや、自由度とかの兼ね合いになるんだろうけど

逆に、ライブラリを使っていい前提で
開発効率を比べてみないか？

まあ、さすがに非公開ライブラリとかじゃダメだが。

checkPermuを無くすと、内包表記の条件式を書いてないのと同じ動作になるので、checkPermuを追い出して、さらに自由度をあげてみた


allPattern 0 _ = [[]]
allPattern _ [] = [[]]
allPattern n ns = [x:xs | x <- ns, xs <- allPattern (n-1) ns]

permutations n xs = filter checkPermu $ allPattern n xs



各要素(リスト)から先頭要素が偶数のもののみ抽出

filter (\x -> (even.head) x) $ allPattern 3 [1..3]

各要素のリストが昇順になっているもののみ抽出

filter (\(x:y:z:[]) -> x <= y && y <= z) $ allPattern 3 [1..3]

ライブラリの使用が前提で比較するなら
それなりの規模の内容である必要があるな

そうだな。Rail On Railsの15分で作るブログ
あの程度でいいから関数型言語で作ってみてよ。

Ruby信者を装ったRubyアンチ厨の新たな荒らしネタだと判明しましたw

それなりの規模と言われてRoRを思い浮かべる
Webドカタ思考は非常にRuby信者らしいじゃん
どうしてRubyアンチ厨だと思ったん？

>>180
自分は、Web系全く触ったこと無いんでパスするが、この辺見ながら、RoRと使い比べてみては？
http://yannesposito.com/Scratch/en/blog/Yesod-tutorial-for-newbies/

それなりの規模って言って
本当に実務レベルのもの要求したって
書けないだろｗ

だから15分程度でできる課題を用意したのに、
それすらできないのか？

>>182
Rails信者はRuby信者だけど
Ruby信者にはRailsアンチもいる事に注意

Ruby on Railsの「15分」の真実を知らずに偉そうな奴もいたもんだw

あれはRoRがまだマイナーだった頃、IRCのしかるべきチャンネルに入れば
DHHとかが直接指導してくれた、だなんていう時代の話。

関数型言語で、それなりの規模といったら
それなりの”関数”でしかない件。

関数型言語だけではアプリは作れない。
それが関数である宿命。

>>184
英語読みながらだと確実に15分以上かかるじゃないか
おまけに私は全くWebに興味が無い

と言うか、>>175,>>178書いててなんだけど、Haskell入門書もまだ読み終わってない入門中の身なんよ
(正直、>>158見るまで、>>161のライブラリ関数の存在自体知らなかったw）

それなのに、Rubyのコードが>>172のみってのは・・・

今回見たかったのは、プログラミングする際の思考の流れが見たかったんだ
自分の場合は、内包表記で１から３までの重複なしの組み合わせを素直に書くと、こうなる

xs = [1..3]
[[x,y,z] | x <- xs, y <- xs, z <- xs, x /= y, x /= z, y /= z]

んで、１から４の場合はこうなる

xs = [1..4]
[[w,x,y,z] | w <- xs, x <- xs, y <- xs, z <- xs, w /= x, w /= y, w /= z, x /= y, x /=z, y /= z]

ここで、w /= ..., x /= ..., y /= ...に注目する

w /= x, w /= y, w /= z
x /= y, x /= z
y /= z

と、x /= ...と、y /=...については、１から３と共通な事が分かる
１から５や、１から２についても、同様な法則性があるだろう

そう言う思考の流れでcheckPermuは組んでみた
なので、出来れば、>>172書いた人はどういう思考の流れで組んだのかお聞きしたい

おまえらpermutationはsortの逆関数だと気付くまでに何分かかった？

> 今回見たかったのは、プログラミングする際の思考の流れが見たかったんだ

一般のプログラミングで１から３までの重複なしの
組み合わせを書くことなんてまずないよ。

そんな考えることが殆ど無いこと、
思考の流れなんて言われても思考しません。

あえて言うのなら、「重複なしの組み合わせ」を返すメソッドを書いて
それを呼び出すだけだな。ぱっとコードを見て説明（名前）が必要なら関数にする。
xs = get重複なしの組み合わせ（1,3);
すごくわかりやすいよね。

あんた、実戦経験ないんじゃない？
プログラミングのための勉強ばっかしてて
動くアプリを作ったことないでしょ。

>>189
お前のレス見たので5秒ｗ

最近、言語仕様でサポートされてるのも
ライブラリでサポートされるのも、
違いを感じないな。

とある言語なら、こうやって書ける！と言われても、
たしかにこの言語でそれ書くの大変だけど、
とある言語では、そうやって書ける構文を言語開発者が
作ってくれてるだけだよね。

作ってくれてるから楽だ。という話なら
それがライブラリでも、作ってくれてれば楽だよね。

言語仕様も、ライブラリも大差ないんじゃない？
この考え、否定出来ないな。

>>190
日本のIT業界が世界に勝てない理由が分かった気がする・・・

>>193
うん。開発力の差だよ。
やつらは、まずとりあえず動くものを作る。
そしてあとで直す。こういうやり方。

railsとかもそうだよね。
まず、動くものが出来るスピードが大事。
興味がないと言ってる場合じゃないよ。

>>194
それもあるが、考える力が全般的に負けてるんじゃないか？
(自分も人の事言えないが、壁にぶち当たったときの突破力みたいなのがRubyじゃ身につかなさそうな意見だ)

素人のコードに付き合う余裕も無いとは・・・
実践じゃ、ありもののコード使えばいいけど、頭の体操も実践風にするのはどうなの

仕事ではもっと面倒な事を考えてるから問題ないよ。

既存ライブラリの成熟、過去との互換性、新技術見極め、開発者集め、
どちらも自分が頑張っただけじゃ解決しない
もっと面倒な問題だ。

GithubがあっさりクラックされたRailsがどうしたって？

関数型言語でクラックされたって話は聞かないな。

使われてないからか。

Rubyは静的型チェックが無いんだから
Haskellと同じ長さ/時間でプログラムを書けたとしても
同等じゃないんだよ

全ての変数にkind_of?でチェックを入れても、
所詮は実行時チェックにすぎないから
まだ同等じゃない

> Haskellと同じ長さ/時間でプログラムを書けたとしても
> 同等じゃないんだよ
いや、速く作れる。

>>199
これって、割と有名なサービスだと思うけど・・・
http://tanakh.jp/pub/unisys-tech-2011-11-09.html#7

>>202
daemontoolsの再実装のことですか？
仮想ドライブじゃない方の
daemontoolsですよね？

>>202
それは、（ウェブ）サービスではなく
UNIXのサービス管理ツールだ。マヌケめ。

命題論理実装してみようず

data Expr a =
    TRUE
  | FALSE
  | And (Expr a) (Expr a)
  | Or (Expr a) (Expr a)
  | Not (Expr a)
  | Base a

eval :: (t -> Bool) -> Expr t -> Bool
eval evalBase expr =
  case expr of
       TRUE -> True
       FALSE -> False
       Base base -> evalBase base
       And x y -> eval' x && eval' y
       Or x y -> eval' x || eval' y
       Not x -> not $ eval' x
  where eval' = eval evalBase

つまらん。
なんでいつも関数レベルの話しかせんのだ？

設計レベルの話しろよ。
デザインパターンを関数型言語で実装するとか

数学屋はヒントを隠して問題を出す。
宣言を明示するパラダイムとは全く逆のことをしている。

俺は拡張性を重視しながら開発をしているわけだが、

拡張性のある関数。
なぜこの言葉に違和感があるのだろうか？

>>188
俺は手続き的に、最初に自分が手でその作業をやる場合の手順を考えた
1〜nのカードを用意して、手から順番に机の左から置いてくイメージ
そのイメージをする中で、1枚置いたら、その残りで同じことを繰り返す…つまり再帰であると気付いたって感じ

１．普通に考えたら手続きで書く。
２．関数型って言えば再帰だよねｗｗｗ
３．やってみた。

こんな感じ。

>>208
コンビネータを知らないから

>>211
うん。それで？

馬鹿には拡張は無理

>>206
GoFに実装する価値のあるもん在ったっけ？

>214
デザパタを勘違いしてないか？

最初に何かしたいというお題があって
それをオブジェクト指向で実装したのが
デザインパターンね。

最初の何かしたいというお題は
別にオブジェクト指向に限ったものじゃないよ。

デザインパターンがそんなにすごいのなら
どうして抽象化して再利用できるようにしないのか？
それはつまりデザパタが行える抽象化は
関数プログラミングでは取るに足らないばかりなので
一瞥の価値もないからだ。
と密かに思ってるんだけどどうだろう

>>216
デザインパターンは抽象化して
再利用できるようにしたものだよ。

だから、あんたの結論は逆

Javaの場合、言語がカチコチなせいで、具体的汎用的なコードとしては
実装できず、「パターン」とするしかないものもある。Smalltalkでは確か
そういうパターンのいくつかは具体的に実装できるとかいう話があったはず。

デザインパターンは言語は関係ないよ。
実装が違っても、パターンと呼ばれる概念は存在する。

実装が改善される必要はないんだよな
コードは何も変わらなくても、概念が有名になれば説明しやすくなって可読性は向上する

なんか抽象化という言葉の意味が違う
パターンを抽象化したのなら元の記述より短くならないと
書き写すのは抽象化とは言わないでしょ
でも何となくわかったよ
javaでは抽象化はできないんだね
だからパターンってもので凌ぐわけだよ
でやっぱり関数型で行える抽象化からすると
デザパタはおもちゃにしか見えないというか
だからパターンってもので凌ぐわけだよ
でやっぱりデザパタは関数型で行われる抽象化からすると

ごめん最後の二行は忘れて

末尾再帰？

そりゃデザパタはパターンランゲージに端を発するもので、
元々は建築家がいかに住人参加型の街づくりが出来るかを考えたものだからな。
数学的な抽象化とはまるで意味合いが違う。
違うものを同列に語るのは間違っているし、優劣を付けるのも同様。

「まるで」とは言い過ぎた。当然、絡む部分もある。

>>221
オブジェクトは書き写すとは言わないでしょ
書き写すのはstringだが、stringは関係ないな

class nullObject;
class undefinedObject;

全部共通のポインタにいれたいなら、shared_ptr<void>で解決

>>205はCompositeパターンもStrategyパターンも
Interpreterパターンも使ってる

建築と数学だから関係ない、とか言ってる奴は、『親族の基本構造』を知らないとみえる

他人のソース読んでいるとゴミみたいに冗長なんだよな。
書き方が下手だとかそういう瑣末な話ではなく論理的な無駄が多い。
エレガントさに目覚めたHaskell厨には頑張って欲しい。
しかしこういう論理的にガチガチなのは平均的なプログラマーには受け入れられないだろうな。

Haskell使うには副作用ありきの考え方から抜けないといけないのが辛い。
参照やポインタありきなデータ構造をピュアにすんのが辛い。
何かこの構造はこう書けるとか、代わりにこれ使えとかいう指針はないの

親族の基本構造って、パターンを勉強したら親族が繁栄しましたって話じゃなくて
何も勉強しなくても自然にエレガントな構造になってたって話だろ

>>231 Purely Functional Data Structures の翻訳が待たれる

>>231
再帰とか高階関数とか、dataで独自データ型作るとかで大体対応出来る

宣言型を拡張していくのは限界がある

プロの棋士じゃないんだから
「たった一手悪手を指しただけで敗北」
みたいなのはいらない

それ命令型or手続き型の悪口にしか思えないのだが

>>233
博士論文版（PDF）の方はSMLコードしか載っていませんが、
本の方はHaskellコードが巻末に載っているそうです。
英語が苦手でもHaskellが得意なら活用できるかもしれません。
PFDS読書会が進行中なので議事録が参考になると思います。

Purely Functional Data Structures
http://www.cs.cmu.edu/~rwh/theses/okasaki.pdf
Purely Functional Data Structures
http://www.amazon.co.jp/dp/0521663504

Purely Functional Data Structures読書会議事録
http://wiki.haskell.jp/Workshop/ReadPFDS/
20分でわかる Purely Functional Data Structures
http://www.kmonos.net/pub/Presen/PFDS.pdf

>>143
mallocに関して他の板でも同じ事をいってたヤツがいたな。
どっから出たガセねたなんだろ。

glib使ってるgccは、mallocつかうと毎回mmap呼ぶし、
Windows上のgccとcl.exeは、Platform SDKにある同じ
malloc関数を使う。そのmalloc関数のコールスタックを追うと
毎回HeapAllocを内部で呼んでる。

なんでそういう仕組みになってるか多少考えればすぐ解るはずなんだけどな。
OSのメモリ関数は、呼ばれても実際にはメモリーを割り当てない。
仮に複数のアプリが同時に2GBの領域を要求しても実際にメモリーを
割り当てないことでスライシングに陥るという最悪の事態を緩和してる。

個々のソフトでメモリー管理なんかしてたらシステム全体として遅くなんだよね。

>>238
メモリアロケータとか
newの実装を勉強してから
またおいで。

>>239
newも毎回呼び出してる。
アロケーターとはそもそも書いてなかったろ。
余談がアロケーターはちっさいオブジェクト作るときやたらと重いし
学が無いなら黙っとけよ

呼び出している呼び出していると主張しているが、

呼び出してませんよ。

>>241
ソース。

operator newの場合msvcr80.def, msvcr90.def, msvcr100.defの
いずれかに定義しているoperator new呼んでて、そんなかで毎回
HeapAlloc呼んでたわ

allocatorは、gccやclのヘッダーをずっと追っかけてくと
こういうのがあって、結局newしてるだけ。
例えばgccはnew_allocator.hってのに定義してある。

pointer
allocate(size_type __n, const void* = 0)
{
　if (__builtin_expect(__n > this->max_size(), false))
　　 std::__throw_bad_alloc();

 　return static_cast<_Tp*>(::operator new(__n * sizeof(_Tp)));
 }

>>189
>おまえらpermutationはsortの逆関数だと気付くまでに何分かかった？
30分たったがまだ分からん。

>>239
>>241

さー苦しくなって参りました
そーすっ!　そーすぅ! 早よ出せ そーす!

>>241
実装の一つでも挙げてみろよw

>>216
デザパタは抽象化なんかじゃない。
しかし（だから）取るに足らないものであるのはその通りだ。
まだ分からん奴が多いらしい。

>>238
glibcじゃなくてglib?

>>249
cがあろうが無かろうがそんな揚げ足どうでもいいだろ
mingw-w64-crtとソレが呼び出してるライブラリだ

>>250
なんだWindowsべったりの話か。どうでもいいや

>>251
だからWindows以外でいいから実装一つでも出してみろよ
linuxだと毎回確実にmmap呼び出してるぞ
俺のPC Linuxだし

>>251
存在しねぇんだろ素直に認めろよ

% cat malloctest.c
#include <stdlib.h>
int main(void) {
int i;
for (i = 0; i < 100; i++) malloc(1);
return 0;
}
% gcc malloctest.c
% strace ./a.out 2>&1 | grep mmap | wc -l
8

[admin@service test]$ cat memory.cpp
#include<cstdlib>
#include<cstdio>

int main()
{
char *array = static_cast<char*>( malloc( 10 ) );

for( int i = 0; i < 10; ++i )array[i] = 'a';
array[10] = 0;
puts( array );
free( array );
return 0;
}
[admin@service test]$ strace ./a.out
execve("./a.out", ["./a.out"], [/* 58 vars */]) = 0
brk(0) = 0x1985000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fef2ddbc000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=219526, ...}) = 0
mmap(NULL, 219526, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fef2dd86000
close(3) = 0
open("/usr/lib64/libstdc++.so.6", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360cEH>\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=989840, ...}) = 0
mmap(0x3e48400000, 3166648, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x3e48400000
mprotect(0x3e484e8000, 2097152, PROT_NONE) = 0
mmap(0x3e486e8000, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xe8000) = 0x3e486e8000
mmap(0x3e486f1000, 82360, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x3e486f1000

putsの中でmmapが使われてると言われると癪なんで標準出力を除去。

[admin@service test]$ cat memory.cpp
#include<cstdlib>
int main()
{
char *array = static_cast<char*>( malloc( 10 ) );
int result = 0;
for( int i = 0; i < 10; ++i ) array[i] = i;
for( int i = 0; i < 10; ++i ) result += array[i];
free( array );
return result;
}
[admin@service test]$ strace ./a.out
execve("./a.out", ["./a.out"], [/* 58 vars */]) = 0
brk(0) = 0x20e7000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fc6fc8e2000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=219526, ...}) = 0
mmap(NULL, 219526, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fc6fc8ac000
close(3) = 0

mallocの度に毎回システムコール呼ぶとかどんな糞実装だよ
まともなライブラリ実装ならあるわけないだろｗ

御託はいいからソース出せ

>>254で結論出てるじゃん。毎回呼び出しなんぞしてないし>>238は偽

>>259
実際やると100回越えるが？
自分の実機でやってみろよ

そもそも1回のメモリ確保で1回mmapする理由じゃないからな。
1回の呼び出しで16回mmapしたりするし。

>>260
実際やったのを貼ってみて

いくらでも偽装できるんだからお前自身が試さん限り
嘘か本当かわからんだろ

% strace ./a.out 2>&1 | grep mmap | wc -l
148

>>254を10000ループ。>>260いいかげん諦めたら？
hoge@huga:~$ strace ./malloctest
execve("./malloctest", ["./malloctest"], [/* 16 vars */]) = 0
brk(0) = 0x10011000
uname({sys="Linux", node="foo", ...}) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x3001f000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=28153, ...}) = 0
mmap(NULL, 28153, PROT_READ, MAP_PRIVATE, 3, 0) = 0x30020000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\24\0\0\0\1\0\1\351\240\0\0\0004\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1458348, ...}) = 0
mmap(0xfe7a000, 1528408, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xfe7a000
mprotect(0xffd8000, 65536, PROT_NONE) = 0
mmap(0xffe8000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x15e000) = 0xffe8000
mmap(0xffed000, 8792, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xffed000
close(3) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x30027000
mprotect(0xffe8000, 4096, PROT_READ) = 0
munmap(0x30020000, 28153) = 0
brk(0) = 0x10011000
brk(0x10032000) = 0x10032000
brk(0x10053000) = 0x10053000
exit_group(0) = ?

>>264
実際それ以上出るよなどうせ行数オーバーで貼れんだろうけど

>>263
あなたが試して*その結果が出たのなら*それ以上追求しないよ

ライブラリがちがうんかもな

踏ん切りつかなくなってるんだなぁ…

関数型言語スレからパクってきた。
関数型言語って、チャーチ数見たいに
関数自体をデータとして扱えるってのは必須要件なのかね？

template<class> struct F;
template<class> struct Count;
template<class type> struct Count< F<type> >
{
      enum{ value = Count< type >::value + 1 };
}

template<> struct Count< void >
{
      enum{ value =  0 };
};

Count< F< F< F< F<void> > > >::value == 4;

OSが違えば中身も違う。どっちもあるってわかってよかったじゃねーかｗ

いやはやｗ

newの中でmmapしてる？ そりゃしてるだろうなｗ
ただ、それが毎回じゃないってこと。

>>269
必須じゃないと高階関数書けない

Prelude> map head ["Hyper","eternal","love","less","only"]
"Hello"
Prelude> fun [sum,product,length] [1..5]
[15,120,5]


fun [] _ = []
fun _ [] = []
fun (x:xs) ns = x ns : fun xs ns

>>269
式自体を値として扱えるためには、実行時に式を解釈するのが必須要件。
数学の世界はコンパイラがない。

コンパイラを内蔵すれば、
実行時に式を解釈できるよ。

Windowsｔｔｗ最終的に呼ばれるのVirtualAllocとちがうん？

そらそうよ。
システムコールであるmmapと違って、WinのHeapAllocはmallocから毎回呼んでいても
不思議じゃないよ。実際どうかはしらんけどな

職業的なプログラミングでは、論理的な中核部分は考える時間が大半で
どの言語を使おうが書く時間はボトルネックにならない
言語の選択によって重大な差が生まれるのは
ファイル入出力だったりデータベースアクセスだったりWeb連携だったり
ネットワーク通信だったり。論理とはかけ離れたゴミのような部分
プログラマはそのことを知っているので、言語を選ぶときにそんなところは見ない。
「枝葉末節」をどれだけ簡単に書けるかという視点でサポートライブラリの豊富さを見る。
そっちの篩で先に「使えない言語」が落とされて、
残った言語の中ではじめて「スマートさ」が比較される。
言語屋と現場ではフィルタの順序が逆なんだ。

>>277
プログラムという世界においてロジックを考える時間はゴミのように少ない。
デバッグなどの己の脳の欠陥探しが大半だったりする。
いや実生活においてもそうだ。
論理なんてのはカオス世界の事象のうちのごく一部しか占めていない。

世界が論理的ならもっと建設的に人類は発展するだろう。
世界は論理的協調ではなく合理的な競争や敵対によって足を引っ張りあっており
総和としての発展はカメより遅い。

ニュータイプは、協調性も論理性もない相手の内情を推論できるだろう

ドカタはサポートライブラリの豊富さで言語を選ぶ
まったくその通り
まあ俺には関係ないけど

ドカタって所にコンプレックスを感じるなｗ
俺は土方と違うんだ！みたいな感じか？ｗ
お前こそが土方だよ。

職業に貴賤無しだよな
プププwww

そうそう。ドカタなんて呼び方は止めてあげなよ。
派遣・受注奴隷でいいじゃないか。

どうやら、仕事をする＝土方みたいだ。
つーことは、素人がコンプレックス持ってるってことだな。
なんでソフトウェア開発を仕事に出来なかったの？力不足？

派遣・受注奴隷さんチーすっ。
隷属根性が染み付きすぎて自社開発って選択肢は脳内に無いんだね

どうやら図星だったかｗ

自社開発だから土方ではありません！

さすがｗｗｗ

派遣受注なんてやってるのは、
製品開発できるよな頭が無いからだしな
与えられた環境、与えられた道具しか使えない
いろいろとお察しくださいだろ

ん？ だれが派遣受注なんて言った？
いつも思い込みで自分の理想の仮想的作って戦ってるな。

まさに、一体何と戦っているんだ？

おまいらもうちょっとお利口さんに見えるお話をお願いします

じゃ派遣・受注奴隷なんて言葉に反応する必要ないよな
無関係なんだろ？

派遣・受注という言葉に反応してるのはお前じゃね？
このスレじゃなくて、ずっと気にして頭から離れない用語だから
また書き込んじゃったんだろ？

だから職業に貴賤無しっつーとろーが
年収400万とかの薄給で頑張ってる人達を馬鹿にすんなwww

派遣とか受注してる人はコンプレックスもってんの？

お前らにとっては、派遣や受注なんて他人事なんだからスルーしとけばいいのにね

>>290
俺が言ったんだが。ドカタじゃなく派遣・受注奴隷と。

就職厨うぜーｗ

なんでそんなに目の敵にしてるんだろうなって感じだ。
親でも殺されたか？

僕は将来学者さんになって一億稼ぐ。土方にはならない。

　 ,j;;;;;j,. ---一､ ｀ 　―--‐､_ l;;;;;;
　｛;;;;;;ゝ T辷iﾌ i 　 　f'辷jァ　 !i;;;;;
　 ヾ;;;ﾊ　　　　ﾉ　　　　　　　.::!lﾘ;;rﾞ
　　 `Z;i　　　〈.,_..,.　　　　　　ﾉ;;;;;;;;>
　 　,;ぇﾊ、　､_,.ｰ-､_',. 　 　,ｆﾞ: Y;;f.
　　 ~''戈ヽ 　 ｀二´ 　　 r'´:::.　`!

少なくとも派遣・受注奴隷には言語の選択権は無い
だから言語間の優劣を論じる意味も無い
せいぜい「あの葡萄は酸っぱい」といって自分を慰めるだけ

派遣・受注奴隷には言語の選択権は無くとも
それを選んだ奴は、派遣・受注奴隷じゃないだろう？
何を言っているんだ？

だよな。最終的には、正社員（？）が決めてるはず。

だからこのスレには派遣・受注奴隷なんて居ないってことだよ

な？居ないよな？www

>>277　こんなん気にするのは派遣か受注だもんな
自社開発だったら調査検討にかなり時間掛けられるし
マイナーだろうと必要に応じて道具は選べる

>>305
お前ん中ではなってやつ？
勝手に決め付けんな。

まあcabal listで出てくるライブラリを調査検討したり
ghcのFFIでCで書かれたコード資産を問題なく使える事を確認したり
そういう時間はあるだろうね、自社開発なら

> 自社開発だったら調査検討にかなり時間掛けられるし
どういう理屈なんだろう？

> マイナーだろうと必要に応じて道具は選べる
自社にはマイナーなものを使える人がたくさんいると？

単に、お前一人で作ってる小さなプロジェクトで
過去の資産がないような歴史が浅い小企業だから
自由に選べるってだけじゃないのか？

自社開発だから、自由に使える時間がある。

ニート？

>>309
調査検討に時間使うのを承認されないって
どんなブラック企業だよ

あ、派遣・受注奴隷さんでしたかwww

やっぱり奴隷って言葉はストレート過ぎるわ
ドカタって呼ぼうぜ

>>308
うちなんかメインの資産はC++だが他のマイナー言語の資産も散在してるぞ。
依存関係的に、メインの資産にぶら下がってるんなら問題しされない。
うちはだれも速度必要ないところをC++で書きたがらないし

>>308
発売予定日なんて出さない企業なら、残業も殆ど無いぞ

足に鎖で鉄球付けられてる八は、同族どうしで
どっちの鎖が綺麗か自慢しあってりゃいい

JavaってJVMで走る言語以外と連携するの面倒
だからJavaドカタは>>277みたいなこと言ってJavaにしがみつく奴が多い

>>308
言語は社内で教育してるし、そもそも前提知識が無しで
1月以内でぐらいで関数言語すら覚えられん様なヤツは社内にいない

どこの馬の骨か知らん派遣の寄せ集めじゃないからな

まぁ、そもそも派遣を雇って何で言語を教育しなきゃならんのだってのがあるからな
必然的に派遣や請負には、教育しなくて済む案件ばかりが集まる

でもお前の会社で派遣を雇うってことは、
派遣に頼らざるを得ないということ。
雇えばいいのにねｗ

マ板でやれ

無理矢理にスレを進めて話題を逸らそうとしているように見える

>>316
教育が必要な時点でダメだろｗ
俺の会社は、最初から使える人間しか雇っていない。
だから最初から即戦力で
バリバリアプリケーションを量産できる。
今月は10個ぐらいつくったな。

携帯アプリ会社かよwなんの専門性もいらないようで何より。

別に担当がついて教育する訳でもないが、使う道具について勉強させるなんていくらでも有るだろ
入社した社員は、世の中に存在するライブラリすべてを知り尽くしてんのか？
ライブラリ覚えるのと新しい言語習得なんて大差ない

教育しないでも使えるのは
社員ではなく派遣。

誰がやっても出来る単純作業は派遣任せ

それは派遣だけで出来るのか？
どうせ後でメンテするのはお前だろう？

プログラマーに限らず工場も似たようなもんだよな
契約社員やら派遣社員が正社員と同じ事やってるのになんていってるけど
実際正社員は管理業務やってて違う理由だし

ああSEってやつだな。
技術力がないからバカにされてる人種。

おまえらってループしてるつまらん話を飽きもせずよう語れるな。それにスレチだ。

派遣や受注はこのスレくるなってことだからスレ違いでもない

ほらまた、キチガイうぜーな

>>328
ライン工も技術なんていらんけどな

ライン工とプログラマは決定的に違うだろ。
同じ物を何度も繰り返し作ってるのか
お前の会社は。

この業界で常識になってるけど
プログラミング＝詳細設計なんだよね。
生産に当たるのはコンパイラ。

>>333
入力画面つくってDBに問い合わせて画面に出力するだけの単純労働なら
派遣にまかせられるよ

>>335
効率が悪いことやってんな。
そんなの自動生成だろ。

ある程度以下のアルゴリズムとか数学が必要とされん仕事なら高卒でも十分だしなぁ

>>336
わざわざ機械化せずライン工使ってる理由考えろよ

当社は、ライン工に合わせて
言語を選んでいます。

そうなんだよな。
結局自社で作っていても
言語を選ぶ権利はない。

なんでライン工と同じ言語使ってんの？
お前もライン工レベルだから？

>>340
かわいそうな環境だな

>>340
ドカタ乙

どっちかだよ。

ライン工でも出来るようなつまらない
仕事を自分らでやるか、

ライン工雇うかわりに、ライン工に言語を合わせるか。

>>341
自社開発でJavaとか.Net系使うこと殆どないだろ
VBやDelphiなんかも使わん。

Webアプリのプログラミングなんて全部ライン工の仕事だろ
せいぜい僕ちんこんな複雑なSQL組んだよ〜♪ってことぐらいしか
職人技を発揮する場所がないよ

>>344
ライン工がする仕事は、ライン工だけがすればいいんであって
こちらが管理以上に踏み入る必要はない。

派遣と一緒にコード書いてる正社員なんているの？

実際にプログラミングしてる現場なら９９％一緒に書いてる。

その程度も知らないのはドシロウトかガキの可能性が非常に高い。

やっぱ派遣を何年も続けてる人は言うことが違うなぁ〜尊敬するわ

派遣の人だけに全部おまかせとか、放置ﾌﾟﾚｲとかあるわけねぇだろアホ。

管理はするけど、一緒に同じ仕事するわけないじゃん
どうでも良い仕事だから派遣に投げるわけで

スレが伸びてると思ったら。。。。
スレチな話題で盛りがってんなよ

Hakenn Oriented Language

ハッテン指向言語Common Lisp

Ha$kenn

次スレ立てするときは　派遣受注指向型言語 vs 関数型言語・オブジェクト指向言語　にしなきゃならんな

だからマ板でやれっての。板違いだろ。

実際のところ、vsにするほど相反する概念でもないよーな
その内、両方こなせる言語が流行るんじゃねーか？

Simulaは深遠なものを感じるがHaskellは人工的なものを感じる

コンセプトを最大限に活かす機能を言語に入れようとすると
オブジェクト指向言語は動的型付けに、
関数型言語は静的型付けに行き着く

本質的には水と油

>>361
オブジェクト指向は (静的言語に) 動的な性質を
関数型は (動的言語に) 静的な性質を持ち込む

静と動を極めたものだけがたどり着ける境地があるというのか

本質はマッチポンプ

omnes viae Romam ducunt

オブジェクト指向っても、今主力なのはオブジェクト指向“もどき”でしょう。
smalltalkのような純粋オブジェクト指向(？)となると関数型言語のようにニッチ。

SmalltalkはIF文すらブール型のメソッドであって制御構造じゃないんだよな確か

選択も反復もメッセージ送信で実現してるのに
順次だけは違うんだよね。
どうせなら徹底すれば良かったと思うが、理由はあるのかな？

もう終わった言語の話はどうでもいい

ぶっちゃけSmalltalkってマイナーなだけじゃなくて
使ってる人間にもあんまり好かれてなくね？

ttp://attractivechaos.github.com/HN-prog-lang-poll.png

善戦しているようにみえるが？

>>370
VBとCOBOLが酷いwww

Haskellより下の言語ばっかりじゃんwww

favorite / (favorite + disliked) の順位

1位: Python (マルチパラダイム）
2位: Clojure (関数型）
3位: C (手続き型）
4位: Haskell (関数型）
5位: Lua (マルチパラダイム）
6位: Lisp (関数型）
7位: Erlang (関数型）
8位: Ruby (オブジェクト指向）
9位: C# (オブジェクト指向）
10位: Scheme (関数型）


ハッカーには関数型言語の方が好まれてる

Python, Lua, Ruby, C#はあんまり差がない気がするんだけど
どこがマルチパラダイムとオブジェクト指向の境目なの？

>>375
最初からそれを前提に設計されていた言語かどうか、じゃね？

純粋な関数型であるHaskellが4位なのに
純粋なOOPであるSmalltalkは10位圏外...

>>369
日本人の派遣・請負がシランだけで今でも導入事例は多い
http://smalltalk.cincom.jp/main/successes/

しかも、Pharoとか新しい実行環境まで登場してる
ただ派遣・請負が使えないのと言語が普及率を一緒にすんな

>>370
それ自称Hacker向けだろ
教育現場とか開発現場とか実状とはまったく関係ない

Scalaも圏外か

絶対数なら単純なユーザ数がモノを言うが
好き/嫌いの比率で負けてちゃ話にならんな

かつてのSmalltalkファンが
今ではRubyやPythonを使ってるってのは良く在る話

Smalltalkは構文がダサくて読み難いし
Squeak/Pharoは玩具過ぎるし
Visual Worksはまるで古いVBみたいだし

RubyやPythonに移動したヤツなんて極少数だろ
大概プログラマー辞めて他の事してる

Smalltalkのスクリプト程読みやすい言語も無いけどな
Smalltalkはそもそも実行環境+それを操作する専用スクリプト
メインは実行環境で作って必要な所だけスクリプトで補完するから
読みづらくなることがまず無い

まぁ、Smalltalkには関数(メンバー関数)とかファイルの概念が無いからとっつき辛いヤツにはとっつき辛いだろうな。
クラスの設定はクラスのウィンドウ。手続き(メソッド)の記述は手続きのウィンドウに記述するから。
C形式の先入観を持たないならはるかに合理的に見える。英語圏の人なら小学生でも使えるしね。

流行ってない時点でだめ

　ゴリ押しが無いから目にしないだけ

使えるならごり押し無くても流行る

C++ ← MS, Nokia(Qt)
VB ← MS
C# ← MS
Java ← Sun, IBM
javascript ← Google
Python ← Google
Objective-C ←　NeXT, Apple

>>388
そうだな。だからCは相変わらず需要が減らないし、
関数型が持ち上げられるし、Smalltalkは移植環境が常に増えてるな。

実行速度がクソ遅くて良いなら移植は簡単

速度が遅くていいからinterpreterが流行る

そもそもスクリプトとして使うならどんな言語だろうと速度はいらんしな
手順道理に動けば十分

Smalltalkのイメージファイル方式は
その肝心の手順がワケ分からん事になるけどな

アレでわけわからんって小学生以下かよ

そもそもSmalltalkは他の言語と比較する事自体がおかしい
Smalltalk型開発方式 vs 言語型開発方式 ぐらいの差がある

トイプログラムしか書かないお子様には分からんだろうけど

あ、いま最もホットな処理系はScratchだからお子様向けで良いんだったね

>>396
Smalltalk型開発方式はハッキリと流行ってないね
どの言語でもその気になれば可能なのに

Smalltalkはマック信者とものづくりから逃げる連中しかいない印象

>>398
VBやらDelphiやらC#やらどれも近づこうとして中途半端だしね

省庁がまた税金使ってゴミをつくってた
既に有るSmalltalkの実行環境日本語化すりゃ安く上がるのに

【文部科学省】プログラミン【おえかき】
http://hibari.2ch.net/test/read.cgi/tech/1282208963/

>>397
トイプログラムって何が悪の？

役に立たない

smalltalker ＝雑談人＝小十日

lisper = 栗鼠波＝短舌人

javaer=蛇腹=ジャワ原人

C#er=恣意シャブ人 delphier=曖昧な人＝出る不意 haskeller=蓮啄木鳥
Pythoner=蛇人間＝廃損菜 rubiest=類賭 C++er=恣意ブラジャー

pythonはpythonista

delphiも delphian

関数型とオブジェクト指向を融合させたScalaでは
OOP部分が邪魔なゴミ扱いされて関数型スタイルのライブラリが持て囃されてるわけで
やっぱりオブジェクト指向は要らない子だな

オブジェクト指向は設計レベルでは活躍するけど
構文レベルでサポートするようなもんじゃねーよ
そんなミクロなレベルで使ってどうするって感じ
数にtimesメッセージを送る、とか馬鹿じゃネーのマジで

なるほど構文とライブラリを混同する馬鹿じゃネーの

>>411
メインでは言語なに使ってるの？

ある程度以上に規模が大きくなると
全体をモノリシックなシステムとして設計するのは不可能で
オブジェクトがメッセージをやりとりするというデザインにする必要がある

でも、モノリシックに書ける規模までそういうデザインにするのは
単にコードの見通しが悪くなり、処理速度も遅くなるだけ

ただし、トイプログラムでも規模の大きいアプリと同じ設計手法が使えるので
トイプログラマーが「自分も大きいプログラムを作ってる」と錯覚できる
だからトイプログラマーには大人気

関数型は所詮関数だよ。

オブジェクト指向でフレームワークを作って
その中で呼ばれる関数で使うもの。

ADTやモジュールや型クラスがあれば
OOPのクラスが無くてもフレームワークくらい作れますよ？

馬鹿には無理

> ADTやモジュールや型クラスがあれば

それ自体が関数型言語の機能と特徴に
反しているわけだがｗ

>>419
全然反していないよ？
良く知らない話題に無理して首突っ込まない方が良いんじゃない？

>>419が「関数型言語の機能と特徴」を理解してるとは思えない

クラスに反応するbotだろ。釣られるなよ

>>420-421
反論するならちゃんと説明しないと逆効果だよｗ

>>423
まずお前が「関数型言語の機能と特徴」について説明するのが先じゃね？

大抵の関数型言語には>>417に類する機能があって使われてるのに
関数型言語の機能や特徴に反してると言われてもな……
お前のいう関数型言語って何よ？という話になるわな

クラス至上エセOOに染まったPGは
クラスが無いと大規模プログラミング出来ないと
錯覚するらしいよ、Javaとかの

>>417
揚げ足だがFrameworkの定義が不明。
そもそも英語圏じゃFrameworkなんて要綱・格子案・骨組み
といった意味を表す形容詞でしかない。

何かを作り、誰かがFrameworkと形容してしまえば全て
FrameworkなんだからFrameworkを作れるという表現は意味が無い。

ということで、関数型言語で作られた
デスクトップフレームワーク、もしくは
ウェブフレームワークの話をしようよ。

MVCモデルを採用したもの有る？

CLOSというOOを実現するFrameworkはある。
あっちではこういうものもFrameworkと言ったりする。

Web用ならWeblocksってのがあるな

>>428
MVCなんてまともに実装してんのOOPLでも
Smalltalk派生環境ぐらいでしょ。
Web用のなんちゃってMVCはModelをControler同士でまともに共有できないし、
ModelのためのFrameworkも無い。

いえMVCの定義とかそんなことはどうでもよくて、
重要なのはそれに変わるものがあるのですか？ってことですよ。

Weblocks

Weblocks に関しての記事を読んだ。
http://e-arrows.sakura.ne.jp/lisp/common-lisp/

Common Lisp のオブジェクトシステム CLOSは初めて公に規格化されたオブジェクトシステムらしいし、
Common Lispを関数型言語 VS OOPLの文脈で関数型としていいのか疑問。

>>435
それって要するに関数型言語 VS OOPLという図式自体が成り立たないことの証左じゃ…

Lispしか知らんけど、Web系の一部をあげるとこんな感じ

Framework系
・kpax
・cl-weblocks
・cl-terrace(MVC型)

Framework補助
・lisp-on-lines(宣言的に関数らしく構築できる)

CMS/VMS系
・cl-eshop(商業ページ用)
・CLEWS(教育環境構築用)
・ALIW(情報共有ページ作成用)
・CL-WIKI
・CLiki(WebのAutoringができる)

Blog系
・blogsym
・cl-blog
・ext-blog(WordPressと互換性のあるやつ)

他
・cl-amazonproduct(Amazonの広告操作)
(Amazon系は、Amazonが昔Lispを使っていただけに種類が多いので省略)

そう。オブジェクト指向のフレームワークの中で
関数型言語を使うか手続き型を使うかの
違いでしか無い。

>>435
関数型の上にOOが乗っかってるって図式は理解できないのか？

結局さ、関数型とOOPってのは
対立したり相反したり排他的な関係じゃないんだよ
むしろ相互に補完し合う関係だと思う、vsなんて成り立たない

>>435
例えば、C++のtemplateは無名関数の無い関数型(curry化は最近できるようになった)。
templateを評価した結果としてclassを返す。
OOと関数型が違う階(Rank)で存在するというのは割と身近にある。

多くの実績があるオブジェクト指向言語が
関数型言語の機能を取り入れだした。

関数型言語は無駄なものじゃないよ。
ただ関数型言語だけで作るのは
オブジェクト指向言語だけで作るよりも
はるかに面倒で大規模アプリは作りにくくなる。

>>442
ぶっちゃけ無名関数は関数型必須要素じゃない
だから無名関数持ってる程度で関数型を取り入れるのは違和感がある
関数型の特徴はパターンマッチ・再帰でしょ

あと純粋に守ってる言語も多くないが副作用除去か

パターンマッチ・再帰ができない
言語なんて有るのか？ｗ

>>446
C系統の言語は、スタックオーバーするから100万回とか
メッセージループをひたすら回すといった完全な再帰は出来ない

それからパターンマッチってのは正規表現とかの文字列に対するパターンマッチじゃない
リストに対するパターンマッチ。これができる言語はC系ならC++のtemplateぐらい
身近な関数型だとXSLTでよくみる。ちなみにXSLTやC++のtemplateに副作用は存在しない

だがそんなのは工夫次第でなんとでもなる。

そこらへんが実践と研究の違いだろうね。
実践だと物量（既存ライブラリや人的リソース）で押しきれる問題を
ちまちまと解決しようとするのが研究

工夫で何とかなるならCだけでいい
OOも関数型もライブラリ上で構築できるしな

>>448
国内じゃHTML至上主義があるのか、ほとんど見かけないけど
Web作るんだったらjspやphp使うよりXML+XSLTで構築した方が断然作りやすい
海外じゃ割とみる。実際のところただ使いこなせないだけだろ。

> XML+XSLTで構築した方が断然作りやすい

それ苦痛なだけだよｗ
デザイン重視や使いかっての良いUIを作るのはほぼ不可能
せいぜい、何かのリストを整形するのが関の山。

> 海外じゃ割とみる。

どこ？ アップル？ マイクロソフト？

>>427
提供されるソフトウェアからユーザの作成したコードを呼び出すものがフレームワーク
ユーザのコードから提供されるソフトウェアを呼び出す場合はライブラリ

>>448
そういうのを人的リソースで押し切ろうとするのがドカタなんだ

またキモい奴が来たｗ

>>453
んな定義主張してんの極一部だけだろ

FizzBuzzすら自力で書けないドカタがメソッドを順番に呼ぶだけで
アプリを作れるようにしたものがフレームワーク

>>456
どんな定義が一般的なの？
まさか>>457？

>>458
要綱・格子案・骨組みという形容詞
形容されれば全部Framework

それ一般的過ぎだから
http://en.wikipedia.org/wiki/Software_framework

Clojure, Scala : Java
Haskell, OCaml, Lisp : C/C++
F# : .Net
（関数型言語 : 利用できるコードベース）

こんな感じで、既存のコードベースを一切捨てずに
関数型言語を使い始める事ができるのが、
最近の関数型言語の流行に一躍買ってる気がする
上に書いた以外でも、Thriftとか使えば大抵の言語間ではRPCできるし

だからライブラリやフレームワークの不足は全然ハンデにならない
実際不足してないから

>>452
何でDevelopperなんだよ、jspで書かれたMSのサイトがあるか？aspで書かれたAppleのサイトがあるか？
引き合いに出すならBloombergとかだろ。

で、肝心のXSLで作成されたページだが 7,190,000 件ある。
http://www.google.co.jp/search?sourceid=chrome&ie=UTF-8&q=filetype%3Axsl
filetype:xslで引っかかるヤツはサーバーサイドXSL。大体FileMakerベースだ。
ただ、サーバーサイドXSLは、jspだろうがaspだろうが、どっちをベースにしても作れるんで
実際内部で使用してるのを含めたらこれ以上になる。Javaも.netもXSLでページを作るための
支援機能もってるからな。

>>451
デザインに凝ったページだって楽に作れる
http://www.harpercollins.co.nz/fmi/xsl/nz/book_details.xsl?isbn13=9780062083692
どーせベースのXMLをデータ構造じゃなく人間の見やすさで作って
リレーション組めず挫折したオチだろ。DBの仕組みとか再勉強しろよ

>>460
Task Parallelism in a High Performance Fortran Framework (1994)
Java Collection Framework.
.Net Framework.
Spring Framework.

Frameworkたる共通点を述べよ。と言っても
実際バズワード扱いされてるから無理だと思うが。
http://www.buzzwordhell.com/framework/

日本語版Wikipediaでも下の方に関連バズワードって皮肉られてるでしょ。

バズワードってレッテル貼って安心しちゃうのは馬鹿の典型的な行動だなw

意味のないラベルをありがたるヤツはマイナスイオンに群がるババアと同じ
どうせ数年後はWeb2.0と同じ運命だ
バズワードと言われたくないなら正確な定義を作れ

正確な定義なんて不可能なものはいくらもある。
正体が不明だろうがなんだろうが、分かる範囲でなんとかするのが工学。

厳密な定義を巡って侃々諤々したいなら500年昔に行って神学でもやってろ。

意味のないラベルの代表例→「バズワード」

バズワード程意味が明確な言葉もないだろ
フレームワークに比べりゃ段違いにはっきりしてる

フレームワークはバズワード
HTMLはバズワードじゃない

完全に意味を使い分けできる

>>468
理由が書いてないから、そのレスは無効

>>466
不確定なものを人間が作り出す必要はないし
技術者がありがたるのはマイナスイオンの信奉者以上にマヌケ

>>469
理由 >>463 の様に定義が未定である = バズワード
規格書や厳密な定義がある != バズワード
バズワード = 定義が無いのに巷にあふれてる言葉

>>466
根拠の無い言葉が許されるのは、ガキと主婦と営業と政治家ぐらいだろうが。

こいつらのうち何人かはWeb2.0の勉強会とかしてたんだろうな〜w

やれASP(Application Service Provider)だSaaSだクラウドだ
あきねぇよなぁ

オブジェクト指向も関数型も厳密な定義はないからバズワードってことか？
このスレ全否定だなwww

>>463
> 日本語版Wikipediaでも下の方に関連バズワードって皮肉られてるでしょ。

えーと、どこに書いてあるか引用してみてくれる？

http://ja.wikipedia.org/wiki/%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E3%83%95%E3%83%AC%E3%83%BC%E3%83%A0%E3%83%AF%E3%83%BC%E3%82%AF

定義が未定だと バズワード というのなら
定義を作ってしまえば、バズワードではないということだな。

関数型言語の定義はなんでしょうか？
関数型言語はバズワードでは？

プログラマはバズワード

>>476
http://ja.wikipedia.org/wiki/%E3%83%95%E3%83%AC%E3%83%BC%E3%83%A0%E3%83%AF%E3%83%BC%E3%82%AF

このページは曖昧さ回避のためのページです。一つの言葉や名前が二つ以上の意味や物に用いられている場合の
水先案内のために、異なる用法を一覧にしてあります。お探しの用語に一番近い記事を選んで下さい。このページへ
リンクしているページを見つけたら、リンクを適切な項目に張り替えて下さい。
カテゴリ：バズワード曖昧さ回避

>>477
当たり前

厳密な定義とか言ってるけどさ、formal semanticsが与えられてる
プログラミング言語なんてどれだけあるよ
Standard MLは良いとして、オブジェクト指向言語で何かひとつでも在ったっけ？

>>478
Conception, evolution, and application of functional programming languages
で提唱されてる内容だろ。

>>480
このスレでフレームワークと呼んでるのはsoftware frameworkのことに決まってるだろ
そっちはバズワードにカテゴライズされてない

>>483
提唱は、定義ではない。

定義でないから、提唱してるんだよ。

>>482
どういう言語が正しいかなら。
規格ないし、規格が無ければ言語の処理系で動く言語だろ至極明解じゃん。
そもそもフレームワークと違ってこっちは線引きをはっきり
させないと仕事にならんしな。

>>485
だからそれを目指してる言語だろ。
それを無視してる言語は関数型とは呼ばん。

>>484
Wikipediaでフレームワーク全体がバズ扱いなんだから知らんがな。
大体Wikipedia自体宛にならんし、既に出てるページの様に英語圏じゃバズワード扱いするヤツも多い。
英語版Wikipediaの会話見てみろ、意見がまとまってねーじゃねぇか。
http://en.wikipedia.org/wiki/Talk:Software_framework

大抵のプログラミング言語は意見まとまってなくても
無理矢理規格化してるけど？

そもそも話の流れ的にフレームワークって
言い出したの>>416なんだよね

フレームワークがバズワードでも良いけど
「オブジェクト指向でフレームワークを作って
その中で呼ばれる関数で使うもの（キリッ」って言い出した
>>416がアホみたいで可哀想

>>489
それがどうした？規格化されたら、その規格が言語の定義だろ。
Wikipediaでの議論が規格や定義に影響するんか？
WikipediaでCのページ作ったら、Cの処理系作るのにWikipediaにあわせにゃならんのか？

"functional programming"
https://www.google.com/#hl=en&q=%22functional+programming%22
About 13,600,000 results

"functional programming" buzzword
https://www.google.com/#hl=en&q=%22functional+programming%22+buzzword
About 66,100 results

比率：0.486%


framework
https://www.google.com/#hl=en&q=framework
About 150,000,000 results

framework buzzword
https://www.google.com/#hl=en&q=framework+buzzword
About 957,000 results

比率：0.638%


"object oriented programming"
https://www.google.com/#hl=en&q=%22object+oriented+programming%22
About 10,500,000 results

"object oriented programming" buzzword
https://www.google.com/#hl=en&q=%22object+oriented+programming%22+buzzword
About 500,000 results

比率：4.762%

フレームワークに意義を持ちたいヤツはフレームワークの要件定義してみろよ
結局堂々巡りするだけだろバカバカしい

>>488
wikipediaも大概あてにならんが、お前さんが>>463で引用したサイト
（超マイナーな上にReferencesすら無い）よりは100倍マシだぜ

フレームワークはバズワード
オブジェクト指向はもっとバズワード

以上

まぁ世の中がどうとかどうでもいいや
実用上フレームワークという言葉をつかうとマーケティング以外で何に使えるんだ？

そりゃお前さんみたいな
フレーム問題を超えられない人工無能レベルの
コミュ障でなければ意思疎通に使えるよ

じゃつかってみろよホレホレ
ネイティブの人間ですら合意の取れてない言葉をよ

どうせ形容詞レベルでしか意味の有る使い方できんだろw

おまえら水掛け論だと元気だな

>>497
Task Parallelism in a High Performance Fortran Framework (1994)
Java Collection Framework.
.Net Framework.
この辺のFrameworkってどういう意味よ？

まず第一に英語ではframeworkは名詞だから
何語の話をしてるのか知らんが

flame work

>>503
分割して書いてもframeworkは名詞だからね
大体>>501の"a High Performance Fortran Framework"を見て
「あれ？形容詞って言っちゃったけどおかしいな？」って思わないのかよ

ああ、俺はあほだ

形容詞とか品詞の話はしてないんだけどなー
形容してると形容詞の違い解りますか？

>>506
???

>>427
> そもそも英語圏じゃFrameworkなんて要綱・格子案・骨組み
> といった意味を表す形容詞でしかない。

>>459
> 要綱・格子案・骨組みという形容詞

>>504
そうか名詞なのか。で、名詞のFrameworkがついてると他とどう違うんだ。

>>507
品詞上どうかはどうでもいいんだつうの

>>507 そういうところは細かいのに意味が曖昧な事にかんしてはおおらかなんだな

言葉の厳密な定義にこだわる割には
自分の発言には大雑把なんだな

え？いやだって皆カタカナでフレームワークって書いてたのに
一人カッコつけてFrameworkとか書いてた人が
実は全然英語分かりませんでした、とかマジうけるじゃん

>>501はどうなったの？

>>511
厳密な定義ねぇ〜

ああそれ？www
一番目はFortranを形容してて、二番目はCollectionを形容してて、
三番目は.Netを形容してるんだよ

「骨組みなFortran」ぷぷぷwww

そうなんだー結局骨組みのFORTRANになるんだーへー

ほぅ高性能FORTRANにおける並列処理基盤の意味かと思ったけど違うのか。
ともあれこのFrameworkって用語は他の2つとどうつながってるんだろうなぁ

>>506
> 形容してると形容詞の違い解りますか？

「違い分かりますか？（キリッ」じゃねーっつーのww
どっちでもオカシ過ぎるだろーがwww

誰もフレームワークの定義なんて知らないんだからそろそろ下らない話止めないか

誰も関数型言語の定義なんて知らないんだからそろそろ下らない話止めないか

どういうものを関数型というかは文章が上の方に出てたろ

曖昧な定義は定義とは言えない。

関数型：全ての操作を関数だけで行う(ラムダ計算)ことを目指した言語
OOPLより明解だよな

全ての操作を関数だけで行うというのは
必須なのか？

関数型言語は>>523でいいだろ
LispやMLを仲間に入れようとするから「目指す」なんて物言いになってるが
純粋関数型言語ならまさにその通りだし、
LispやMLでも殆どのコードは純粋な関数として書いて副作用は注意深く一部に制限する

逆に聞くけど、オブジェクト指向言語の定義って何よ？
ちまたのオブジェクト指向言語と呼ばれるものを特徴づける共通の性質は？

関数型：全ての操作を関数だけで行う(ラムダ計算)ことを目指した言語
オブジェクト指向：オブジェクトを実装するのに適した仕様を持っている言語

関数型言語っていうのは、
表現の幅を小さくしたもの

オブジェクト指向言語というのは
表現の幅を大きくしたもの

だから全体の設計（アーキテクチャ）は
表現能力が高いオブジェクト指向を使い、

その中の小さな一部分に関数型言語を使用するのが
一番適している。

対比させたいんだろうけど
>オブジェクト指向言語というのは
>表現の幅を大きくしたもの
はおかしい

>>525
ポリモフィズム：対象に応じてメッセージやメソッド呼び出しによる処理が選択される
インヘリタンス：あるオブジェクトの性質を受け継いだ別の性質のオブジェクトを作成することができる
アクセス制御・カプセル化：一部の性質を外部に対して隠ぺいすることができる

この辺を備えたのがOOPLじゃないかな、OOPLを名乗っててこれらを備えてない言語って何がある？
L（言語）を外して「OOP」にすると若干曖昧になるが

>>525
>逆に聞くけど、オブジェクト指向言語の定義って何よ？

CTMCP(Concepts, Techniques, and Models of Computer Programming)では、
抽象データ型を何度もコピーしないで済むように、継承・カプセル化・クラスの概念を加えたもの、となってる。

従来型のCなどでのstatefulプログラミングだけでは扱いにくい問題、
例えば都市交通シミュレーションで交差点を表現するとかに有効。

・他モジュールの処理の大半を引き継ぎたい　→　継承で解決
・継承だけでは、グローバル変数だらけと大差無くなる　→　カプセル化で解決
・同一ロジックで、内部データだけ微妙に違うものを沢山生成したい　→　クラスで解決

>>523
>関数型：全ての操作を関数だけで行う(ラムダ計算)ことを目指した言語

ラムダ以外にも、パイ計算、シーケント計算など色々ある。

クラスの無いOOPL（プロトタイプベースとか）もあるから、クラスは流石に必須事項ではないと思う

関数型は、プログラム全体を式として表現する言語…のような気がするが関数型の人たちにとってはどうなん

そもそもオブジェクトって何？

>>529
ライブラリベースを含めれば増えるが言語に限ればこんな感じか

アクセス制限が全くない
Javascript( 出来なくもないが )
Perl
Python
Self
Go(カプセル化してしまえばあんまり関係ない?)
AppleScript
Groovy
Io
他プロトタイプベース系

メンバー関数もしくは、メッセージに制限が無い
Smalltalk
Objective-C
JADE

実装継承が無い
PL/SQL
VB6.0以前
Go
Emerald

構築子の継承が無い
Io
Javascript

>>534
メッセージを受け取ってメソッドを起動したり、メッセージ転送を行えるもの。

>>535
メッセージに制限が無いってどういうこと？

>>531
だね。
ただ究極的には関数だけで演算や処理する言語ってのはあってんじゃね。

>>537
メソッドを実装してなくてもメッセージは受けられる
ただし構文エラーにはならないが実行エラーになったりする

>>539は、ズレてた忘れてくれ
メッセージに対し呼び出せるメソッドを限定できずprivateメソッドが存在しないんだ

>>540
良く分からん、アホの子にも分かるように説明して
メッセージに対する実行時メソッド探索の話なんだよね？

>>541
privateなメンバー関数を作れない

>>542
それは>>535の「アクセス制限が全くない」言語は全部当てはまると思うけど、
その理解で良いの？

>>543
あってるよ。

>>535
JSにはあるし、Pythonは擬似的なアクセス制限があるじゃない
SelfやGo、Ioは知らんが、PerlやAppleScriptってOOPL名乗ってたっけ…？

あと「メンバ関数もしくはメッセージに制限が無い」「構築子の継承が無い」ってどゆこと？
JSは継承自体は存在するけど、構築子？

擬似ならどの言語でもできるがな、それこそCでも

>>545
JSのアクセス制限とは具体的に何？
function Type()
{
     var member = 10;
     this.method = function(){ return member; };
}
こんなんとか出きるには出きるけど。

>>547
それのことだよ

だからJavascript( 出来なくもないが )とかいてんじゃん
実際にこのやり方すると関数の継承出来なくなるし
パフォーマンスがっつり落ちるからメンバーさらすのが普通でしょ。

>>529
Haskellも全部備えてね？HaskellもOOPLってこと？

OOPLかどうかなんてどうでもいいよ
メッセージ送信を体現できりゃOOPLだろうが関数型だろうがどうでもいい
問題は何が出来るかであって、どういう概念をもってるかじゃないだろうし
そんなんやってたらいつまでも道具に使われるだけ

>>550
もしかしたらそう言えたとして何も問題はないと思うよ

>>551
ポリモーフィズムできればメッセージ送信なんて体現してなかろうがどうでもいい
そんなのに拘ってるのキモイSmalltalk使いだけ

>>152
今北んですがへー、面白そうじゃん、てんで流れも読まず、また今さらですが…

use 5.12.0;
use Data::Dump qw(dump);

my @a = 1..4;

sub fn {
  my ($le, $pv, @ri) = @_;
  defined $pv ? map {[$pv, @$_]} fn([], @$le, @ri) : ([])
    ,
  @ri ? fn([@$le, $pv], @ri) : ()
}

say dump(fn [], @a);

こんなのすぐ出来たよ…てのは嘘で恥ずかしながらうまく行くまで半日ほど考えましたｗ
ｶﾞﾍﾞｰｼﾞの生成を抑制する、よりperlらしい書き方もあるだろうけど、読みやすさ優先でそこは目をつぶりました。

ErlangといいObjective-Cといいメッセージが使える言語は
最初っからMPI搭載してるようなもんだから通信が楽だねぇ
もっとメッセージサポートする言語が増えたらいいのにな

object->method(params) とさ
method(object, params) ってさ
書き方が違うだけでほぼ同じだよね。

で、違いがあるとすればさ、
object->method()は、objectのprivate変数にアクセスできるけど、
method(object)だと、アクセスできない。

と言うことは、オブジェクト指向というのは、
objectのprivate変数へのアクセス制限があることが重要だと思うんだけど。

>>556
・ﾃﾞｰﾀドリブンな記法
と
・パッケージまたはクラスｽｺｰﾌﾟ
必ずしも一致でないのでは？
private(インスタンス)変数に相当する変数のスコープをどこにどうもつかでしょ
オブジェクト指向ってのはほんと誤解されてるし言葉が一人歩きして色々な意味に尽かされてるなあと思う

指針となるテキストがないから当然

FILE * を出発点として考えていたんですけど、これも一つに見方にすぎないのか。

>>559
FILE *に関して言えば、中のデータ構造とテーブル管理の仕様を丁寧に設計すれば
ﾃﾞｰﾀﾄﾞﾘﾌﾞﾝなオブジェクト指向風との差は、呼び出し方の記法および
内部データの管理のためのコードを多少省けるくらいでは？

>>556
method(object, params)

lispとか、Pythonとかちょうどそんな感じでよびだす

>>556
アクセス制限の無いOOPLなら8以上はある
アクセス制限は、ミスを減らすためのものであってOOの要件じゃない
情報隠蔽機能がなくてもユーザーがカプセル化に
気を遣ってれば再利用性は下がらないからね

>>554
この問題は、オブジェクト指向＋手続型言語的にclassもうけてifだのforだのflagインスタンス変数だの使って
チマチマグチャグチャ書いたらめんどくさいだろうなってんで再帰を使ってみたけれど、
問題を細分化して再帰するならば、だれか高階関数使って書いてみてよ
できれば匿名関数の自己末尾再帰で（ﾊｰﾄ
いやま時間があればｵﾚもやってみるけれどもさ…

>>562
そうなんだよね。

オブジェクト指向というのは結局のところ
”指向”という言葉の通りで、考え方。
どちらかというと全体の設計思想のことなんだよね。

どういうふうにコンポーネントを分けて
どのように組み合わせるか。

それに対して関数型言語はコードの書き方。
小さい範囲（関数）をこのように書けば
テストが容易になりますよとか。

再利用性やユニットテストのやり易さを考慮すると
データ構造とアルゴリズムは分離したほうが良いんだが
オブジェクト指向って基本的に逆だよね

>>564
> 小さい範囲（関数）をこのように書けば
> テストが容易になりますよとか。

関数型言語においては「関数 = 小さい範囲」という図式は成り立たない

>>566
オブジェクト指向だと、クラス（関数の集まり）とか
さらにそのクラス間の関係、差分プログラミングといった話は
普通に出てくるんだけど、関数型言語の場合、
再帰とか副作用とかラムダとか、一つの処理で
完結する話しか出てこないよね。

関数の族とか、差分プログラミングという話は、普通に出てくるんだけど。

>>564
細かい粒度でclassを使う必用が低減され、objectを主にﾓｼﾞｭﾗﾚｨﾃｨｰの向上
など必要に応じて使えば良くなるﾒﾘｯﾄは大きいと思うよ。
これはCLOSとかECMAとか関数型でｶﾂｵﾌﾞｼﾞｪｸﾄ指向も備えた言語の場合だけれど。

関数型ﾌﾟﾛｸﾞﾗﾐﾝｸﾞは有効な局面ですんごく威力有ると思う。
使わない手はない。
しかし幅広い処理にも有効かは、ｵﾚにはまだわからない。

ｵﾌﾞｼﾞｪｸﾄ指向は…型推論の弱い型付き言語でclassﾍﾞｰｽ、継承で共有する(mixinやtreitでない)ﾀｲﾌﾟ
のものは有効性に個人的に疑問を持つことがあるし、使い方によって害もあると感じている。
入門ﾃｷｽﾄも含めその害まで含め誤解や拡大解釈が幅広く流布している、それが現状だと感じている。

True = function( Then ){ return function( Else ){ return Then; }; };
False = function( Then ){ return function( Else ){ return Else; }; };

bool = True;
println( bool( "true" )( "false" ) );
bool = False;
println( bool( "true" )( "false" ) );

おもしれぇなぁ。あと、IsZeroを関数だけで実装できりゃ最高なんだけど。

>>567
OOPLではオブジェクト（またはクラス）だけで
多態や静的スコープや名前空間や差分プログラミングなどの
多くの機能を提供するけど、関数型言語では
それぞれが直交する言語機能として提供される（ことが多い）

逆に言えばその程度の違いなので、OOPでちゃんと設計できる人なら
関数型言語でも設計レベルでは困らないと思う

関数型でセルオートマトンとかあほかと思う

>>573
なぜ？

人間の思考に近いのがオブジェクト指向なんだよね。

誰しも”物”という単位で物事を考えている。
メソッドとプロパティは本質的には同じものなんだけど、
人間の思考では、動詞と形容詞は違うものとして考える。

だから優れてる云々ではなく、より人間の思考的なオブジェクト指向を
基本的な設計として使い、関数型言語の便利なものを、ちょこちょこ
取り入れるという方法が受け入れられやすい。

おまけで、受け入れられやすいと人が多く集まり、
それが力となって、便利なライブラリなどが量産される。
結果的に生産性も上がることになる。

現在までのところ、多数のユーザを獲得できるか否かは
C系列手続き型の系譜かどうかで決まってて
オブジェクト指向は無関係に見えるが

ていうか、見た目がCっぽいか否かが問題で、抽象構文とか意味じゃないんだよな。
Go は拒絶するが PHP は受け入れる、とかそんな感じ。

ユーザ数一位と言っても良いJavaは
言語がヘボすぎて洗練されたAPIをデザインできず
同じ目的の使い勝手の悪いライブラリが沢山あるという切ない状況になってる
ある程度は言語も重要

＞＞５７７
goスレも無くなってるようだけど、どうなったん？
GOOGLEさんちのひろみくんは余り普及してないの？

なでしこってどうなの？

Goはバージョン1が出たところだな

今年ISO化されたRubyの開発開始が1993年
ISO化すらされてないJavaの開発開始は1990年
Goが流行るかどうかは知らんがまだ見限る時期でもないだろうに

>>582
「goスレが無い→流行ってないの？」というパターンは
2chで世界が判った気になってる奴に多いけどな。

>>576
> 現在までのところ、多数のユーザを獲得できるか否かは
> C系列手続き型の系譜かどうかで決まってて

違うと思うけど。VBとかCOBOLの例があるし。

多数のユーザーを獲得するのは特定の分野で適していたからだよ。
今は別の選択肢ができたかもしれないが、普及した当時ね。

たとえば
C言語だと、速度が早い（昔は特に重要）、組み込みに適している。
VB、Windowsで簡単なGUIを作るのがすごく楽だった。
C#、〃 （時代の違い）
C++、C言語＋オブジェクト指向。
COBOL、金融関係で強い
JavaScript、ブラウザでそのまま動く
PHP、レンタルサーバーでもほぼデフォルトで組み込まれている
Java、専有サーバーに限定されるが、高速なウェブアプリを作る場合
Objective-C、iPhone、iPadアプリを作るのに必須だから。当然最近増えてきた

> オブジェクト指向は無関係に見えるが

一見オブジェクト指向かどうかは無関係に見えるけど
比較的最近普及した言語は全部オブジェクト指向だよ。
オブジェクト指向じゃないのは時代的な理由のため。（普及した当時は技術もスペックも足りなかった）

>>578
言語名間違ってるぞ。

ただしくは、

Perlは
言語がヘボすぎて洗練されたAPIをデザインできず
同じ目的の使い勝手の悪いライブラリが沢山あるという切ない状況になってる
ある程度は言語も重要

Javaで同じ目的のライブラリがたくさんあるなんて
聞いたこと無いな。

>>584
CとCOBOL以外単にベンダーのゴリ押しだろ
COBOLについては、その当時COBOLぐらいしか
金融に使える言語はなかった。
その後他の言語に移行しようとしても資産が多すぎて
移行出来なかったのが実状。

>>578
ユーザー数1位はbatか、VBAだろ
次いでjavascript、C。どっかにグラフが有ったぞ。

>>586
普及した理由が違うだけで、
C系列手続き型の系譜かどうかは関係ない
ってのは、同じですね？

そりゃな。一時期Delphiがメジャーだった時代があったがMSに潰されたし。
Javaも2003年ぐらいは死んだ言語と言われてたが、Sunがサーバーサイドを強調して
ゴリ押しした結果復活した。IBMの力技Eclipseの影響も大きい。
JavascriptはGoogleのAjaxのおかげ。
.Net系はVisual Studioの.Net移行と.Netライブラリ群のおかげ。
Rubyなんか一見仕事で見かけるから流行ってるように見えるが、
世界的にはPythonに負けて流行ってない。
PythonはGoogleやRedHatがバックに居る。

えぇ、だからC系列かどうかは関係ない。

そして全てオブジェクト指向である。

どっちかっつうと全部手続き型
純粋に近いもの程流行らない

ま、アホばっかりですからね

流行る言語の条件
・手続き型であること（ドカタが理解できる）
・企業のゴリ押し（ドカタが仕事にありつける）

>>593
ぜんぜん違うだろｗ

・オブジェクト指向であること（手続き型で流行ったのはオブジェクト指向自体が普及してない時代の話）
・特定の分野で優れた言語であること

言い方を変えてもこのことは否定出来ないぞｗ

VBもPHPもオブジェクト指向機能が付く前に普及した

>>594
ドカタってそうやって自分を慰めてるんだwww
おもしろーい

>>594
どっちでもいいんじゃない？
流行ってるかどうかを気にしてるうちは三流だし。

今流行ってるのはC言語だよ。
関数型もオブジェクト指向も直感的と言うには引き算されすぎててさ。

>>575
>人間の思考に近いのがオブジェクト指向なんだよね。
アホか

ん〜でもアホの指向回路はオブジェクト指向に近いから、言いえて妙かも。

ドカタにとっては流行ってるかどうかが最重要なんだよ！！！

はいはい

>>575
もの以外は関数型言語の方が直感的だ
そして、プログラミングの大半はもの以外を対象とする事が多い

複数のプログラミング言語を日常的に駆使してる者なんて、地球人口の0.1%も居ないだろうに、
その狭い環境の中で流行り廃りを気にするのは何でだろう？

さあ

分母は地球の人口ではなくプログラマじゃないと

流行り廃り気にするんだったら、C言語使っとけって。
昔から流行ってて、今も使われてるんだから。

まず自分の使いたい言語が存在する
その言語が流行れば言語環境が整備されると期待できる
だから流行り廃りを気にする

そういう人にC使っとけってのはピントがずれてると思うの

pascalは流行ってなくてもRAD環境整ってるが。。。

つまり、流行り廃りは気になるけど、乗り換える気はない、と？
それは子供の考え方だよ。厨って言われるよ。
自分の選択に起因した不利益の対処は、
選択を変えるか、趣向と受け止めるか、
しか認められてないよ。
周りを気にするぐらいなら、乗り換えろってのが世間の目。

いいのを見つけたから、皆に知って欲しい、流行って欲しい！！
→ファンと呼ばれる。積極的で普及の為の手間を惜しまない。

流行ってる奴を教えてくれ、流行ってないのをやるのは嫌だ。
→依存型。消極的で、他のものの成果だけ欲しいが、自分が貢献する気はない。

へえ

>>611
依存型も今風で良いと思うんよ。
常に流行をチェックして、最善の選択に勤める、つーんだから。
ただ、>>608の発言は、その努力すら怠ってるっつーか。
しいて言えば、ゲハみたいな。

私には見えない物が見えます、まで読んだ。

依存型とか書いてあるからCoq等の話題かと一瞬オモタ

>>594
オブジェクト指向支援機構はついてても、
ライブラリ使用するのに使ってるだけで
全然オブジェクト指向な開発してないだろ。
所詮クラスライブラリ使ってるだけの手続き。
本当にOO使ってるというなら、OO強制する言語でも普及するだろ。

もしケーキを作ろうと考えたら
オブジェクト指向なら素直に表現できるよね？
材料から道具まで。

>>616
そりゃ、すでにライブラリが存在してるんだから使うだろ？

>>618
オーバーライドして使用してんの大概スレッドか
リスナークラスぐらいだろ。
OOだっつうなら、イテレーターやら、バッファーやら
オーバーライドですむものはオーバーライドするだろ。
でも大概、既にあるオブジェクトに一旦詰め込んでgetterの
戻り値で受けとってんのばっか。

>>619
うん。お前の所はな。

>>619
そもそも論で言えば、
ライブラリとかフレームワークは
自分が作ってもいいところだよ。

すでに誰かが作ったものってのは
もしかしたら社内で作っていたかもしれないもの。

で、それがオブジェクト指向で作られてるだろう？

社内でやるか、社外でやるかの違いであって
オブジェクト指向の開発であることに違いはないよ。

>>621
違う。インターフェースの再利用ができてないってこと。
社内でオレオレインターフェース定義してもそれじゃ、
クラスライブラリの恩恵は手続きと同じだけしか受けられない。

ドカタは自分のところで作れない
自分で作れないから流行り廃りを気にする

>>622
お前の会社特有の話なんかしらんよ。
単にお前の所とお前の知ってる狭い範囲が技術力低いだけだろ。

>>623
じゃあお前はどの言語を作ってるんだい？（苦笑）

>>624
インターフェースを再利用する意味を理解してないだろ。

>>625
俺はお前の使ってる言語分かるよ。ドカタの定番Javaだろ？

>>626
なんでそういうレスが来るのかわからんのだが？
俺はインターフェースの話なんかしていなくて、
>>622の会社がおかしいだけって言ってるだけなんだが？

>>627
質問の答になっていない。

>>628
そのレス自体にレスしたつもりじゃなかった。
お前自身に言いたかっただけ。すまんな食い違って。

俺のこと知るわけ無いんだからだから言いがかりでしか無いな。

いやお前の私状はどうでもよくて>>621がズレてたからなんだがな

つーかさ、関数型言語を何か一つでも使えて、実際に開発できて、
その上でオブジェクト指向言語の優位性を説いてるなら良いんだが
そうじゃないのが見え見えなんだよな、
流行り廃りを気にしてるヤツは（>>608とか）

自分が新しい言語を覚えない言い訳に
流行り廃りを持ち出してるだけ

>>632
それでどこがずれてるかの指摘は？

>>633
いや、関数型は使える前提で
オブジェクト指向のほうがより自然だよねって言ってる。

だって、ケーキを作るという問題があったとして
材料から道具までオブジェクト指向なら素直に表現できるよね？

>>635
え？お前関数型使えんの？嘘でしょ？

現実をシミュレーションするなら、オブジェクトとメッセージパッシングが素直な表現だよね。

知らないってことにしないと都合がわるいんだろうね。
自分より上であることを認めたくない。

だから、思い込みで言いがかりをつけて
満足感を得るという戦略に出る。

少しは相手ができることを前提に
話をしろよ。

ほらな、言ったそばから>>636のようなレスが出てくるｗ

>>638
よし。じゃあ木に対するfilterを書いてみて
好きな関数型言語を使って良いよ

>>634
>すでに誰かが作ったものってのは
>もしかしたら社内で作っていたかもしれないもの。

>で、それがオブジェクト指向で作られてるだろう？

>社内でやるか、社外でやるかの違いであって
>オブジェクト指向の開発であることに違いはないよ。

社外か社内かなんて初めからどうでもいい話だったのに
こんなレスがきたからズレてると感じた。
既に有るものをどう再利用するかが問題なんだが
その事が解らなかったように見えた。

filter という物自体が
すでにオブジェクトなんだが・・・。

>>635
非常に興味が有る。オブジェクト指向でケーキを作ってくれ。

>>640
じゃあ、代わりにケーキの作り方を
関数型言語とオブジェクト指向の両方で
書いてみてくれ。

ま、一般論で言えば
材料（オブジェクト）があって
その中に作業（関数）ができるだろうね。
あとは頑張って。

そもそもアウトプットのケーキとはどういうものなんだ？
プログラム自体はケーキ製造機を制御してケーキを作るってことか？
それとも論理ケーキをメモリ空間上に生成するのか？
例えば舐める操作をすると、甘いが返ってくるとか。

ケーキ製造機.makeCake() とかでいいんじゃね？
パラメータは材料とかケーキのプロパティは色とか形とか。

>>642
それで答えたつもり？
馬鹿馬鹿しいケーキの例え話と違って
>>640は実際にプログラム書ける話だよ？

ま、そうやって誤摩化す時点でお前が
関数型言語を使えないのは良く分かったよ
オブジェクト指向言語が使えるかも怪しいけどw

ケーキ製造機は
ホール製造機とか
クリームコーディング機とか
イチゴ載せ機を内包しているとか？

木に対するフィルターってなんぞ？

>>649
内蔵してるってのはOOとしてあんまりよくないだろ。
構造的に集約しておくべきだ。

>>650
そんなのはどうでもいい。
フィルタと言ってるんだから
一般的にはデコレータパターンだろう。

>>651
お前がオブジェクト指向を知らんってことはよく分かったｗ
内蔵じゃなくて内包だ。

木に対するfilterか・・・
これだけの情報だと
擬似関数型言語で書いたとして

filter(木)

ぐらいしか書き用がないよな。

木に対するフィルタって

> (func '1+ '(1 2 (10 11) 3))
(2 3 (11 12) 4)

みたいなやつかと思った

>>653
用語なんてどうでもいいじゃん。実際どうなってんのかがもんだいでしょ。
オブジェクトを深く内蔵しすぎるとオブジェクトレベルでの交換が効かない。
オブジェクトの集約してるオブジェクトを差し替えることでより
振る舞いを変えられる方がオブジェクトらしい。

オブジェクト指向・・・設計
関数・・・実装コード

やっぱりこういう感じだよな。
関数型言語における設計の話を聞きたいのに、
実装コードの話しかでてこない。なんで？

>>654
擬似じゃなく本物でかけよ。

関数型言語でfilterと言えばリストなどに使うfilter関数でしょ
本当に関数型言語使ってたらピンと来るはず

>>655
それは木に対するmapだね

>>657
演算子や制御構文を使わず関数だけでプログラムを書くのが関数言語で
それ以上のものじゃないから。ときたい数式とかあるなら、そのまま関数に落とせばいいし、
処理したい事象があるならなんとか関数に落とせばいい。
設計もクソもない。

> 設計もクソもない。

やっぱり関数型言語は設計がないんだ。

>>659
効果じゃなく濾しとる処理か。

>>657
え？関数型言語を使えもしないのに
使えると嘯いてるアホをいぶり出してるだけでしょ？

>>660
だよねえ
もし木に対するfilterがどういうものか知ってたら呼びだし例書いてみて

何言ってんだ。

ケーキとか木とか作ってどうすんだよ。

俺らは目的の機能が欲しいだけなのに。

何でケーキ作ることが目的みたくなってるの？

>>661
やっぱり関数型言語は考え方がミクロなんだよね。
処理したい事象とか、そんな小さなものじゃなくて
作り上げるシステム全体のコンポーネントを
どう組み合わせるかというマクロな視点は
関数型にはないのかい？

> 俺らは目的の機能が欲しいだけなのに。
ほしいのは機能じゃなくて
機能とデータの集合体とその変化を
どうシステム化するかじゃないのか？

ま、単純な関数がほしいってだけのこともあるだろうけどさ。

>>667
そりゃ思想というより関数型な道具だもの。
感覚としちゃCOBOLよりCのコードの方が見やすいわ〜ぐらいの話だし。

オブジェクト指向と関数型言語は
戦略と戦術みたいなもんかね？

オブジェクト指向という大きな戦略があって
その中で使う戦術に関数型言語を使う。みたいな。

>>668
ネタ？何言ってるのかわかんねーよ。
最終的なアウトプットとして欲しいのは、要求仕様を満たした機能、に決まってるだろ。

>>670
戦術よりまだ小さい
アサルトライフルつかうかサブマシンガン
つかうか程度の道具を選ぶ話

>>671
アウトプットとして欲しいのは要求仕様を満たした ”システム” だろｗ

機能が顧客の要求になることはまず無いよ。

>>673
システムってなんよ。
機能っつうと y = f( x ) でのfに当たるものだけど。

>>673
もう勘弁してくれ。
システムは、目的機能を実現するための手段だろーが。
なんでシステムが先に出てくるんだよ。
目的の機能を実現するために、さて、どういったシステムを組もうか、ってのが普通の思考回路だろ。
これだからOO脳は困る。

>>674
システムっていうのはブログとかだよ。

ブログというシステムには一覧表示機能があって
投稿機能があってカレンダー機能があって。

その個々のコンポーネントをどう組み合わせて
作り上げるかという設計の話。

関数型言語だと、そこらへん全部終わっていることが
前提で、その後の関数をどう実装するかの話になってるでしょ。

だから設計どうすんの？って聞いてる。

> 目的の機能を実現するために、さて、どういったシステムを組もうか、ってのが普通の思考回路だろ。
機能っつうと y = f( x ) でのfに当たるものだけど。

機能を作るためにシステムを作るとかさっぱり意味がわからん。

>>676
システムの定義を聞いてるんだけど。
自己循環系の体系でどうのとかそういう話。

”システム”という言葉の感覚もわからんのかな？

まあ仕方ないか。

学生さんにとって、課題とは○○をする関数を作れという
問題であって、それが必要になった理由までは考えなくていいからね。

システムシステムと軽々しくいうヤツは多いが
どれはシステムでどれはシステムじゃないか
はっきりいえるヤツは多くない

>>679
「システム開発 事例」

で調べてたくさん出てくるものだよ

ググって出てきたものの中から
君が気に入ったシステム開発の事例持っておいで。

>>680
感覚でしか使えん言葉だったら明確な
意味を持つ言葉である機能の方がましだろ

>機能を作るためにシステムを作るとかさっぱり意味がわからん。

ご冗談を。生きるために飯食う、ぐらい簡単な道理だぞ。

>>682
あれはなんとなく付けてるだけでシステムの定義無視してるだろ

>>684
システム設計と機能設計
どちらを先にやるかわかる？

>>685
たくさん出てくるものが無視してる？

今話してるのは、たくさん出てくる一般的な意味の
システムの話をしてるんだが？

システムを作って欲しい、システム開発して欲しい、って意味わからんじゃん。
普通は「〜をする」システムを作って欲しいと言われるはず。
だったら、その「〜をする」ってのが最終目的だし、顧客が欲しい最終的な機能だ。

> 普通は「〜をする」システムを作って欲しいと言われるはず。

お前の文章、
システムを作って欲しいといっているだけで
機能を作ってくれとは言ってないないじゃんｗ

たとえば「テレビ番組を録画するシステム」を作ってくれと言われる。
そしてテレビ番組を録画するシステムには
時間になったら起動する機能とか
記憶デバイスを操作する機能とかが含まれている。

システム ＞ 機能

>>686
残念だけど、「顧客の要求仕様」が、一番大きな括りでの機能設計そのものなんだよ。

>>687
具体的な意味が無いんだからしかたない
システム屋って看板にかいたり〜システムって売れば営業として顧客に
アピールできるから言ってるだけ

国外でSystemというと、Operation Systemといった体系に使い
WindowsやLinuxの様に具体的な実装をLinux Systemとか言ったりしない
国内だと実装その物を〜Systemと言って売ったりするが
学問的な意味からすると狂ってる

>>690
うん。でもまあそれは大雑把すぎて、
システムの下にサブシステムがきてサブのサブシステムがきて
最終的に機能（関数）になるだろうけどね。

>>690
だからその「テレビ番組を録画するシステム」は、
テレビ番組を録画する機能を満たした一実装ってことだろ。
頭わるいな。

WindowsというOperation Systemには
いろんな機能が含まれます。

あってるよね？

>>694
重要なのは、そのテレビ番組を録画するシステムを
表現するのに、オブジェクト指向なら
時間になったら（略）というコンポーネントなり
オブジェクトなりといった設計をするわけだよ。

>>665
こんな感じ

> filter (< 2) [0, [1, 2], [3]]
[0, [1]]

>>697
話がミクロすぎだｗ

オブジェクト指向＝物理(Simlula)
関数型＝数学(Haskell)
おれはSimulaのほうがいい

機能と違ってシステムは人間を使えばいい。
決まった時間に録画予約する人間を雇い
安定的に管理すればこれで録画システムが完成する。

>>698
>>638>>664

結局関数型言語の話といえば、機能の実装の話ばかりで
それをどう組み合わせるかの話には一向にならないんだよね。

オブジェクト指向では、機能の組み合わせ型の話が主になる。
この点を戦略と戦術と表現したのさ。

あっそ

>>695
自分で、「Operating」 System　って言ってるとおり、
コンピュータのオペレーション機能のためのシステム。

>>696
自分で言ってる通り、
目的の機能を持ったコンポーネントなりシステムなりを開発したり使ったりするわけでしょ。
機能 > システム ってことにならないか？

>>702
お前さんが関数型言語は使えないってことは良く分かったよ

>>705
反論できなくなったかｗ

関数型の詳細設計ってフロチャートでかける？

>>705
俺は、彼はむしろOOPを上手く使えてないように思うんだが。OOの毒にやられているというか。

物理が解析的に研究されるようになって確かに発達したけど
量子力学とか誰もイメージしなくなったよね。
計算物理では状態の時間発展としてイメージ可能にする。

時間発展ルールにしか焦点を当てない関数型より
状態とその発展を表現できるオブジェクト指向のほうが好き。

>>706
えー、反論も糞も
自称「関数型言語が使えるOOP使い」君は
関数型言語の基本中の基本filterすら
満足に書けないって事実が露呈しただけだよ

君がこれに反論する方法はただ一つ、コードを書いてみせるだけ

彼が長々とスレに書き込んだ量の
1/5以下の長さでfilterは書けるから
そんなにタイピングの負担は無いはずなんだけどな

>>709
それは、手続き型ってだけで、OOPとはまったく関係ないんだよ。
関数型を扱き下ろすには十分なのかもしれないが、
OOPを擁護したことにはならない。だって、それはC言語でも十分だろ。

>>709
関数型は状態を持つぞ引数として
見た目が関数の引数なだけだ

( new-state '( name (+ age 1) ) )

>>712
それにLazy Kじゃあるまいし、普通の関数型言語は
状態を表すデータ型くらい定義できるしな
>>709は妄想で語ってるから批判の焦点がズレてる

>>711
ほんとやんなっちゃうよね
filterすら書けないのに関数型言語について語るなんてどうかしてるよまったく

ELISP> (defun my-filter (fun tree)
         (if (null tree) nil
           (if (listp (car tree))
               (cons (my-filter fun (car tree))
                     (my-filter fun (cdr tree)))
             (if (fun (car tree)) (cdr tree)
               (my-filter (cdr tree))))))
my-filter
ELISP> (my-filter (lambda f (n) (> n 1)) '(1 (10 20) 2))
*** Eval error ***  Symbol's function definition is void: fun


さて寝るか

>>713
それが圧倒的に不自然なんだよ

>>714
都合のいいときだけ非純粋型を持ってくるねｗ

>>717
Haskellでも出来るぞ

>>718
できると扱いやすいは別ですが

関数型は結局副作用の有り無しにしかメリットないのに何で過大評価されるのかね

GUIやOSがインタラクティブ性を前提とする以上関数型は主役になりえないのに

そもそもデータ型を定義できることと
純粋・非純粋は全く関係が無い
むしろ>>717が>>714を読んで非純粋型を連想した理由を聞きたい

>>720
関数型が人間の思考回路に近いから。数学をみても分かるとおりね。
ただ、コンピュータ的には副作用ありきな手続き型の方がネイティブだから、
コンピュータ言語となれば関数型よりも手続き型の方が自然に感じたりもする。
でも、無味乾燥な手続き型言語よりも、人間の思考形態により近い関数型言語によりロマンを感じる。
車で言えば、オートマ=関数型、マニュアル=手続き型　って感じ。

>>722
状態を表す

偏微分表記の波動方程式と
メッシュ状の状態の差分方程式じゃどっちが分りやすいか

>>720
関数だけでプログラムを書けるから。
言語上如何にも機械的なループ構文も分岐構文も存在しない。
存在する制御はただ関数を呼び出すだけ。
コンピューターの実装から極度に抽象化され
言語上はコンピューターを意識する必要は無い。

>>724
破壊的代入が無くても状態は表せるよな

>>726
抽象化するメリットがない。
ループを再帰にする必然性がない。
直観性を喪失させているだけ。

>>727
モナドで？
なんのためにわざわざ？

x_n+1 = f(x_n)

これを表すのに iterate f x0 は直感的

>>728
反復も分岐も数学からみれば直感的じゃない
数学でしょっちゅう分岐だの反復だの見るか？
Σや∫といった関数で表現できる。
数式上制御構文はノイズ。

>>729
何度も出てるが引数で

引数は先送りしてるだけでややこしくしてるだけなのに

理系出身じゃないヤツには無用な長物
数学に馴染みの無いヤツは好きな言語使えばええ

数学から見ることじたいが直感的じゃない

つか数学科落ちこぼれのオナニー言語

コンピュータ自体、数学上のある仮説検証のために作られたもんだからな。
今の利用法は可能性のごく一部でしか無い。

線形代数より鶴亀算の方が直感的と言われてもなぁ、って感じ

だれがそんなこといったの？

>>662
いや、無くはないと思う。
決めておかなければコード化できない「ことがら」が消えるというか減る感じはある。

オブジェクト指向で
鶴と亀がメッセージングして
足の数を求めるの想像して笑た

あとコンポーネントってことばはホント良くないな。
システムレベルの構成要素はもっと大きいグレインとなるのではないかな。
しかもシステムをコンポーネントに細分化って、問題を解く関数を細分化…にアナロジーだし。
両方使いこなした上でこそ身をもってわかる善し悪しの意見を述べるのがよい。
わからないこと知らないことは知らないと言う方が潔い。

でもまあJavaのようなｵﾌﾞｼﾞｪｸﾄ指向は開発してて退屈するが、ﾌｧﾝｸｼｮﾅﾙは面白くて熱中してしまう
これは実感だぜ。知恵使うからｶﾅ？

つくりたいものがないからじゃね？

( defun subample ( a b c ) ( if (< 0 c ) ( example b c ) a ) )
( defun example ( a b ) ( subample a b ( mod a b ) ) )
単なるGCMの計算でも見通しがいい

( defun gcm ( a b ) ( if (< 0 ( mod a b ) ) (gcm b ( mod a b ) ) a ) )

>>742
コンポーネントっつーか、OO用語で言うところのクラスだな。
データ構造の切れ目と制御や関数の切れ目が必ず一致する訳ではないからなぁ。
そういった場合、OOPではデータ構造を優先して制御をぶった切って、
接着は多態で誤魔化すのが主流だけど、
あまり小さい粒度でそれやられると、ねぇ。
大きい粒度でOOするんなら、特別、言語のサポートが必要とも感じんし、
結局C言語withC++テンプレートで良いような。
C言語はノイマン型コンピュータのネイティブとも言えるような言語だし、
人間が機械に合わせる必要性があるとはいえ、不思議と変なストレスはナイノヨネー。

さすがに見識無さ杉

>>747
小さいグレインをクラス切ってgetter,setterもうけて継承で絡めるｵﾌﾞｼﾞｪｸﾄ指向ってしばしば害あると思う、同意。
ｿﾌﾄｳｪｱは封雑になると単純な入れ子の木構造では表現できないｸﾞﾗﾌのような構成になることが多いから
下位の小グレインは多少共有できる余地があっても細かく関連付けず、具体的なｺｰﾄﾞを展開して書いた方が
依存を減らせてよろしいことも多いと思う。
逆に、ある程度大きいグレインでの中上位機能のモジュラリティーのためのｵﾌﾞｼﾞｪｸﾄ思考は有益な場合も多いと思う。

Ｃについては癖のなさ、コンピュータの上で直接稼働するプログラムとしての表現の素直さ、
あとポピュラーで目が慣れているってこともあるんじゃないかな。

漢は黙ってコード比較

テキストファイル読み込んで、行番号つけて表示せよ

import System
import Control.Monad

numbering = unlines . map (\(x,y) -> show x ++ y) . zip [1..] . lines
main = mapM_ (putStr . numbering <=< readFile) =<< getArgs

gawk


BEGIN {
    for(i = 1; i < ARGC; i++) {
        for(n = 1; (getline x < ARGV[i]) > 0; n++) {
            print n, x
        }
    }
}

ruby -e 'ARGF.each_with_index{|e,i|print "#{i}: #{e}"}' < src

Pythonのenumerateとはi,eの順番が逆だということを学習した

gwakはじめて見たけど>>752が一番見やすい

>>753は複数ファイルを渡したときの挙動がアレだけど
短いし十分読みやすい

短いと読みやすいとかｗ

短い「から」読みやすいとは書いてないな

そして同じくらい読みやすいなら短いほうが良い

>>751
haskellはむしろdo表記の方が読みやすいんじゃ。。。

>>758
Haskellでもforの方が読みやすい？


import System
import Control.Monad

main = do
  argf <- mapM readFile =<< getArgs
  forM_ argf $ \f -> do
    forM_ (zip [1..] $ lines f) $ \(i,x) -> do
      putStrLn $ show i ++ x

そういう本音は議論に負けるから止めてください

ここまでJavaなし。

結局オブジェクト指向の方が
人間の考え方、物の認識という自然な行動に
近いんだよね。

一体今の流れのどこを見て>>762に至ったのか

このスレお題出して関数型とオブジェクト指向で書いていく方が楽しい

>>763
なんか間違ってた？

君の机の周りにあるものの名前を言ってみてよ。

>>765
いま比較されてるのは手続き型と関数型だろ

>>765
得意な言語で>>750書いてみて。

import java.io.*;

class ReadArgs {
    public static void main(String args[]) {
        try {
            for (String filename : args) {
                BufferedReader br = new BufferedReader(new InputStreamReader(new FileInputStream(filename), "UTF-8"));
                for (int i = 1; ; i++) {
                    String x = br.readLine();
                    if (x == null) break;
                    System.out.println(String.format("%d %s", i, x));
                }
            }
        } catch (Exception e) {
        }
    }
}

オブジェクト指向の特徴的なのは
、
今はファイルから読み込んだが、
そこに「ファイル読み込みオブジェクト」すなわち
FileInputStreamを使っているから
それを入れ替えることでファイル以外からも読み込めるだろう。

ということをごく自然に表現できている所。

Smalltalkのコードを観てみたい
これぞオブジェクト指向って感じのやつ

関数型とOOPっつーけど、さっきから出てる「反」関数型のコード、
OOの機能を有効活用してねーじゃん。
これじゃ「関数型vs手続き型」だよ。
OOらしく、多態やオーバーロード使って、
スマートに問題を解決して欲しいね。

>>769
でも実際はファイル以外から読み込むシチュエーションは訪れないんですよね、分かります。

> OOの機能を有効活用してねーじゃん。
え？ 問題がそうなってるだけだからでしょ。

問題が”関数を作りましょう”なら関数になるのは当たり前。
問題が小さすぎるの。

オブジェクト指向というのは、関数はできてることが前提といってもよく、
その関数の集まりをどう組み合わせていくかという
もっと上流のプロセスなんだから。

オブジェクト指向を活かせる問題であれば、そんな○○する関数ではなく、
例えばGUIシステムの設計みたいな問題にしてくれ。
丸い形のボタン、四角い形のボタン、押したら光るボタン、
ボタンという機能はそのまままで基本のボタンに何かを追加できる設計の場合
どのようにするか。みたいな。

もうOOPすらヤバイってのが良く分かる。
誰か相手してやれ。

で関数型言語だと、
ボタンをレンダリングする関数にshow()関数の配列を渡すんだけど、

show()関数は、別の関数、show(color)とか、show(shape)とか
そういう引数がある関数をカリー化して引数のないshow()関数を作る。

という設計をするのです。俺関数型のプロだからこの回答に自身あるよ。

>>774
誰も反論ないから、これ以上いうことがない。

>>774
ヤバイのがお前には見えるんだったら、
お前が相手してやれよｗ

>>773
それデコレータパターン？

>>778
正解。

オブジェクト指向の例といえば
有名なものの一つが、デザインパターンだけど、
そのデザインパターンでも紹介されている
OOの機能を有効活用した有名な例の一つ

オブジェクト指向を有効活用するってことはこういうことなんだから
こういう粒度の話になるのは当然なんだ。
○○する処理書けとか、まったくわかってないとしか思えないね。

まあ

「アセンブラで言うANDニーモニックを関数型言語で実装してみて」
↓
and文一個書く
↓
「それ、関数型言語の機能有効活用してないじゃん」

みたいに感じるよね。

問題が悪いとしか。

だからさー。
かなり探さなきゃ、OOPと関数型で共通の御題は見つからないって時点で
元々競合してないんだからさー。
関数型言語もOO言語も、最終的には適当な手続き型言語の一部として吸収されて、
それで終わり。

>>768
一行野郎で十分ちゃ十分なんだろうけど…

perl -nle 'print "$.:$_"' 入力ﾌｧｲﾙ

これだと複数ﾌｧｲﾙ指定した場合に、行番号が通しになっちまうから減点かｗ

>>782
うん。問題が小さすぎるからそうなるんだよね。

もう少し、ウェブアプリとかデスクトップアプリとかさ
普通に仕事で作ってる規模レベルで話すればいいのに。

>>781
関数型言語は手続き型言語の一部として吸収されるかもしれないが、
オブジェクト指向言語は競合してないなら吸収されないだろｗ

>>781
上で出ていた戦術と戦略の話ですね？

オブジェクト指向が戦略で、
戦術として、関数型言語や手続き型言語がある。

大きな開発なら戦略が重要だけど
小さな開発なら戦術だけでもどうにかなる。

>>750はそのままじゃツマラナイから
(1)行番号を付ける、
(2)改行記号の代わりにカンマで改行する、
(3)何もしない、
の三種類を「コマンドライン引数のファイル名を読み込んで、変換して表示する」
というメインのロジックを変更しないで
切り替えられるようにしようぜ

DecoratorパターンやStrategyパターンを使う余地あるだろ

>>784
ほとんどの手続き型言語はOOの機能を持つようになってきたし、
競合しない分、関数型よりも吸収が早いようですが。

>>785
また分けの分からん。戦略とか戦術とか。俺定義で用語つかって、したり顔されても困る。
なんとなく分かってもらえませんかねぇ？は止めてくれ。
そんな狂った思考は、こっちは分かりたくもないだから。
何でお前のデバッグをしなきゃいけないんだってはなしになる。

>>786
最初からそういう問題にしておかないとダメだよね。

でも三種類だけじゃなくて、それ以外の変更にも
耐えられるようにして、ソースコードを修正すること無く
切り替えられるようにしないいけないな。
コード書き換えて変更できます！じゃ意味ないからｗ

途端に関数型言語じゃ作りにくくなったｗ

>>787
話がくどい

> ほとんどの手続き型言語はOOの機能を持つようになってきたし
それ、オブジェクト指向言語に成長しただけだよ。

そういえば、関数型言語＋オブジェクト指向言語ってのもあるよね。

関数型言語で関数レベルの処理を書いて
オブジェクト指向部分で設計を行う。

>>788

convPrint f = mapM_ (putStr . f <=< readFile) =<< getArgs

>>792
行番号とカンマはどこいったんだい？

fに好きな処理書いてってことだね
なんていうか>>786と>>788でこのスレがどういう所か理解できたわ

>>786
ﾁｬﾁｬっと書いてもいいけれど、引数optionで出力ﾌｫｰﾏｯﾄ切り替えるのにﾊﾟﾀｰﾝ出すほどのものかという稀ｶﾞｽ。
そういうちょっとしたところで話が大仰になる点が「いま流行りの」OOにおいてｵﾚがいまいち好きになれない一面かな

単なる型スイッチで設計語るんだから困る。>OO信者

>>786

convPrint f = mapM_ (putStr . f <=< readFile) =<< getArgs

numbering = unlines . map (\(x,y) -> show x ++ y) . zip [1..] . lines

splitBy _ [] = []
splitBy p xs = a : (splitBy p $ drop 1 b) where (a, b) = break p xs

numberingPrint = convPrint numbering
splitCommaPrint = convPrint $ concat . splitBy (== ',')
normalPrint = id

例えばちょっとした言語処理系の一部くらいを書き比べてみりゃ特徴が出やすいんだろうけど
言語ごとの字句・構文解析ﾌﾚｰﾑワーク競争に陥りｶﾞﾁだしな…

訂正
normalPrint = convPrint id

ミス多いな

訂正
splitCommaPrint = convPrint $ unlines . splitBy (== ',')

これで分かったと思うけど、
少なくともこの規模じゃないと
オブジェクト指向の機能を有効活用することはできない。

さっきのは問題が小さいってことの意味がよくわかったでしょ？

OOPLでの実装が出てきてないのにそんなこといわれても

じゃあRubyでの実装でいいですか？

>>795
彼らは結合度を下げろ下げろって言うけど、二項以上の演算は相手あっての話だからなぁ。
結合度を下げたりカプセル化を進めることと、演算して処理をすることが、方法論として相反してるっていうか。
機能の切れ目とデータ構造の切れ目と処理の切れ目が丁度一致して、
クラスとしてスッポリ抜き取れるかといわれるとねぇ。上手く抜き取れた場合は単に運が良かったとしか。
C++のfriend指定とか見る度にお腹痛い。

>>803
どうぞどうぞ

> C++のfriend指定とか見る度にお腹痛い。

でもまあ、全部friendよりはマシでしょｗ

>>804
> 彼らは結合度を下げろ下げろって言うけど、二項以上の演算は相手あっての話だからなぁ。

なんかまだまだ理解してないって感じだね。

確かに二項以上の演算は相手が必要だが、その相手をインターフェースにすることによって
相手を自由に変えられるってことが、結合度を下げるってことなんだよ。

>>806
個人的にはソースファイル単位のカプセル化で十分だと思う。

>>808
ソースごとに機能を分けて作っておいて
friend的なことをしたくなったら、
同じソースファイルに入れるようにするってこと？

>>807
後半嫁

>>810
で？

読んだのなら文句はない

>>801
> 少なくともこの規模じゃないと
> オブジェクト指向の機能を有効活用することはできない。

んじゃまぁ、あしからず完全に手続き型にてちょっと書いてみたけれど…

use Getopt::Std;
my %opt = ();
getopts "nj", \%opt; # -n:行番号表示, -j:','で行を連結

for my $file (@ARGV) {
  open FILE, $file or die "Couldn't read open file `$file': $!\n";
  #for (<FILE>) { # forは最適化されて一気に読み込まれ、最終的な行番号が印字されてしまう
  while ($_ = <FILE>) {
    chomp;
    print "$.: " if $opt{n};
    print;
    print $opt{j} ? ',' : "\n";
  }
  close FILE;
}

このお題で、オブジェクト指向の機能を有効活用って…
申し訳ないが、おれには謎だよ。

>>813
おい、拡張性がないぞｗ

>>813
プラグインみたいな機構を持って
他の誰かが勝手に、オプションを追加できるような
仕組みを搭載しないと、条件を満たさないぞ。

え？なになに？仕様見落とし？

>>816
完全に仕様見落とし。

行番号やカンマってのはあくまで一例であって
それ以外にも対応できるような仕組みを作れというのが本題。

>>786
> の三種類を「コマンドライン引数のファイル名を読み込んで、変換して表示する」
> というメインのロジックを変更しないで
> 切り替えられるようにしようぜ

この要件か？optionで切り替えるっていみと違ったのか?

一文字追加するとは限らないし、
行を反転するかもしれないし、
行に対してどんな加工をするかは決まっていない。

>>818
>>788が続き

>>816
行に対する処理を関数にまとめてlinesにmapするとかでいいんじゃないか

>>821
どうやって、「現在行」を保持するつもり？

×どうやって「現在行」を保持するつもり？
○どうやって「現在行番号」を保持するつもり？

行に対する処理を関数にまとめるんじゃなくて、
オブジェクトにまとめてlinesにmapするとかでいいんじゃないか

オブジェクトの処理が呼び出されるごとに、
プライベート変数を+1していけば良い。

ﾁｮｯﾄ待て、下記の通りmapに渡すfilterﾌﾞﾛｯｸを変数化するとうまくうごかん

sub odai2(&) {
my $filter = shift;
for my $file (@ARGV) {
open FILE, $file or die "Couldn't read open file `$file': $!\n";
map {print $_} map $filter <FILE>;
close FILE;
}
}

use Getopt::Std;
my %opt = ();
getopts "nj", \%opt; # -n:行番号表示, -j:','で行を連結

if ($opt{n}) {
odai2 {"$.:$_"};
} elsif ($opt{j}) {
odai2 {chomp; ","};
} else {
odai2 {"$_"}
}

こんなｲﾒｰｼﾞになると思うが、なにか間違えている。動いたら又upする(汗

ここは東京駅から品川駅へ行くのにも新幹線に乗る人ばっかで困るね。

と自転車にラジカセを積んだおっさんがぼやいております

あんまりｴﾚｶﾞﾝﾄじゃないんだけれど関数のリファレンス切り替えでなんとかした。

sub odai2(&) {
  my $filter = shift;
  for my $file (@ARGV) {
    open FILE, $file or die "Couldn't read open file `$file': $!\n";
    while (my $line = <FILE>) {
      print $filter->($line);
    }
    close FILE;
  }
}

use Getopt::Std;
my %opt = ();
getopts "nj", \%opt; # -n:行番号表示, -j:','で行を連結

if ($opt{n}) {
  odai2 sub {"$.:$_[0]"};
} elsif ($opt{j}) {
  odai2 sub {chomp $_[0]; "$_[0],"};
} else {
  odai2 sub {$_[0]}
}

mapのコードblockを切り替えるかっちょいい方法はチョット勉強しとく

下の方はsub省いて

if ($opt{n}) {
  odai2 {"$.:$_[0]"};
} elsif ($opt{j}) {
  odai2 {chomp $_[0]; "$_[0],"};
} else {
  odai2 {$_[0]}
}

これでいいんだった。でも_[0]の記述が今一だな…まぁいいや。

>>759
読みづらい

>>768
OOらしくないし最高に汚いな
やってることが手続きとまるでかわらん

手厳しいな君らは…
ｵﾚみたいに恥をさらしてみれば？w
どうせ名無しなんだし

>>808
物理単位でカプセル化しても意味ないだろ
情報隠蔽じゃあるまいし
インターフェース(境界)で区切ってカプセル化しなきゃ

意味ないって言い切るから話が面倒なんだよ。
物理単位にオブジェクト分ければそれなりに意味あるとかいわれ始める。

>>834
どうやって物理単位にオブジェクト分けるんだ？

>>770
無理だよSmalltalkにはファイルなんて存在しないし
実行引数も存在しない
入出力は存在するが全てオブジェクト

>>835
COOLとか読んで来い

C-language's Object Oriented Languageの事か？

>>835
クラス分割の事でも言いたいんじゃねぇの？

しかし、厨ってのはそんなにプラグインみたいなことがしたい物なのかねぇ。
かなり大きな粒度で問題ないし、WinのCOMなんかみても分かるとおり、言語の支援も言うほど必要か？
単なる型スイッチ相当のものに良くそこまで期待できるよなぁ。

手続きにクラスを追加したOOPLが圧倒的シェアになったのは
粒度が小さいところでは手続きが有効だけど大きいところではOOが有効だから。
では関数型はどこにあたるのだろう。
ヒントはすでにあってC/C++は関数と呼ばれるものがある。そのスケール。
実際D言語でpureキーワードあるし。

Cの関数とは、呼び出しが似てるだけであとは全然違うぞ。
演算子、ループ文使った時点で関数型じゃなくなる。

今ある関数型に寄せようとするとboost::function。
やり杉って話です。

>>842
とトイプログラムしか書かないHaskellerが申しております。

手続き型言語からしたら、オブジェクトもパーツだよ。
実際、main関数の頭で、オブジェクトの初期化コード走らすんでしょ。パーツを作ってるわけよ。
だから一番大きな外枠は手続き型言語。

C++はOOを過信しすぎてこの辺の師弟関係を誤って、
「グローバルオブジェクトの初期化順が不定」っていう痛い仕様になってしまった。

歴史的に一番外側だけって証明されてるじゃん。
C++はCとの互換性を維持してるからグローバルオブジェクトという概念を許容してる。
整理したのがJava。

>>843
boost::functionは手続き型の領域だろ
関数型ならテンプレートだ

template<class left, class right> struct Cell;

template<class cell> struct Car;
template<class car, class cdr> struct Car< Cell< car, cdr > >
{
    typedef car Result;
};

template<class cell> struct Cdr;
template<class car, class cdr> struct Cdr< Cell< car, cdr > >
{
    typedef cdr Result;
};

でtemplateでプログラム奴がいないのはC++プログラマが馬鹿だからですか？

>>846
Smalltalkを始め大概のOOPLはグローバルオブジェクトを持ってる。
もってない方が異端。

Niceは今どうなってるんだろう

>>849
で？

>>846
大抵クラスはグローバルオブジェクト
グローバルオブジェクトであるクラスを操作できないってのは
整理したというより劣化してるだけ

>>852
は？意味不明。

>>851
>歴史的に一番外側だけって証明されてるじゃん。
大嘘

どうでもいいが>>786のOOPLのコードはまだ？
>>801が書いてくれるのを待ってるんだけど

>>854
Java

>>853
お前にゃ理解できんだろうなw

>>857
理解してるのお前だけだなｗ

>>856
batファイル、VBA、javascript,C以下の普及率言語がどうかしたか

>>859
反論にはなって無いね

>>860
Javaってレス自体が正銘になってねぇよ

>>861
Javaしらないの？static mainから起動してるでしょ。

>歴史的に一番外側だけって証明されてるじゃん。

そう思っても、実際には手続きでオブジェクトを操作しているのが実際なのよ。
典型的なOOPの構文が、オブジェクトありきな、あんな調子だから、勘違いしてしまうのは無理も無いが。
OOPといってもそれが手続き型言語なら、「手続き」がとても強い個性で、
逆にOOなんて、単なる型スイッチ用の構文だろ。人によっちゃ構文砂糖。
ノイマン型コンピュータが手続き的に動いているから、
どうしても手続きに関する性質は、時の流れのごとく強烈になる。

>>863
おまえが勘違いし続けてるだけだと思うけどｗ

アセンブラが強烈な個性でCなんて単なる構造化用の構文だろ
といってるように見えるｗ

典型的なOOPLであるJavaで出て来た唯一のコードが
>>768の時点で殆ど手続き型と言われても仕方ないよね

Javascript:
var type = Type;
var object = new type();

Ruby:
type = Type
object = type.new

Python:
type = Type
object = type()

Squeak:
|type. object|
type := Type.
object := type new.

>>866
おまえ手続き型の拡大解釈してるよｗ

>>862
そんな言語C#、Java、VB.netしかねぇじゃねぇか

>>868
じゃイテレーターなり使えよ

>>869
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
しかないって便利な言葉だなｗ

>>867
動的型ならほとんどグローバルオブジェクトだなw

>>870
おまえが何を憎んでるかはわかった気がするけどそれお前の中のOOPだからｗ

ヒープに乗っけるものをグローバルオブジェクトという珍説ｗ

>>871
batファイルやVBAがはいっとらん時点であてにならんわ

>>875
そこをプログラミング言語と呼んでる層は相手にして無いんだろうなｗ

>>871
Source Forge の上位アクティブプロジェクト集計した方がまだ信憑せいがあるわw

>>874
スタックだろ。

つかスタック変数で束縛すりゃグローバル変数で無くなるのか
int *value = &::value;
こう書いてば、グローバル変数使ってませーんって言い張れる理由だ
便利だなぁ

Strategyﾊﾟﾀｰﾝで書くとこんな感じかね…
package FilterCat;

sub new {bless $_[0], __PACKAGE__};

sub file_read_filter_print {
  my ($this, $file) = @_;
  open FILE, $file or die "Couldn't read open file `$file': $!\n";
  while (my $line = <FILE>) { print $this->($line); }
  close FILE;
}
1;

package main;

use Getopt::Std;
my %opt = ();
getopts "nj", \%opt; # -n:行番号表示, -j:','で行を連結

my $filter;
if ($opt{n}) {
  $filter = sub {"$.:$_[0]"}
} elsif ($opt{j}) {
  $filter = sub {chomp $_[0]; "$_[0],"}
} else {
  $filter = sub {$_[0]}
}

my $obj = FilterCat::new($filter);
for my $file (@ARGV) {
  $obj->file_read_filter_print($file);
}

>>878
それで反論した気になっているのが間違っている。
・初期化の順番は自前に生成順番書くようにすれば問題が無くなる
・変数にスコープがあればあらゆるところからのアクセスはできなくなる
主張の論拠としては十分
その例では::valueがそれを満たしてない。

つか、なんでこの程度のものにStrategyﾊﾟﾀｰﾝとか大仰な名前付けるやら…

バッチファイルはプログラム作るなら半ば必須技能だからなぁ
実際Windowsでプログラム作ってるヤツの8割ぐらいは使ってるはずだよな

バッチだけでアプリケーション作ってる奴が８割ならその主張に意味あるけどなｗ

>>880 何が言いたいのか解らん

>>884
え？まじで？
おれもおまえがなんでわからないかわからんｗ

>>883
ダブルクリックして起動すれば自動でコンパイルしてくれる
バッチファイルアプリケーション作ってるやつはいっぱいいるだろうなw

>>886
で？

ﾌﾟﾛﾊﾟﾃｨｰﾍﾞｰｽならではのｲﾝﾁｷDecoderﾊﾟﾀｰﾝです;-)ﾆﾔﾆﾔ
package FilterCatSkt;

sub new { bless {}, shift }

1;

package main;

use Getopt::Std;
my %opt = ();
getopts "nj", \%opt; # -n:行番号表示, -j:','で行を連結

my $filter;
if ($opt{n}) {
  $filter = sub {"$.:$_[0]"} }
elsif ($opt{j}) {
  $filter = sub {chomp $_[0]; "$_[0],"} }
else {
  $filter = sub {$_[0]} }

my $obj = new FilterCatSkt;
$obj->{func} = sub {
  my ($file, $filter) = @_;
  open FILE, $file or die "Couldn't read open file `$file': $!\n";
  while (my $line = <FILE>) { print $filter->($line); }
  close FILE;
};
for my $file (@ARGV) {
  $obj->{func}->($file, $filter);
}

>>880
おれもお前がグローバルオブジェクトとグローバル変数の初期化を混同させてて
何が言いたいのかわからんわ

>>889
なろほど。
グローバル変数の初期化が>>845ででてるから
グローバルオブジェクトの問題と絡めてる。
これはいい？

>>874
ヒープに乗っててもグローバルオブジェクトはグローバルオブジェクトじゃないか？
全スコープからアクセスできりゃグローバルオブジェクトだろ

>>887
バッチだけでアプリケーション作ってる奴が８割ぐらいいるだろうなって話

>>892
そんなアメリカンジョークわからんわｗ
でも１割いないと思うぞそれｗ

>>888
このスレは口ばっかりでコード書けないヤカラばかりだから
無駄ですよ？
実際に動くコードはPerlしか出てこないという...
関数型もオブジェクト指向もどっちも終わってる

(´･ω･`)ｼｮﾎﾞｰﾝ

んじゃ、最後に継承を使って派生ｸﾗｽにて適用するfilter関数を差し替えるのを…

package FilterCatBase;
sub new {
  my ($class, $file) = @_;
  bless \$file, $class
}
sub _filter {$_[1]} # ﾃﾞﾌｫのfilter:ｽﾙｰして流す
sub file_print {
  my $this = shift;
  open FILE, $$this or die "Couldn't read open file `$$this': $!\n";
  while (my $line = <FILE>) {
    print $this->_filter($line);
  }
  close FILE;
}
1;

package FilterCatLineNum;
use base qw(FilterCatBase);
sub _filter { "$.:$_[1]" } # ←ここを好きなfilterに書き換えた派生ｸﾗｽを増設すればおｋ
1;

package main;

for my $file (@ARGV) {
  my $obj = new FilterCatLineNum($file);
  $obj->file_print;
}

↓ﾊｹﾞばっか！

さっきの行ごとのフィルタ？だけどさ、

まず本体で行をグルグル回すでしょ？
で、フィルタ側で処理をするでしょ？

いわば、awkと一緒なわけだけど、
awkにあるよね。BEGINとEND

これと同じ物をさ、オブジェクト指向なら
class Filter {
begin(){...}
filter(){...}
end() {...}
}
って感じで作って、適用させるじゃない？
関数型言語だったら、beginとfilterとendを別々に分離しなきゃいけないの？

import System
import System.Console.GetOpt
import Control.Monad

convPrint f = mapM_ (putStr . f <=< readFile)
numbering = unlines . map (\(x,y) -> show x ++ y) . zip [1..] . lines
splitBy _ [] = []
splitBy p xs = a : (splitBy p $ drop 1 b) where (a, b) = break p xs
splitByComma = unlines . splitBy (== ',') . concat . lines

data Mode = Numbering | SplitByComma

options = [ Option ['n'] ["numbering"] (NoArg Numbering) ""
          , Option ['s'] ["splitByComma"] (NoArg SplitByComma) ""]
main = do
  args <- getArgs
  case getOpt RequireOrder options args of
       (opts, fs, []) -> print (foldl (\_ x -> Just x) Nothing opts) fs
       (_, _, errs) -> error $ concat errs ++ usageInfo header options
  where
    print (Just Numbering) = convPrint numbering
    print (Just SplitByComma) = convPrint splitByComma
    print Nothing = convPrint id
    header = "Usage: program [OPTION...]"

>>897
> まず本体で行をグルグル回すでしょ？

本体で行をグルグル回さなかった

>>899
トンチやってるんじゃないよ。

とりあえず750をC++で。
その1

template<class Functor> class LineConvertor
{
　　Functor　format;
public:
　　LineConvertor( Functor format ):
　　　　format( format ){}
　　void opeartor( std::string &file_name ) const
　　{
　　　　std::ifstream in( file_name, std::io::in );
　　　　for( std::string line; std::getline( in, line ) ; ) format( std::getline( line ) );
　　}
};

class SimpleFormat
{
　　int count;
　　std::ostream *out;
public:
　　SimpleFormat( std::ostream *out ):
　　　　count( 0 ),
　　　　out( out ){}
　　void operator( const std::string &line )
　　{
　　　　*out << ( ++count ) << ":" << line << std::endl;
　　}
};

その2
int main( int argc, const char *argv )
{
　　SimpleFormat ormat( &std::cin );
　　--argc;
　　++argv;
　　std::for_each( argv, argv + argc, LineConvertor<SimpleFormat&>( format ) );
　　return 0;
}

オブジェクト指向の、
「複数のメソッドをひとかたまりにして扱える」
という性質は便利だよね。

>>903
ボトルネックで便利じゃねぇよ。
便利だと思うならC++にマルチディスパッチ導入しようとか
Pythonにマルチディスパッチライブラリ導入とかそんな話でてこないだろ

おれは
・オブジェクトという概念を明示する
という性質が気に入ってる。
次にOOPLでは大抵ついてくるカプセル化かな。

>>900
事実だからしょうがない

結局オブジェクト指向のコンセプトはSimulaで出てるんだよな。
そこを自分の手柄にしようといろんな解釈持ち出してる連中がうざい。

>>904
ボトルネック？
なにが？
マルチディスパッチは全く関係ない話だけど？

>>908
じゃ「複数のメソッドをひとかたまりにして扱える」ってどういう意味だよ

>>906
普通本体側でループを回すだろ。
入力がネットワークからだったりしたらどうするんだ？

すべてのフィルタにネットワーク処理でもさせるのか？
それとも全部データ読み終わらないと
フィルタ処理開始できないのか？

>>909
awkの例みたいに、
フィルタオブジェクトが
begin、filter、endメソッドを持っているということ。

一つの”物”に複数の関数やデータをまとめられること。

>>910
遅延ストリームも知らんのか

さぁ知ったか合戦が始まりましたｗ

>>911
じゃマルチディスパッチで成立しなくなるのは有ってるじゃねぇか。

Message( object1, object2, object3 ); // awkとは全然違う

>>912
ない場合はどうするんだ？

awkじゃなかった awkの例とは全然違う だった

>>915
関数型言語にはあるよ

>>914
だから関係ない話だろ。
頭悪いな。

さぁ遅延ストリームがない言語は関数型言語ではないという新しい言及が出ましたｗ

>>917
ない場合の話をしてる。
ストリーム以外だとどうなる

>>911
持つ必要なくね？

'( 事前処理 間の処理 終了処理 ) ってリストに関数入れりゃいいだけだし

お互い分からない単語は分かってて関係ないから無視してるんだという振りをしています

遅延ストリームって遅いから嫌いなんだよね。
ま、パフォーマンスを求めないのが関数型言語使う上での
トレードオフなんだけどさ。

>>921
これは関数型堅固の本質を突いてると思う
だからおれは関数型よりOOのほうが包括的であるべきだと思う