一部には関数型言語を崇拝している人もいます
どちらが上なのか、この際はっきりさせましょう
前スレ http://toro.2ch.net/test/read.cgi/tech/1331328955/
http://toro.2ch.net/test/read.cgi/tech/1333801632/
> それならそれでFILTERでも変更できるインターフェースを付け加えればいいだけ。
そういう変更/拡張のし易さも議論の対象
ちゃんと変更したコードを提出しないと比較にならない
負け惜しみじゃないんだろ？
本来はフィルタでやることではないよ。
それわかってる？
class Filter {
private i = 0;
private m = 0;
begin(awk) {awk.RS=';'}
filter(line) {i++; m = max(m, line.length()); }
end() {print "最大文字数は"+m+"文字でした"}
}
こんな感じだろうｗ
いいから「改行コードを変更する拡張をする」に対して
OOPでやるとどれくらい簡潔になるか、コードを出せって
疑似コードじゃなくて動くヤツな
こんな感じかな。まあこの例ならsetuupでやればいいことだけど。
class Filter {
private i = 0;
private m = 0;
private awk;
setup(awk) {this.awk = awk}
begin() {awk.RS=':'}
filter(line) {i++; m = max(m, line.length()); }
end() {print "最大文字数は"+m+"文字でした"}
teardown() {this.awk = null}
}
肝心の部分はどうしたんですか？
どうやってセパレートしたんですか？
そうやって誤摩化すってことは、関数型言語で一瞬で書けるコードが
OOPでは難しいってことですね？
OOPでやると簡潔になるんじゃなくて、
変更の範囲を極小化出来るんだよ。
該当のフィルタだけの修正で、
それ以外の場所は何も変えないで変更できる。
使えないな
え？ 行フィルタなのに、ファイル全体をセパレートするのはおかしいでしょ？
ここにないのは、ここにあるべきじゃないコードだからだよ。
「標準入力から文字列を読み込んで、カンマ区切りで改行して、
各行の文字数を数えて最大文字数を標準出力に表示せよ」
これを書いて
ファビョってきたなｗ
全部関数なんかでやろうとするから
設計ができないんだ。
それ問題が不適切。
「標準入力」から文字列を読み込んで、「カンマ区切りで改行」して、
「各行の文字数を数えて最大文字数」を「標準出力」に表示せよ
ただし、カッコの中は一例であり
容易に変更できる設計にしておくこと
各行に対して□を処理をして、その結果を☆に表示せよ
抽象化するとこんな感じか。
ｵﾚ何度も書いたし、もういいや今日は。
そのリーダーインターフェースを実装した、
標準出力リーダークラスを作る。
行セパレータインターフェースが必要
その行セパレータインターフェースの実装として、
\r\nセパレータを作る
その後フィルタインタフェースが必要で
そのフィルタインタフェース（begin、filter、end）を実装した、
「各行の文字数を数えて最大文字数」はfilterで文字数を数えて
endで結果を出力する。
あとは、同様にライタインターフェースを実装した
標準出力ライタクラス。
とかそんくらいの成果聞いてみたいもんだわ
こんな感じになるわけ。
例外が悪いという意味がわかったかな？
オブジェクト指向は様々な実装を書くための仕組みを
提供するもの、つまり設計の部分なので
やることの対象が違うんだよ。
オブジェクト指向で枠組み設計を行い
関数型言語でその枠組みの中身を書く
広範囲な部分、処理の連携部分を記述する言語ってことなだけでしょ。
> オブジェクト指向で枠組み設計を行い
> 関数型言語でその枠組みの中身を書く
こんな感じ？
{-# LANGUAGE RecordWildCards #-}
import System
import Control.Monad
data Filter a b = Filter { begin :: a, body :: a -> String -> b, end :: b -> IO () }
awkLike Filter{..} = end . body begin
countFilter = Filter {
begin = Nothing,
body = \_ -> maximum . map length . lines,
end = \p -> putStrLn $ "最大文字数は" ++ show p ++ "文字でした"}
splitBy _ [] = []
splitBy p xs = a : (splitBy p $ drop 1 b) where (a, b) = break p xs
countFilterSplitBy sep filepath = countFilter {
body = \_ -> maximum . map length . splitBy (== sep),
end = \p -> writeFile filepath $ "最大文字数は" ++ show p ++ "文字でした"
}
main' = awkLike countFilter =<< getContents -- 例1: 標準入出力使用、普通にカウント
main = mapM_ (awkLike (countFilterSplitBy ',' "test.txt") <=< readFile) =<< getArgs -- 改行コードを変えて入出力先も変更
おー、なかなか。ﾊﾟﾁﾊﾟﾁ
ソースにパッチを当てて変更するのは容易ではないの？
パッチが容易ではないというのは、もしかして
「CUIは容易ではない」「GUIは容易」みたいな思想と関係あるのか
ソースにパッチ当てるといってもいろんな意味がある。
インターフェースを変更するようなソースの修正は容易ではない。
影響があちこちに波及するからだ。
関数型が使えそうなところには関数型の機能を使う。
両方使えそうにないところは普通の手続き型の格好に。たったそれだけのことだろ？
「関数型 vs オブジェクト指向」 からは、「if文 vs for文」並みのナンセンスさを感じるね。
OOも関数型も単なる一機能なんだから、状況に合わせて 使う/使わない すればよいじゃない。
「関数型 vs オブジェクト指向」ならその通りなんだけど、
ここは「関数型言語 vs オブジェクト指向言語」なんだわ
パッチの意味は追加と削除の二種類しかない。
マクロな視点でいうと、最新版を出す影響と古い安定版を切り捨てる影響の二つ。
現に大きな影響が出ているが、
関数型とオブジェクト指向の人間はこの問題についてなにも言ってない。
なぜなら、古い仕様が優遇されてしまうと手続き型が圧倒的に有利だから。
具体的に言って下さい。
functional (programming)
・ソースコード自体を書き換える方法
・ソースコードはそのままに静的に書き換える方法（マクロ、テンプレート）
・ソースコードはそのままに実行時に書き換える方法（モンキーパッチ）
などがあるのですが
文字列自体を操作する方法と、文字列に代わるものを操作する方法があるよね
個人的に、関数型言語は「型指向」だと思う
どう言う型受け取って、どう言う型を変えしたいのか考えると、自然と答えが出て来る
それらの区別はたいして何も変わらんｗ
納期に迫られ、ろくに設計できる環境も、人材も無い現場では関数型言語の方が向いてると思うんだが・・・
checkPermu ns = and.concat $ check ns
where
check [] = [[]]
check (x:xs) = map (x/=) xs : check xs
allPattern 0 _ = [[]]
allPattern _ [] = [[]]
allPattern n (ns:nss) = [x:xs | x <- ns, xs <- allPattern (n-1) nss]
-- 普通に作ったpermutations(使用例：permutations [1..3])
permutations ns = permutations' (length ns) ns
where
permutations' 0 _ = [[]]
permutations' _ [] = [[]]
permutations' n ns = [x:xs | x <- ns, xs <- permutations' (n-1) ns, checkPermu (x:xs)]
-- 汎用的なallPatternを作って、それに差し替えたpermutations
permutations2 ns= filter checkPermu $ allPattern (length ns) (replicate (length ns) ns)
-- allPatternを使った拡張版permutations(使用例：permutationsEx 3 [[1..3],[1..3],[1..3]])
permutationsEx n ns= filter checkPermu $ allPattern n ns
全然違うだろアホか
節子、動的・動的…
やっぱOOPはだわ……
俺は
「設計を意識しないとそもそも書けない」のが関数型言語で
手続き型言語やOOPLはメチャクチャな設計でも書けるor書けてしまうが
ちゃんと意識すると関数型言語にも通ずるようなコードが出来上がる
…と感じる
設計・・・オブジェクト指向
実装・・・関数型言語
って感じるな。
OOだって実装の道具にすぎん。ハンマーやカンナの類だ。
OOにはOOA（分析）やOOD（設計）があって
開発プロセス全体をカバーするものなんだ。
OOPLはOOによる開発プロセスを素直に実装するための言語
分析や設計がなぜOOなのかというと、それが一番
システム開発に適しているから。
そしてその分析、設計に一番適している実装がOOPL
関数型による分析や設計が出てこないことには
関数型は実装のみにしか適用されずに終わるよ。
夢見ちゃったって感じだね。
>システム開発に適しているから。
正しくはこうだね。
分析や設計がなぜOOなのかというと、使う言語がOOPLだから。
実装のみの技術ってことだろうね。
何を？
流れ的に>>41
今Haskell版読みながらRuby版書いてみてるんだけど、やっぱ適当に書かれてる印象はないなあ
発想自体がよく練らないと出てこないというか
「自分が手作業でやるならこう」を素直にコード化する手続き脳ではいきなりは出てこないコードだと思う
どちらにしても行き当たりばったりにも見えないんだよ、それがサクッと出て来る時点でもう設計できてんじゃん、みたいな
そうは言っても関数型言語での記述は、仕様をそのまま記述してるだけだしな・・・
クイックソートの記述が有名だけど、マージソートはもっと仕様そのまま書いてるだけなのがハッキリする
-- ソート済みのリストの小さい方をリストに追加して、他方を元のリストに戻して、リストのどちらかが空になるまで比較とリストへの追加、他方のさし戻しを繰り返す
merge xs [] = xs
merge [] ys = ys
merge (x:xs) (y:ys) | x < y = x:merge xs (y:ys)
merge (x:xs) (y:ys) = y:merge (x:xs) ys
-- １要素または空になるまで半分に分割を繰り返してからmergeによる結合（１要素のリスト、または空リストはソート済みのリスト）
mergesort [] = []
mergesort [z] = [z]
mergesort zs = merge (mergesort xs) (mergesort ys)
where
(xs,ys) = splitAt (length zs `div` 2) zs
分析については、プログラミングHaskellの最後の方に書いてるプログラムの論証を読むと参考になると思う
>>41も、設計もへったくれも無く、こうしたいなと言う脳内仕様をそのまま書いたし、checkPermuを外に追い出して差し替えられるようにしたいな。とか、長さの異なるリストも扱えるようにしたいな。という気まぐれでどんどん変更してた
（そもそも設計が必要な規模じゃないが)
手作業でやる場合の手順をそのままコードに書いた、非常に手続き的な思考回路だと思う
class Array
def my_permu
return [] if empty?
return [ns] if size == 1
result = []
each do |n|
without_n = reject{|x| x == n }
without_n.my_permu.each do |ary|
result.push( [n] + ary )
end
end
return result
end
end
p (1..3).to_a.my_permu
ruby挫折したりプログラマとしても挫折した(半年で才能無いと悟って辞職)私が褒められてる・・・
設計経験Zeroですよ＾＾；
手続き的なやり方が合わなかったんじゃね？
俺は逆に、そういう式的というか関数的というか…そういう発想が出てこない
まず最初に「それをやるなら、あれをやって、これをやってから…こうかな」と考えて、それをコード化してしまう
その例で言えば俺の脳内ではまず「数字の書かれたカードを並べていき、並べたらメモる」という作業が行われる
いきなりリストを組み合わせ分増やし、フィルタを掛けるなんて発想が出てこない
class Array
def my_permu
return [] if empty?
return [self] if size == 1
result = []
each do |n|
without_n = reject{|x| x == n }
without_n.my_permu.each do |ary|
result.push( [n] + ary )
end
end
return result
end
end
p (1..3).to_a.my_permu
ｵﾚのｺｰﾄﾞは誰も褒めてくれなかった。それどころかｵｾﾛの難解ｺｰﾄと同列扱いされる始末…orz
出てこないのはやっぱりって感じ
オブジェクト指向・・・設計部分の実装
関数型 or 手続き型 ・・・ 一処理の実装
といわれるのはこういうとことか
発想の基点は恐らく、リスト内包表記でしょうね
勝手に全ての組み合わせを生成してくれますし、条件で生成される組み合わせを絞り込める
それを柔軟に扱えるようにしない手は無いな。と
じつは、昔、別のスレでリスト内包表記と再帰の合わせ技は見掛けてたんですよ
発想だけ貰って、自分で自作しました
関数脳の作り方は今も昔も、どう言う関数？どう動くべき？です
このメソッドを使ってとか、ここはポインタで・・・とかの発想は無いです
最初にベタな発想があって、流用できる関数があれば、流用する
Q：lengthは何をする関数？
A：リストを受け取って、長さを返す関数
Q：lengthはどう動くべき？
A：先頭から、１ずつ足して行くべき
Q：リストが空っぽになったら？
A：足しても変わらない０を返す
length [] = 0
length (_:xs) = 1 + length xs
流用版
length xs = sum [1 | _ <- xs] -- 上のQ&Aと、要素数と同じ数だけ１が入ったリストを生成して足し合わせるのは等価
多分、手続き脳ですでにプログラミング出来てる人は、最初から抽象的に考える素養はあると思うので、仕様をそのまま書いてる感覚さえ分かれば、一気に関数脳になると思います
これは局所的なコードは手続き型のほうが恩恵あることを示している。
C++やJavaが受け入れられたのは局所的でないところでは
OOの援用が有効だということを示している。
関数型と対峙するのは手続き型。
受け入れられるとしたらOOと手続き型の中間地点なんじゃないかな。
俺の場合、まず >>67 のように書いてから、それを発展させて初めて関数的コードになる感じになる
実は前スレの >>172 を書いたのも俺なんだが、同じようなコードをまず書いて、それを inject に直した
そこから更に発展させると関数型言語のコードとして成り立つようには出来ると思うが(inject→foldlの変換は難しくないし)
本当に関数型な人のアプローチとはやはり違う形になってしまうんじゃないかなと思う
関数に焦点があたってるけどさ、
それより大きな範囲のオブジェクトはどうするのさ？
昔は、手続き型とか関数型とかの選択肢より、切実にメモリやCPU速度が足りなくて、Cが選択されて、速度を損なわずOOP出来るC++が選択されてきた（OOPも最初はメモリの無駄が多いと敬遠されてきた)
PCの進化とともにLLが選択される場面が増えて来たのと同様に、関数型言語が選択される場面が増えても不思議ではない
・・・けど、C系列の言語が多く選ばれるんだろうな
do記法も、モナドが何となく分かってくると順番が重要な処理をこれまた仕様通りに書いてるだけって気付くし、手続き型を見事に矛盾無く関数型言語でエミュレートしてる事に気付いて鳥肌立つんだが
順序の無い関数の世界で順序の概念をエミュレートしてるって凄い！って
前スレの「テキストファイル読み込んで、行番号つけて表示せよ」ってのを読みやすく？書いてみた
import System.Environment
numbering xs = unlines $ map (\(x,y) -> show x ++ y) (zip [1..] (lines xs))
main = do
fnames <- getArgs
fstrings <- mapM readFile fnames
let numfstrings = map numbering fstrings
putStr $ unlines numfstrings
とくにJavascriptは関数型風にも書けるけどただの趣味の範囲で終わってる。
ブラウザで動く言語はJavaScriptで決まりだよ。
関数型言語は無駄が多いからね。
Objective-CとC#は局所的であることを怖れないが、そういうのは受け入れられにくい
C++とJavaが受け入れられたのは、局所化でないところが実在するのではなく
漠然と、どこかそういうところに行きたいという願望があっただけだろう
意味が分からない
親が動物クラスで子が犬クラス・猫クラスとかのあれ？
型の性質を引き継ぐと言うのは型クラスとか有るけど・・・
ええと・・・で、そのオブジェクトで何をしたいの？どう拡張したいの？それって、オブジェクトである必要あるの？
犬か猫かに合わせて泣き声変えるんなら
data Animals = Dog | Cat deriving (Eq,Show)
voice a | a == Dog = "wan wan!"
voice a | a == Cat = "nya- nya-!"
これで十分なんだけど・・・そして、どっちもanimals型
犬は猫じゃないし、猫も犬じゃない
taroは犬で、taroという名前で、７歳
taro = (Dog,"taro",7)
miiは猫で、miiと言う名前で、３歳
mii = (Cat,"mii",3)
taroは猫じゃないし、miiは犬じゃない
let animalCategory (x,_,_) (y,_,_) = x == y
animalCategory taro mii
>False
全部受け入れられている言語だと思うが・・・
言語なんて金になるかどうかで受け入れるかどうかが決まるもんだよ
関数型言語で金になる話が無いだけ
と言うわけで関数型言語でスマフォアプリ作れる環境を（ｒｙ
犬とか猫を
どうやって関数型言語で表現するの？
これを本気でいうからなぁ
犬とか猫を
どうやってオブジェクト指向言語で表現するの？
まさか class Dog のインスタンスが犬なの？www
言いたい事は分かったが、なんでUMLで分析しないの？
金銭の概念をオブジェクト指向分析すればいいのに、なぜ犬と猫なんだ？
型と値の区別ついてるかな？
もちろん
だからクラスではなくインスタンスだって言ってるだろ
え、表現できてるでしょ？
むしろ、DogもCatもAnimalsに属してるのであって、オブジェクト指向のDogとCatがAnimalの子って言う関係の方が不自然だよ
そして、SnakeやLionが増えても、Animals型である限り、同じ関数が使えるし、せいぜい１つの機能に付き、一つの関数書き換えで済む（泣き声変えるために、いちいちクラスごとにvoiceメソッドを書く必要も無い)
OOPLでもジェネリックやテンプレートで型ごとにメソッド書くでしょ？
でもそれって、OOPLの利点じゃないと言うか、むしろ関数型言語の方が強力
voiceメソッドがAnimalクラスや、その子クラスにあるのは良いけど、animalCategoryメソッドをAnimalクラスが保持するのは不自然。そうなると、関数型では存在しない第３のクラスを作る必要が出てくる（Categoryクラスみたいな?)
関数型言語のデータはデータ。関数は関数。という関係の方が、シンプルに思える
それって、関数型言語でオブジェクト指向やってるだけですよね？
一応さ、型クラス使った方が良いと思うので貼っとくね
Animalに動物足すたびに代数データ型を変更するのはアレなんで
class Animal a where
voice :: a -> String
data Dog = Dog deriving (Eq, Show)
instance Animal Dog where
voice _ = "wan wan!"
data Cat = Cat deriving (Eq, Show)
instance Animal Cat where
voice _ = "nya- nya-!"
taro = (Dog, "taro", 7)
mii = (Cat, "mii", 3)
いや、プロじゃないんでUML触ったこと無い
名前しか知らん
プロの視点で関数型言語とオブジェクト指向言語の生産性の比較とかやって欲しいところ
素人視点（＝感覚的）では、LLとの比較でも、rubyやpythonは記憶力勝負（多くのメソッドを記憶してれば効率的。むしろ、何もメソッド知らない状態だとほぼ何も出来ない)
Haskellは少ない知識で割と素人でも何とかなる（既存の関数知ってる方が効率的なのはLLと変わらないが、何も知らない状態での開発効率に雲泥の差がある)
初学者へのモチベーション維持と言う意味では、関数型言語の方が向いてると思う
そして、最終的な生産効率はLLと変わらないか若干劣る（読みやすさ重視だとほぼ差がなくなる)
昔、length関数をrubyでどう書くの？と言う質問に対して、メソッドとクロージャ駆使して短いコードが返ってきた
素人じゃとても書けないと思った
Haskellなら基本的な再帰関数の作り方覚えるだけで作れるものが、LLだとそれなりの知識を必要とするのだと感じた瞬間だった
Haskellばかり話題に登るのでMLに触れておくと、
MLにはモジュール（関数とデータの集合）というものがあり、
さらにモジュールを引数に取ってモジュールを返す関数（Functor）がある
これはOOPでいうとクラスからクラスへの関数を定義できるようなもの
カプセル化？差分プログラミング？全部余裕ですよ
余計なこと考えるだけのメリットが聞きたいのに
例えば文字列のリストのjoinを
",".join(strlist) とするか
strlist.join(",") にするかみたいなね
・・・・え？
オブジェクト指向設計って事？
意識したこと無いけど、これがそうなのか・・・
まあ、関数型言語は色んな角度の視点を許容する感覚はあるかな
何だろう。破壊的な代入が出来ない分、そのものの性質を見ようとする体質に自然となるような・・・
Haskell でリストの要素を swap する 9 つの方法
http://jutememo.blogspot.jp/2011/04/haskell-swap-9.html
>>70のlengthも視点の角度が違うだけで等価なものだしプログラミングHaskellの付録Aに書いてるlengthの定義もまた違う視点
length = foldl (\n _ -> n + 1) 0 -- 初期値0とリストの先頭要素を受け取るが、初期値に＋１を繰り返すだけ、リストが空になったら蓄積変数(初期値0のもので、リストが空になるまでひたすら＋１されてた変数）を返す
仕様の表現の仕方に色んな表現があるけど、OOPLや手続き型は表現自体を制限されてる感じ
だから、そのまま仕様をコードに落とせないと感じるのかも・・・
TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲
マルチスレッドプログラミング相談室 その8 (978)
【PSP】PSPで東方やりたい奴12【弾幕】 (149)
おまいら最強の麻雀プログラムしてみろよ Part5 (525)
Microsoft Silverlight その9 (271)
HSPプログラムコンテスト２０１１【part 2】 (208)
Androidプログラミング質問スレ Part22 (364)
--log9.info------------------
ハゲ判定スレ 61本目 (265)
【どうなの】バイオテック【生えるの】 (813)
嵐の櫻井翔がハゲてる (468)
やはりハゲはーのしすぎが原因だった！７ (758)
【片側Ｍ】おでこが下北半島みたい【むしろＮ】 (306)
なんで美容院のやつは薄毛なのにすくんだ？ (284)
ハゲ (156)
【食事療法】 (467)
ハゲよりチビのほうが悲惨 (331)
●●●●小倉智昭ってヅラなの？？●●●● (342)
全スカで坊主にしてオワタ (804)
■発毛◆リアップＸ5 7本目■なが〜い付合い (282)
なまはげ暴走！女湯乱入！！！ (393)
アデノバイタルは結果を出す。 (564)
ハゲにはサウナがいいらしい・・・ (579)
【リーブ２１】 髪ドック 【３８００円】 (151)
--log55.com------------------
一番馬鹿・いらない美大
【ena】新宿美術学院18【No．5】
河合塾美術研究所名古屋校
学校法人桑沢学園（造形・桑沢共通）スレ
松任谷由実の母校、多摩美術大学は底辺校
女子美 短期大学部
東京デザイン専門学校part10
低偏差値からムサタマ行ったひといますか？