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

1 ：12/04/07 〜 最終レス ：12/05/30

一般的には、オブジェクト指向型言語が優勢でが
一部には関数型言語を崇拝している人もいます
どちらが上なのか、この際はっきりさせましょう
前スレ http://toro.2ch.net/test/read.cgi/tech/1331328955/

2 ：

オブジェクト指向 ∋ (関数型言語 VS 手続き型言語)
http://toro.2ch.net/test/read.cgi/tech/1333801632/

3 ：

前スレ>>1000
> それならそれでFILTERでも変更できるインターフェースを付け加えればいいだけ。
そういう変更/拡張のし易さも議論の対象
ちゃんと変更したコードを提出しないと比較にならない
負け惜しみじゃないんだろ？

4 ：

>>3
本来はフィルタでやることではないよ。
それわかってる？

5 ：

まあやるなら、
class Filter {
　private i = 0;
　private m = 0;
　begin(awk) {awk.RS=';'}
　filter(line) {i++; m = max(m, line.length()); }
　end() {print "最大文字数は"+m+"文字でした"}
}
こんな感じだろうｗ

6 ：

>>4
いいから「改行コードを変更する拡張をする」に対して
OOPでやるとどれくらい簡潔になるか、コードを出せって
疑似コードじゃなくて動くヤツな

7 ：

beginの引数が変わるのが好ましくない場合は
こんな感じかな。まあこの例なら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}
}

8 ：

>>5
肝心の部分はどうしたんですか？
どうやってセパレートしたんですか？
そうやって誤摩化すってことは、関数型言語で一瞬で書けるコードが
OOPでは難しいってことですね？

9 ：

>>6
OOPでやると簡潔になるんじゃなくて、
変更の範囲を極小化出来るんだよ。
該当のフィルタだけの修正で、
それ以外の場所は何も変えないで変更できる。

10 ：

いいから代表的なコードは貼りなおせよ
使えないな

11 ：

>>8
え？ 行フィルタなのに、ファイル全体をセパレートするのはおかしいでしょ？
ここにないのは、ここにあるべきじゃないコードだからだよ。

12 ：

じゃあ、問題をはっきりさせよう
「標準入力から文字列を読み込んで、カンマ区切りで改行して、
各行の文字数を数えて最大文字数を標準出力に表示せよ」
これを書いて

13 ：

設計がおかしいって指摘されて
ファビョってきたなｗ
全部関数なんかでやろうとするから
設計ができないんだ。

14 ：

>>12
それ問題が不適切。
「標準入力」から文字列を読み込んで、「カンマ区切りで改行」して、
「各行の文字数を数えて最大文字数」を「標準出力」に表示せよ
ただし、カッコの中は一例であり
容易に変更できる設計にしておくこと

15 ：

○から文字列を読み込んで、△で改行して、
各行に対して□を処理をして、その結果を☆に表示せよ
抽象化するとこんな感じか。

16 ：

またこういう例題か…
ｵﾚ何度も書いたし、もういいや今日は。

17 ：

コードが出ても議論が進まないことがはっきりしただけかｗ

18 ：

まず、リーダーインターフェースが必要。
そのリーダーインターフェースを実装した、
標準出力リーダークラスを作る。
行セパレータインターフェースが必要
その行セパレータインターフェースの実装として、
\r\nセパレータを作る
その後フィルタインタフェースが必要で
そのフィルタインタフェース（begin、filter、end）を実装した、
「各行の文字数を数えて最大文字数」はfilterで文字数を数えて
endで結果を出力する。
あとは、同様にライタインターフェースを実装した
標準出力ライタクラス。

19 ：

どうせなら、parottをJapaで書いたらこーんなに見通しのよいﾌﾟﾛｸﾞﾗﾑが短期間でできましたよ
とかそんくらいの成果聞いてみたいもんだわ

20 ：

結局拡張性をもたせようとすると、
こんな感じになるわけ。
例外が悪いという意味がわかったかな？

21 ：

能書きからして冗長までは良くわかった。

22 ：

関数型は実装の一つを書いているだけ。
オブジェクト指向は様々な実装を書くための仕組みを
提供するもの、つまり設計の部分なので
やることの対象が違うんだよ。
オブジェクト指向で枠組み設計を行い
関数型言語でその枠組みの中身を書く

23 ：

冗長というか、単にオブジェクト指向は、単処理よりも
広範囲な部分、処理の連携部分を記述する言語ってことなだけでしょ。

24 ：

この程度の例題で広範も減ったくれもない気がす

25 ：

>>22
> オブジェクト指向で枠組み設計を行い
> 関数型言語でその枠組みの中身を書く
こんな感じ？
{-# 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 -- 改行コードを変えて入出力先も変更

26 ：

>>25
おー、なかなか。ﾊﾟﾁﾊﾟﾁ

27 ：

なんかお株奪われた?

28 ：

>容易に変更できる設計にしておくこと
ソースにパッチを当てて変更するのは容易ではないの？
パッチが容易ではないというのは、もしかして
「CUIは容易ではない」「GUIは容易」みたいな思想と関係あるのか

29 ：

> ソースにパッチを当てて変更するのは容易ではないの？
ソースにパッチ当てるといってもいろんな意味がある。
インターフェースを変更するようなソースの修正は容易ではない。
影響があちこちに波及するからだ。

30 ：

OOが使えそうなところにはOOの機能を使うし、
関数型が使えそうなところには関数型の機能を使う。
両方使えそうにないところは普通の手続き型の格好に。たったそれだけのことだろ？
「関数型 vs オブジェクト指向」 からは、「if文 vs for文」並みのナンセンスさを感じるね。
OOも関数型も単なる一機能なんだから、状況に合わせて 使う/使わない すればよいじゃない。

31 ：

なにも言ってないレスされても

32 ：

>>30
「関数型 vs オブジェクト指向」ならその通りなんだけど、
ここは「関数型言語 vs オブジェクト指向言語」なんだわ

33 ：

そういや関数型指向ってないよねｗ

34 ：

>>29
パッチの意味は追加と削除の二種類しかない。
マクロな視点でいうと、最新版を出す影響と古い安定版を切り捨てる影響の二つ。
現に大きな影響が出ているが、
関数型とオブジェクト指向の人間はこの問題についてなにも言ってない。
なぜなら、古い仕様が優遇されてしまうと手続き型が圧倒的に有利だから。

35 ：

>>34
具体的に言って下さい。

36 ：

>>33
functional (programming)

37 ：

一口にパッチと言っても
・ソースコード自体を書き換える方法
・ソースコードはそのままに静的に書き換える方法（マクロ、テンプレート）
・ソースコードはそのままに実行時に書き換える方法（モンキーパッチ）
などがあるのですが

38 ：

>>37
文字列自体を操作する方法と、文字列に代わるものを操作する方法があるよね

39 ：

>>33
個人的に、関数型言語は「型指向」だと思う
どう言う型受け取って、どう言う型を変えしたいのか考えると、自然と答えが出て来る

40 ：

>>37
それらの区別はたいして何も変わらんｗ

41 ：

個人的には、OOPLだと設計がしっかりしてないと拡張するとき困ること多いけど、関数型言語だと、設計を意識しなくても（行き当たりばったりでも)拡張しやすい感触がある
納期に迫られ、ろくに設計できる環境も、人材も無い現場では関数型言語の方が向いてると思うんだが・・・
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

42 ：

>>40
全然違うだろアホか

43 ：

>>39
節子、動的・動的…

44 ：

>>18の方針でJavaで実装したら100行超えた……
やっぱOOPはだわ……

45 ：

でも関数型でも50歩100歩だったよ・・・

46 ：

>>41
俺は
「設計を意識しないとそもそも書けない」のが関数型言語で
手続き型言語やOOPLはメチャクチャな設計でも書けるor書けてしまうが
ちゃんと意識すると関数型言語にも通ずるようなコードが出来上がる
…と感じる

47 ：

じゃあRubyで実装しましょうよｗ

48 ：

俺は
設計・・・オブジェクト指向
実装・・・関数型言語
って感じるな。

49 ：

UMLがアップを始めました

50 ：

単なる型スイッチに夢おいもとめんなって。
OOだって実装の道具にすぎん。ハンマーやカンナの類だ。

51 ：

実装の道具は、OOPLだよ。
OOにはOOA（分析）やOOD（設計）があって
開発プロセス全体をカバーするものなんだ。
OOPLはOOによる開発プロセスを素直に実装するための言語
分析や設計がなぜOOなのかというと、それが一番
システム開発に適しているから。
そしてその分析、設計に一番適している実装がOOPL
関数型による分析や設計が出てこないことには
関数型は実装のみにしか適用されずに終わるよ。

52 ：

OOPLが先にあって、それを生かす形でOOAやOODが生まれたわけで。
夢見ちゃったって感じだね。

53 ：

>分析や設計がなぜOOなのかというと、それが一番
>システム開発に適しているから。
正しくはこうだね。
分析や設計がなぜOOなのかというと、使う言語がOOPLだから。

54 ：

結局無記名で議論すると個人の感想の叫びあいなんだよね

55 ：

関数型における分析と設計が出ない時点で
実装のみの技術ってことだろうね。

56 ：

>>47
何を？

57 ：

関数と述語による形式的仕様記述やZ言語は？

58 ：

OOP より FPのほうが響きがいい よってFPの勝ち。

59 ：

>>56
流れ的に>>41

60 ：

>>59
今Haskell版読みながらRuby版書いてみてるんだけど、やっぱ適当に書かれてる印象はないなあ
発想自体がよく練らないと出てこないというか
「自分が手作業でやるならこう」を素直にコード化する手続き脳ではいきなりは出てこないコードだと思う

61 ：

ああ、適当っつーか原文に倣えば「行き当たりばったり」か
どちらにしても行き当たりばったりにも見えないんだよ、それがサクッと出て来る時点でもう設計できてんじゃん、みたいな

62 ：

>>55
そうは言っても関数型言語での記述は、仕様をそのまま記述してるだけだしな・・・
クイックソートの記述が有名だけど、マージソートはもっと仕様そのまま書いてるだけなのがハッキリする
-- ソート済みのリストの小さい方をリストに追加して、他方を元のリストに戻して、リストのどちらかが空になるまで比較とリストへの追加、他方のさし戻しを繰り返す
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を外に追い出して差し替えられるようにしたいな。とか、長さの異なるリストも扱えるようにしたいな。という気まぐれでどんどん変更してた
（そもそも設計が必要な規模じゃないが)

63 ：

ちなみに数分で、行き当たりばったりで書いてみたRubyのコードはこんな感じ
手作業でやる場合の手順をそのままコードに書いた、非常に手続き的な思考回路だと思う
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

64 ：

>>60-61
ruby挫折したりプログラマとしても挫折した(半年で才能無いと悟って辞職)私が褒められてる・・・
設計経験Zeroですよ＾＾；

65 ：

ごめんテストしてからレスすべきだった…

66 ：

>>64
手続き的なやり方が合わなかったんじゃね？
俺は逆に、そういう式的というか関数的というか…そういう発想が出てこない
まず最初に「それをやるなら、あれをやって、これをやってから…こうかな」と考えて、それをコード化してしまう
その例で言えば俺の脳内ではまず「数字の書かれたカードを並べていき、並べたらメモる」という作業が行われる
いきなりリストを組み合わせ分増やし、フィルタを掛けるなんて発想が出てこない

67 ：

>>63 を修正
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

68 ：

褒められてｲｲﾅｧ…
ｵﾚのｺｰﾄﾞは誰も褒めてくれなかった。それどころかｵｾﾛの難解ｺｰﾄと同列扱いされる始末…orz

69 ：

でもまあ、この程度の規模ではオブジェクト指向が
出てこないのはやっぱりって感じ
オブジェクト指向・・・設計部分の実装
関数型 or 手続き型 ・・・ 一処理の実装
といわれるのはこういうとことか

70 ：

>>66
発想の基点は恐らく、リスト内包表記でしょうね
勝手に全ての組み合わせを生成してくれますし、条件で生成される組み合わせを絞り込める
それを柔軟に扱えるようにしない手は無いな。と
じつは、昔、別のスレでリスト内包表記と再帰の合わせ技は見掛けてたんですよ
発想だけ貰って、自分で自作しました
関数脳の作り方は今も昔も、どう言う関数？どう動くべき？です
このメソッドを使ってとか、ここはポインタで・・・とかの発想は無いです
最初にベタな発想があって、流用できる関数があれば、流用する
Q：lengthは何をする関数？
A：リストを受け取って、長さを返す関数
Q：lengthはどう動くべき？
A：先頭から、１ずつ足して行くべき
Q：リストが空っぽになったら？
A：足しても変わらない０を返す
length [] = 0
length (_:xs) = 1 + length xs
流用版
length xs = sum [1 | _ <- xs] -- 上のQ&Aと、要素数と同じ数だけ１が入ったリストを生成して足し合わせるのは等価
多分、手続き脳ですでにプログラミング出来てる人は、最初から抽象的に考える素養はあると思うので、仕様をそのまま書いてる感覚さえ分かれば、一気に関数脳になると思います

71 ：

昔Smalltalkという言語があったけど普及しなかった。
これは局所的なコードは手続き型のほうが恩恵あることを示している。
C++やJavaが受け入れられたのは局所的でないところでは
OOの援用が有効だということを示している。
関数型と対峙するのは手続き型。
受け入れられるとしたらOOと手続き型の中間地点なんじゃないかな。

72 ：

>>70
俺の場合、まず >>67 のように書いてから、それを発展させて初めて関数的コードになる感じになる
実は前スレの >>172 を書いたのも俺なんだが、同じようなコードをまず書いて、それを inject に直した
そこから更に発展させると関数型言語のコードとして成り立つようには出来ると思うが(inject→foldlの変換は難しくないし)
本当に関数型な人のアプローチとはやはり違う形になってしまうんじゃないかなと思う

73 ：

>>70
関数に焦点があたってるけどさ、
それより大きな範囲のオブジェクトはどうするのさ？

74 ：

>>71
昔は、手続き型とか関数型とかの選択肢より、切実にメモリや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

75 ：

速度やメモリの問題はJavaやJavascriptが普及した時点で終わってる。
とくにJavascriptは関数型風にも書けるけどただの趣味の範囲で終わってる。

76 ：

何を持って趣味なのかわからんけど、
ブラウザで動く言語はJavaScriptで決まりだよ。

77 ：

副作用なしラムダ計算だけで記述するJavascriptって意味なんだが

78 ：

順序をリストにしてるだけだと思うんだが

79 ：

速度やメモリからすれば
関数型言語は無駄が多いからね。

80 ：

>>71
Objective-CとC#は局所的であることを怖れないが、そういうのは受け入れられにくい
C++とJavaが受け入れられたのは、局所化でないところが実在するのではなく
漠然と、どこかそういうところに行きたいという願望があっただけだろう

81 ：

何言ってるかさっぱりわからんｗ

82 ：

>>73
意味が分からない
親が動物クラスで子が犬クラス・猫クラスとかのあれ？
型の性質を引き継ぐと言うのは型クラスとか有るけど・・・
ええと・・・で、そのオブジェクトで何をしたいの？どう拡張したいの？それって、オブジェクトである必要あるの？
犬か猫かに合わせて泣き声変えるんなら
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

83 ：

>>80
全部受け入れられている言語だと思うが・・・
言語なんて金になるかどうかで受け入れるかどうかが決まるもんだよ
関数型言語で金になる話が無いだけ
と言うわけで関数型言語でスマフォアプリ作れる環境を（ｒｙ

84 ：

>>82
犬とか猫を
どうやって関数型言語で表現するの？

85 ：

>>83
これを本気でいうからなぁ

86 ：

>>84
犬とか猫を
どうやってオブジェクト指向言語で表現するの？
まさか class Dog のインスタンスが犬なの？www

87 ：

>>83
言いたい事は分かったが、なんでUMLで分析しないの？
金銭の概念をオブジェクト指向分析すればいいのに、なぜ犬と猫なんだ？

88 ：

>>86
型と値の区別ついてるかな？

89 ：

>>88
もちろん
だからクラスではなくインスタンスだって言ってるだろ

90 ：

>>84
え、表現できてるでしょ？
むしろ、DogもCatもAnimalsに属してるのであって、オブジェクト指向のDogとCatがAnimalの子って言う関係の方が不自然だよ
そして、SnakeやLionが増えても、Animals型である限り、同じ関数が使えるし、せいぜい１つの機能に付き、一つの関数書き換えで済む（泣き声変えるために、いちいちクラスごとにvoiceメソッドを書く必要も無い)
OOPLでもジェネリックやテンプレートで型ごとにメソッド書くでしょ？
でもそれって、OOPLの利点じゃないと言うか、むしろ関数型言語の方が強力
voiceメソッドがAnimalクラスや、その子クラスにあるのは良いけど、animalCategoryメソッドをAnimalクラスが保持するのは不自然。そうなると、関数型では存在しない第３のクラスを作る必要が出てくる（Categoryクラスみたいな?)
関数型言語のデータはデータ。関数は関数。という関係の方が、シンプルに思える

91 ：

争いは、同じレベルの者同士でしか発生しないのAA

92 ：

>>90
それって、関数型言語でオブジェクト指向やってるだけですよね？

93 ：

>>82
一応さ、型クラス使った方が良いと思うので貼っとくね
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)

94 ：

>>87
いや、プロじゃないんでUML触ったこと無い
名前しか知らん
プロの視点で関数型言語とオブジェクト指向言語の生産性の比較とかやって欲しいところ
素人視点（＝感覚的）では、LLとの比較でも、rubyやpythonは記憶力勝負（多くのメソッドを記憶してれば効率的。むしろ、何もメソッド知らない状態だとほぼ何も出来ない)
Haskellは少ない知識で割と素人でも何とかなる（既存の関数知ってる方が効率的なのはLLと変わらないが、何も知らない状態での開発効率に雲泥の差がある)
初学者へのモチベーション維持と言う意味では、関数型言語の方が向いてると思う
そして、最終的な生産効率はLLと変わらないか若干劣る（読みやすさ重視だとほぼ差がなくなる)
昔、length関数をrubyでどう書くの？と言う質問に対して、メソッドとクロージャ駆使して短いコードが返ってきた
素人じゃとても書けないと思った
Haskellなら基本的な再帰関数の作り方覚えるだけで作れるものが、LLだとそれなりの知識を必要とするのだと感じた瞬間だった

95 ：

>>73
Haskellばかり話題に登るのでMLに触れておくと、
MLにはモジュール（関数とデータの集合）というものがあり、
さらにモジュールを引数に取ってモジュールを返す関数（Functor）がある
これはOOPでいうとクラスからクラスへの関数を定義できるようなもの
カプセル化？差分プログラミング？全部余裕ですよ

96 ：

別に完全否定してるわけじゃないのにできますよって
余計なこと考えるだけのメリットが聞きたいのに

97 ：

メソッドをどのクラスに入れるか迷うようなことは無くなるね
例えば文字列のリストのjoinを
",".join(strlist) とするか
strlist.join(",") にするかみたいなね

98 ：

>>92
・・・・え？
オブジェクト指向設計って事？
意識したこと無いけど、これがそうなのか・・・
まあ、関数型言語は色んな角度の視点を許容する感覚はあるかな
何だろう。破壊的な代入が出来ない分、そのものの性質を見ようとする体質に自然となるような・・・
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や手続き型は表現自体を制限されてる感じ
だから、そのまま仕様をコードに落とせないと感じるのかも・・・

99 ：

OOも知らないで語ってたのかｗ

100read 1read

1read 100read

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

JavaScriptは消滅すべきだったよな (111)
MATLABプログラミング　質問箱　その3 (791)
【バグ管理】 BTS使ってる？【追跡】 3 (900)
OpenWatcom C++ (715)
くだすれAjax（超初心者用） (320)
【至急】助けてください。 (237)
--log9.info------------------
アニメ事情 in 【福岡・佐賀除く】九州・沖縄14 (321)
●韓国人アニメーターに汚された作品を語るｽﾚ10● (552)
アニメ撮影を語るtake12 (370)
【打ち切り】赤松健について語ろう【Ｊコミ】 (455)
【角川】角川GHD part12【富士見 AMW eb! 中経 MF】 (774)
STUDIO４℃／スタジオ４℃ (474)
アニメ【バンダイビジュアル】ガンダム (323)
【質問雑談】デジタルで漫画を描こう！【おk】 (959)
◆◆◆白泉社系雑誌投稿者18◆◆◆ (430)
アニメブロガー総合スレ４ (913)
■日本の漫画に韓国人作家は必要か？　議論スレ (197)
韓国キャラは必要ないと考える作家が集うスレ17 (545)
【困った時のエロ頼み】漫画編集者の愚痴スレッド２ (823)
植田佳奈を起用しないでください (473)
【雑談OK版】漫画家を目指す人の制作報告スレ2 (330)
谷口悟朗について語るスレ　その28 (604)
--log55.com------------------
【セルフ経済制裁ｗ】　世論調査　韓国国民の70%以上が「日本にもっと強硬な報復を」「断交も辞さず」
日本、『韓国輸出規制』について追加の会合を拒否する方針
【れいわ】　山本太郎の 「#奨学金徳政令」 がツイッタートレンドに入る　若年〜主婦まで取り込みか
山本太郎れいわ新選組の仙台演説、もはやレジェンド級　見渡す限りの大聴衆が拍手喝采、大歓声
車カスのリアフォグ目潰しが糞迷惑だと話題に。日本じゃトヨタ86とかアホな車によくついてる。
【サイゾー】輸出規制への反発でBTS（防弾少年団）が日本で活動できなくなる？
【気象庁（日本の）】台風5号ダナス、中国を通り過ぎて韓国側へ　週末のソウルの天気は壊滅的
最近、日テレの「韓国ぶっこみ」が多い。どうしたの？