【アンチ】関数型言語は使えない【玩具】 ２->画像>2枚

前スレ
http://toro.2ch.net/test/read.cgi/tech/1320743217/

オブジェクト指向言語で関数型風味(？)に書いたらこんな感じ？
http://ideone.com/CXMrq

要素数と実行時間が何の関係無くなるけど
そもそも何を比較してたんだっけ

今時の技術についていけなくなったら辞めてくださいね

前スレで関数型言語は玩具にすぎないと結論出たからスレは不要

>>1乙

前スレ>>992-993
なら、Haskellもコンパイラの進歩でpythonに並ぶ余地はあるって事か

元々、length関数や、++演算子（リストの連結演算子）が初心者にも簡単に作れるってのが気に入ってるだけだから、体感できない速度差は気にならんけど・・・
Haskellに惹かれるのは、defとか、forとか、（モナド使わない限りはifも）そう言うキーワードをなるべく見ないで済むってのが、一番大きい気がする
（というか、forとifが一番見たくない）

あと、基本的に右辺と左辺が=（等しい）なのも気に入ってる

コンパイラのmain=...と言うのも、あながち間違ってない

速度こそpythonに劣るだろうけど、自作のmap関数や、++演算子などの":"で区切られて、状態を次の再帰に引き摺らないものは、単純再帰でも、ループとして扱われる
（だからこそ、末尾再帰は、次の再帰に状態を引き摺らないのでループになる）
結局、アセンブラに実現できることは、関数型言語でも、命令型言語でも、最終的な最適化の形は同じになるだろうけど、それは時間が解決する話

関数型言語の最終的な最適化の形は
http://ideone.com/SaMJe と　http://ideone.com/kzkty が同じ速度になる事

これは、参照透明性が確保されて無いと、最適化できない事の一つ
（まだ実現されてないけし、逆に言えば、参照透明性が確保された関数に限れば、命令型言語でも理論的には最適化可能なはず）

>>5 最後の行について
Fortran95には、純粋関数/手続きというのがあって、これは副作用を持たない
ということなのたが、ベクトル演算ができるようになる。
が、write文が使えなくなるとか、グローバル変数が使えないとかいろいろ
制約があって非常に使いにくい。

●過去スレ
関数型言語は何故普及しないのかを考える
http://hibari.2ch.net/test/read.cgi/tech/1277215506/
関数型言語は何故普及しないのかを考える
http://hibari.2ch.net/test/read.cgi/tech/1286791669/
【アンチ】関数型言語は使えない【玩具】
http://toro.2ch.net/test/read.cgi/tech/1320743217/

●関連スレ
関数型言語Part5
http://toro.2ch.net/test/read.cgi/tech/1252470706/

速度比較は、よくネタになるけど、最も抽象度の低い言語でも出来る例での比較→言語自体の優劣の流れは無意味だろ。
VBとアセンブラを比べるようなもんだけど、単純作業での比較にこだわる人が多いのはなんでだろう？

なぜ関数型言語は普及しないか - プログラミング日記
http://d.hatena.ne.jp/morchin/20110614/p1
「なぜ関数型言語は普及しないか」に対する言及
http://togetter.com/li/149656
関数型言語が普及しない理由 - mizon dev
http://d.hatena.ne.jp/mizon9/20111112/1321046483
関数型言語が普及しない理由その2 - mizon dev
http://d.hatena.ne.jp/mizon9/20111112/1321128525
関数型言語が普及しない理由 - 偏見プログラマの語り！
http://d.hatena.ne.jp/kura-replace/20111114/1321236695
関数型言語が普及しない理由 - より良い環境を求めて
http://d.hatena.ne.jp/n314/20111114/1321290502

>>8 パッと見て、いろいろ言えるからではないだろうか。
そこそこ重たい数値計算をやりだすと、関数型言語が謳う理想通りにいかない
場面はいろいろあるのだが、2chのように限られた字数でしかも関係者外にも
わかるように問題点を説明するのはなかなかうまくいかない。

個人的にはHaskell、lispはアプリ言語が欲しい時によく使うし、C、Javaはインフラで使ってる。
各言語には目的によって向き不向きがあるから、用途を論じるとか、用途拡大方法を考えるならまだ判る。
同じような単純作業の比較で何を得たいのか判らないんだよね。

>>8
抽象度が低くてもチューリング完全なら最終的にできることは一緒
どれだけ簡潔に書けるかという意味でいうなら、reverseという簡単な例ですら
CとHaskellには大きな差がちゃんと在った

つーか前スレの配列版HaskellはCの次に速かったぞ
コード量もC並みだが

>>12
>reverseという簡単な例ですら

そういう単純な例で実行時間が違うのはわかるけどさ、それを言語全体の優劣判定に短絡するのが無意味だと思うんだが。

コンピュータの利用範囲が広がるに連れて、アセンブラだけでは実現に手間がかかるから色んな言語が開発された訳だから。
例えば金融商品企画のようなアプリを、リソースを大量に使えばCでも開発は理屈上は可能だが、
それはもはやHaskellのインタープリターをCで再発明するくらいの問題になる。
だから疑問は、リソースには色々あるのに、なぜ単純な例で時間だけに拘るのか？という事。

単純例しか経験がなくて、時間以外のリソースは微々たるものだと考えてる者なら必然だけどね。

誰かHaskellが遅いから言語として劣ってるって書いてたっけ？

事実としては「Haskellは遅い」それだけ
言語の優劣は各自で判断すべき

はっきり数字出ましたし。

関数型のリファレンス言語と見られる言語が遅かったら
そりゃ価値を見出せないよ

速さならOCamlがC並ってのは良く聞く
自分はdefとかrecとか関数定義にプログラミング言語特有のキーワード使う機会が少ないのが気に入ってhaskell使ってるけど

>>13
>単純例しか経験がなくて、時間以外のリソースは微々たるものだと考えてる者なら必然だけどね。

このスレは、既存のHaskellコンパイラより早いHaskellインタープリターを自作出来る猛者が集う場所ですよ？

遅い遅いって一生言ってろ、でいいんじゃね？

シートベルトって窮屈じゃん、って言ってるバカと同じなんだから。

>>14
>事実としては「Haskellは遅い」それだけ

そのとおり。
Haskellでできる事は全部、C、Pythonならもっと早く出来る。
時間は重要なリソースだという事は学生にはわからんだろうな。

>>20
えっ。Haskellの遅延評価のようなことがC、Pythonなら
もっと速くできるなんていっていいのですか。
少なくとも「早く」はできませんよね。

>>21
そういうときは、コードを書いて「これを書いてみろ」って言うくらいじゃないとね

ていうか、遅延評価は手段のひとつであって、それ自体が目的であることは滅多に無い

時間という点では開発時間も重要だね

でも長いコードと、それと同性能で短いコードで
前者の方が早く作れたりするのは良くあることだから
コード量と開発時間の相関も割りと微妙なんだよね

学習コストだとか、命令型と関数型の両方を扱える人のうち
関数型の方が早く開発出来る人の割合とかも気になるところ

haskellが遅いってのは、
c/c++より遅い、あるいは静的言語の中では平均的に遅い、という意味なんだが、
時々文脈を（意図的に？）混同して、スクリプト言語よりも遅いとか言い出す輩が後を絶たない。
前スレで可変長配列と片方向連結リストを混同して勝利宣言してる馬鹿を見た時はまたかと思ったよ。

>>17
夢を壊して申し訳ないが...

OCaml

http://ideone.com/MqIzH ; （リスト）
http://ideone.com/LH93F ; （配列）

藁人形製作乙です。。。

>>24
Haskellは可変長配列に代表されるような速いデータ構造を
扱おうと思ったら途端に面倒になるのが問題なんだろ

悔しかったらPythonより速いコードをPython並みに簡潔に書いてみろ

Haskell並みに安全で機械語にコンパイルされたコードをPythonから生成してから言え

>>28
Haskellが安全？www

xs = head []

実行速度の比較をしているときに安全とか抽象力とかいうから
虫ケラ、じゃなかった、ハスケラはコミュ障だっていわれんの！

>>28
Pythonより速いコードをPython並みに簡潔に書けないという
ギブアップ宣言か

もう「Haskell = 遅い」が定着しそうな勢いだな

pythonは永続データと破壊操作を巧みに両立させて速度稼いでいるからな。
どっかでhaskellの人が永続=透明性と書かない人は理解してない人と断定してたけど、
どうしてhaskellの有名人はみんなアレなんだ？

おまえの脳内の勢いがすごい勢いで加速中ということはよくわかった

vectorパッケージが見つからない、と思ったらGHC6.8とはね・・・
古すぎるだろ・・・・
ふふふ残念ながらMPが足りないようだ・・・


・・・とするのは悔しいので前スレのSTUArray版(お借りします)とVector版を手持ちの環境で走らせて計測してみましたよ
STUArray版（コードは省略）
結果（+RTS -sオプションから抜粋）

9 MB total memory in use (0 MB lost due to fragmentation)

Total time 0.12s ( 0.10s elapsed)

次はVector版
コード
module Main where
import qualified Data.Vector.Unboxed as V

main :: IO ()
main = print $ V.head $ V.reverse $ V.iterateN 1000000 (+1) (1 :: Int)

結果

5 MB total memory in use (0 MB lost due to fragmentation)

Total time 0.05s ( 0.04s elapsed)

まあこんなところですね

隔離スレとして、ちゃんと機能してるようで何より。

「なんで時間だけに拘るの？」
「遅いのは事実だ！！」
凄いコミュ力だなw

>>23
>コード量と開発時間の相関も割りと微妙なんだよね

その言語に慣れている者が書くという前提で、一日に書けるコード量は言語による大差は無いというのをどっかで見た。

コード書いてる時間より
ビルド, 実行, ソースとにらめっこ, ウロウロしながら思考
してる時間の方が長い希ガス

コード量が同じなら抽象度の高い言語の方が多くの事が出来るだろうな。

>>39
一般に低水準の言語の方がワード単位の入力時間が短くなる。
極端な場合、倍位にはなる。だから、よほど難しい問題でないかぎり、
>>37がいうように一日に書けるコード量は同じに、近い。
しかし、それだけ体力もいるから、プログラマの定年が若くなる。
高水準な言語だと60歳でも十分。この差は大きい。

高水準な言語とはもしかしてCOBOLのことを言っているのだろうか。

リスト操作の速度を比較しようって決まって、
ベンチマークも決まって実装計測して結果が揃ったところで
どうして時間だけとか言い出すのは完全にコミュ障だろw

数行の「リスト操作」って、何を比較したことにもならんぞw

>>43 くやしいのうw

gccがhaskellになったら考える
なったらなったでメンテする人がいなくなりそうだけど

>>43
まあ元々、アッカーマンとか無視してる時点で、無意味だから。

haskellが一行で配列を高速にreverseしたのがそんなに悔しいんですか？

reverse関数「を」どれくらい簡潔に実装できるかって話してたのに
（しかも言い出したのはHaskeller）
ライブラリのreverse関数呼び出してドヤ顔して馬鹿じゃないの？

>>31を「1行」とかいう人は
目か頭のいずれかもしくは両方とも悪い。

>>49
???

ああ、自分の頭が悪いって告白ですか
そういうのはパパやママに言ってください
我々の所為じゃないので

>>46
アッカーマンを無視するってどういうこと？

>>48
ん、ああそういう流れだっけ？
じゃこれで
module Main where
import Prelude hiding (length, head)
import Data.Vector.Unboxed

rev :: Vector Int -> Vector Int
rev v = generate (length v) $ \ i -> v ! (length v - 1 - i)

main :: IO ()
main = print $ head $ rev $ iterateN 1000000 (+1) (1 :: Int)

9 MB total memory in use (0 MB lost due to fragmentation)
Total time 0.06s ( 0.05s elapsed)

今度はgenerate自作しろって言い出すんでしょうかね（笑）

っていうか『プリミティブなアルゴリズムが簡潔に書ける！』とか言って
車輪の再発明繰り返して喜んでるだけのhaskellerに問題があるよねえ
（どういう意味にせよ）少しは実用的な話をしようぜ？

>>50
ああ、43のtypoだと解らない程度の頭なんだね。
カワイソス

>>52
おそ！

2chで”流れ”を感じ始めたら、少なくとも二重の意味でヤバイな。

>>51
関数型が得意なベンチマークでなきゃヤダヤダ


ってこと。

Rは関数型に入りますか？

C言語プリプロセッサは関数型に入りますか？

バナナの皮は関数型言語に入りますか？
λ
形が似てるんですが

お前、先生が許可したら人も殺すのか
関数型言語を殺すつもりか！

haskellの遅延評価は、元々先行評価よりも遅い傾向にあるんだけどな・・・
（一部のみ、先行評価より速い）

そもそも、reverseが単方向リストに不利なわけだが・・・
とりあえず、main/print（ＩＯモナド使った関数）以外の関数を自作してみた

http://ideone.com/15yhM

自分がHaskellに惚れたのは、IO関連以外は言葉遊びみたいな感じで自作出来るのが楽しいから
(rangeはもうちょっと作りこめたかも・・・）
速さよりも、その構造を調べるのが楽しい

data Natural = Zero | Succ (Natural) deraiving (Eq,Ord,Show,Read)

自然数の定義と、リストの定義が似ているのが分かる。
自然数は、その長さそのものが数字としての意味を持ち、リストは長さにも長さと言う意味はあるが、自然数との決定的な違いは、要素自体も値を持っているか？だけだと言うのが分かる


遅延評価生かしたプログラムなら、ファイル処理とかだろうけど、ideoneでファイルの読み込ませ方知らん（と言うか、在るのか？）
ので、一応、こんなのも作ってみた（1から1000000までの足し算の合計のリストを作って、先頭の１０要素を表示）

http://ideone.com/insk7

簡約の様子を見てみると関数同士が絡み合って、一番外側の関数の終了条件のみで、他の関数の終了条件を満たして無くても、関数が終わるのが自然と理解できる

もちろん、最初から無駄の無い処理を書かれると負ける。foldllやmapみたいな、状態を次の再帰に引き摺らない様に書けば、スタック消費が抑えられるって言うだけで、Haskell自体の最適化は弱い

不覚にも>>60-61の流れに

なんで、list reverseだけでここまで引っ張ってるんだ!?
>>11を受けて関数型言語/命令型言語の適材適所の話題になると期待したのだが。

>>64
まあここは隔離スレだし、目的が互いに異なる言語同士を単純作業で比較したがる人が集まる場所でもある。
鳥と魚を比較するのに、共通項目だからといって体重や肺活量で比較するようなもんで、最重要と言えるほどの意味は無いと思うが。

比較するなら、計算モデルからのアプローチ（CTMCPなど）も有るので、該当スレが宜しいかと。

本スレで煽り質問しかできないバカは回線切って吊れ

>>62
>haskellの遅延評価は、元々先行評価よりも遅い傾向にあるんだけどな・・・
>（一部のみ、先行評価より速い）

評価する際の処理時間が先行評価より速い遅延評価って尊えば何だっけ？
遅延評価を使ったプログラムの総時間と混同してないか？

>>67
X 尊えば
O 例えば

>>67
>評価する際の処理時間が先行評価より速い遅延評価って尊えば何だっけ？

遅延評価とか先行評価とかいうのは評価『戦略』であって、『評価するかどうか』を決めるだけだ。
実際に『評価する際』には評価戦略の段階は通り過ぎてるからその問は無意味だろう。

そして遅延評価は評価するまでに猶予を置く意味合いしか無いから、
無駄な計算をしないという仮定のもとでは、遅延評価戦略が先行評価戦略よりも速くなることは有り得ない。
>>62のいう『一部』というのはたらい回し関数みたいなもののことを言ってるんだろうが、
あれはグラフ簡約がたまたまメモ化の役割を果たし無駄が省けているためであって遅延評価だからではない。

そもそも速度で評価戦略を語ることがナンセンスだよ。
あれは（たらい回しみたいな）一部の計算を無駄なく書くのを簡単にするためのものだ。
無駄なく書くのが難しくなってる計算の方が多くね、ってのが遅延評価に対して意味のある批判だろうよ。

>>69
>そもそも速度で評価戦略を語ることがナンセンスだよ。

別にそんな話はしてなくて、「先行評価より早いものがある」について具体例が知りたいだけ。
だから、総時間と混同してないか？って書いたんだがなあ。
どっかでの、Haskell=遅いって話のことなら俺は無関係。

だからさ、評価戦略によって『評価するかどうか』が決まってからは遅延評価も先行評価も同じ道を辿るんだから、
評価戦略に対して「aはbより早い」とかいうのは論理的に間違ってるってこと。

>そもそも速度で評価戦略を語ることがナンセンスだよ。
これはhaskellerの負け惜しみとかそう言うんじゃなくてさ、
速度と評価戦略が別次元の問題だってことを言いたいだけ。
haskellのたらい回しとcのたらい回しは記述が似てても、
『そもそもやってることが違う』んだから。

遅延評価は計算量を減らす目的もあるけどそれが全てじゃないよね
それに同じ計算量、無駄を省いたCの処理とかに敵うわけないし

割と手軽に計算量を減らせる(処理系にお任せ出来る)ってくらいだろう

無限リストとかを評価しちゃうと氏ぬのは言語に関係無いから
その辺はCでも配列でなく関数とかで仮想化するし

＞それに同じ計算量、無駄を省いたCの処理とかに敵うわけないし
いや、まったく同じ計算をするなら同じ処理時間になるよ。
ならないとしてもそれは遅延評価のせいではない。

＞遅延評価戦略が先行評価戦略よりも速くなることは有り得ない。
よくみると俺もこんな発言をしていた。
俺も論理的に間違っているということだな（ｷﾘｯ

>>64
ネタの投下も無しに贅沢な
それに、>>62はプリミティブな関数が自作出来るのが楽しいって言ってるだろ
python版出すなり、新しいネタ出すなりすれば良い

＞それに同じ計算量、無駄を省いたCの処理とかに敵うわけないし
というか『適うわけない』と思った根拠はなんなのだ？
論理的に同じ計算をするならあとはなんというか、言語の基礎体力だけの問題になるはずだが。
あれか、haskellではIntがボックス化されているからとかなんかそういうのか。

>>74
＞まったく同じ計算をするなら同じ処理時間になる
同じロジック書いても
遅延評価を実装するために発生するオーバーヘッドとかの影響で
まったく同じ計算(機械語レベルで)にはならないんじゃないの？

>>77
＞言語の基礎体力だけの問題
そうだよ、そういう話
例え同じロジックでもインタプリタ方式の方が遅いとかそういうの

Cは安全性を犠牲にしてでも速度優先するってコンセプトがあるわけだし

>>-79までの中に、62が居るとのお告げがあった。

>>78
遅延させることに意味がある場合、それはオーバーヘッドとは言わないんでは？
計算結果を明示的にキャッシュするのだってもちろんスペース喰うわけで。
そういうことじゃなくてGHCの実装の深いところに基づくオーバーヘッドだというなら、
俺にもよく分からないが、お前にはそれが有意な差であると合理的に説明できるのか？

>>80
そのレスバグだろ
開始インデックスの指定漏れてんぞ

>>81
意味有る無しに関わらずオーバーヘッドと言うよ
機械語レベルでの違いによるものなら大小に関わらず有意だよ

>>83
呼ぶのか。なるほど。
それは明示的に計算結果をキャッシュするコストと比べてどうなの？

このコストっては手間的な意味じゃなくてね

あと機械語レベルで差が出るというソースは？
簡易なものなら是非見てみたい。

無いと思うならそれでいいよ
haskellはcと同じ速度ってことでさ

まあ説明できないことは最初から分かってたさ

オーバーヘッドがあったとしても遅延評価には利点があるという話だったんだけど
ここまで速度に拘るとは思わなかったからね

あるかどうかもよく分からないオーバーヘッドの話を持ち出したのはそちらではなくって？
まあね。実際俺もあるとおもうよ。オーバーヘッド。
話として持ち出すからには根拠を持っていてほしいなと思っただけさ。

ちなみに俺がオーバーヘッドがあると思ったのは
単にゼロオーバーヘッドでの実装は無理だろうと思ったのと
「c言語 haskell 速度比較」とかでググッた結果を見たというだけ
流石に個々の速度比較の詳細までは知らない

逆にオーバーヘッドが無いってのを示してくれたらもちろん前言撤回するよ

こんなスレにいる駄民がそんなことを示せるわけ無いじゃないか！俺のことだよ！

ていうかよくよく読み返すと>>78は疑問文だねえ。
俺が謝ったほうがいいのかも知れない。
だがわたしは(ry

遅延評価って、一見全部読み込んでから一部だけ出力するって処理で、必要な分しか読み込まないってので、>>62の上のmyreverseはリストを反転する必要があるから、全部読み込んでるけど、下のaddlistをmytake 10 してる方は、最初の10要素分しか読み込まない
先行評価だと、全部読み込んでから始まるか、最初の10要素だけ読み込む様に書き分ける

ファイル処理とかで、書き分ける必要が無い事になる

とは言え、最近の言語なら、オブジェクトにその辺の処理を押し込んでそうだが

オーバーヘッドつーか、評価機構の構造自体が違うのに、
全体の処理時間が同じなわけがないだろjk

正格評価でもありとあらゆるところにdelayとforceを忍ばせれば
遅延評価になると思うんだけど
計算量が減るところだけ遅延評価にした方がやっぱりいいと思うんだよね

>>93
そのかわり、ファイル読み込んで同じファイルに書き出すときとか
「あー、この辺で正格評価するべ」的なこと考えんといかんけどな

配列のreverseくらいならC++でも一行だな
std::copy(in.rbegin(), in.rend(), std::back_inserter(out));

最近の関数型って実装まで気にするような段階なんだな
はてなあたりの選民気取りが「haskellはCより速い(ｷﾘｯ」とか言い始めたら俺もそろそろ関数型始めようかな

速度稼ぐ必要があるコードだと結局はモナド頼りなんだろ？

関数型言語って名前捨てて”モナド型言語”とでも呼べばいいんじゃね？

おめえらhaskell以外の話もしろよ

遅延評価のコストについては、コンパイラの本とかに載ってることあるよ

>>98 大学の研究のレベルから、一般はてな民が話題にするまで10年ぐらいだから、
おまえは常に10年遅れだけど、好きにすればいいと思うよwwww

xmonadの影響で今になってX11プログラミングを始めた漏れが
8時（10分以上遅れ）をお知らせしますね

10年遅れどころかMLなら40年遅れHaskell直系のMirandaからでも30年遅れだろ

作ればあるもん

>>104
登場時期が基準とかおもちゃじゃあるまいし

ギークやらアルファブロガーやら呼ばれる人が話題する時点ではまだ玩具

それを使用する企業やそれなりの規模のオープンソースプロジェクトが
出始めるくらいから実用品だな

Javaと心中するのは自由ですから、他人を巻き込もうと必死にならないでねw

定番の必死認定

このスレでの関数型言語って純粋関数型言語(Haskell,Mirandaとか)だけ？
非純粋関数型言語(Lisp,R,OCamlとか)も含むの？

Haskellはよく知らないけどCommon Lispは実用かなって思って

アンチの脳内の都合で、その場により変わりますw

>>111
あなたの認識ではどっちですか？

関数型言語に定義なんてないし的当だよ

一般的な定義は

・関数を実行時に生成できる
・関数を引数として渡せる
・関数を関数の戻り値として返せる

だと思うけど、最近は勝手に

・変数に一度しか代入できない

とかルールを付け加えたり好きかっていう人が増えたから

昔は、関数型言語と比べて手続き型言語は原始的で貧弱に思えたけど、
最近は手続き型言語もクロージャを取り込んで関数的にも書けるから、
そうなると実用上は手続き型言語で十分だと感じるけどな。

基本は手続き的に処理を書きつつ、コレクションの操作だけ map や filter,
reduce を使って関数的に書く。他人にも読みやすいコードを書こうとすれば
最終的にはそのくらいのところに落ち着くと思うけど。

>>108 みたいな「仮想ドカタ」を煽るのは現実が見えていないと思うなあ。
今時、職業プログラマだって C, Java だけじゃなくて JavaScript も Ruby も使うよ。
JavaScript で言えば、JQuery なんて発想がかなり関数的だと思うけど。
XML を対象に XPath でパターンマッチかけて filter やら map やら。
ほとんどそういう処理。

>>113
上の３つだとJavaScriptやC++(functor)、C#(delegate)あたりも含まれるな
初代スレの1はむしろ参照透過性、変数に一度しか代入できないことの方を嫌ってるように見える

>>113
そうなんだよね。僕もそのくらいが「関数型言語」だと思うんだけど、
逆に、そのくらいはもう、手続き型言語にも取り込まれてるんだよね。

だから、そんなのはもう関数型言語「ならでは」の長所になってない。
逆に、末尾再帰除去とかカリー化とかになってくると、まだ差がある。

とはいえ >>114 くらいのスタイルだと、
別に末尾再帰除去やカリー化がなくても、そこまで困らないけどね。

javascriptはschemeをC言語っぽい文法に直したものだろ
昔から関数型言語と言われているよ

Haskellなどで言う「関数」は、集合・写像ベースの概念だから、変数の書き換えに依存しないやり方のほうが関数を率直に表現出来るってだけの話だ。
Cにも同じ字面の「関数」があるが、関数型言語の関数と区別したい時は、サブルーチンと呼んだ方が実態に近い。

良い所とか取り込んで明確な境界が無くなくなってる面があるんですね

研究目的の言語の成果が実用目的の言語に適用されたと考えたら
必ずしも実用である必要は無いのかもしれませんね

>>117
それは違うかな。
「言われている」ではなく、
関数型言語を知っている人たちが JavaScript は関数型言語っぽいと
「言っている」が正しい表現じゃないかな。

少なくとも、
Ecma-262 の 4 Overview には
http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf

ECMAScript is an object-oriented programming language for performing computations and manipulating computational objects within a host environment.

と書いてあるんだから、何言語かと一つに決めるなら、
明らかにオブジェクト指向言語でしょ。

>>119
「何ができるか」って意味なら差はどんどん無くなってる
だが、他人のコードを読むときには「何ができないか」ってのも重要で、
そこが手続き型言語と関数型言語では違う

わざわざコードを読んで副作用が無いか目でチェックしなくても
言語仕様で保証されてるなら読むのが楽になる
OOPのアクセス修飾子なんかと同じだな

>>120
http://www.ecmascript.org/es4/spec/overview.pdf
ここの４ページにはこうある

ECMAScript 4th Edition (ES4) is a multi-paradigm programming language that is evolved from the
3rd Edition2 (ES3), which in turn is based on JavaScript3, a programming language for the web developed at
Netscape Communications Corporation starting in 1995.

ES3 is a simple, highly dynamic, object-based language that takes its major ideas from the languages Self
and Scheme.

http://ja.wikipedia.org/wiki/ECMAScript

ECMAScript 4 は過去2回仕様作成が挑戦されたが、仕様がまとまらず、失敗に終わっている。

何でも関数型言語にしたがる香具師がいるな…

末尾再帰最適化とか、マジ関係無いだろ
実装上の話だろ

GCC(C/C++) → 末尾再帰最適化あり

あとC++のboost::lambda(ラムダ式)とはどうなんだろうか
言語自体に直接ラムダ式があるわけじゃないけど

boost::lambdaとスマートポインタでクロージャも作れるらしい

壁4はよく分からない

>>126
関数型言語にとってリストが最も基本的な複合データ型であることは、
誰もが認めることだろう
でも末尾再帰最適化が実装されていない言語の多くでは、
可変長配列(RubyであればArrayクラス)でリストを代用している
もしも、これを真面目に「ドット対の連なり」としてリストを定義して
その操作を再帰関数で定義した場合、ちょっとしたデータ量であっても
簡単にスタックオーバーフローが発生してしまう

だから、関数型言語で書かれたコードを末尾再帰最適化が実装されていない言語へ
移植しようとした場合、再帰ではなくfor/while文のような手続き型構文を使わざるをえない
これは(末尾再帰最適化という)実装がプログラミングスタイルに大きな影響を与えるという
典型的な一例であると思う

>>128
>関数型言語にとってリストが最も基本的な複合データ型であることは、
>誰もが認めることだろう

認めねーよ。
それも実装上の話だろ。

>>128
でも、機械を上手く動かすためのコンパイラの技術だろ
関数型言語の定義に含めることには違和感がある

リストは副作用を嫌う関数的プログラミングがLISPから借りてきた実装上の「逃げ」。
末尾再帰最適化でループの代用にしたのと根っこは同じ。

ま、実用を目指したコンピュータ言語なんてものは
全てが実装上の話になってしまうんだけどな。

末尾再帰なんてC言語の教科書で知ったから
関数型言語と結びつけるイメージが全く沸かない

128は本質をついている。
リストは再帰的データ構造を持つので、
再帰を反復の記述にとる関数型とは相性がいい。

関数型言語にとって副作用が無いことは
本質的なことなの？
そうだと言える根拠とかあるの？

MLやHaskellが設計された頃の流行りだった
だけじゃないの？
”副作用は悪”っていう思想は、古いアルゴリズムの
教科書にはよく載ってる

>>134
反復もリストも、圏論の抽象力の前では、単なる実装上の都合だよ

>>125
壁３は本質的じゃないね。それよりも

--- 壁3'. 宣言性(記述順序に左右されない)の壁

を入れたほうが関数プログラミングの本質に近づくと思うのだが。

>>137
宣言という言葉をあまり狭義に使うのはどうかな。
IBMの簡易言語RPG(現在バージョンはIVかな)は
Decision Tableを使って制御を行っているので、
昔は宣言型言語に分類されていた。同じ宣言でも
こうまで異なると問題だ。

定義のことを宣言って言ってるだけじゃね？

英語でどうなんだか知らんけど。

CTMCPすら知らずに妄想する隔離スレか。

抽象度が高いことを示すコードが出てないんだが
pythonに作れなくて、Haskellに作れるものって何がある？
とりあえずHaskellでif関数自作できるとかはよく見かけるが

if関数ったって組み込みの（型クラスを含む）条件分岐機構を使わずには書けんだろ。

>>140知らなかったので、検索して目次を眺めてみたが、スレタイのような議論をするなら読むべきかと思った。

>>142 ARMなら条件分岐なしのコードにコンパイルできるんでね？

つーか、関数型言語の利点と言えば、バグが無いことを保障できるって事じゃね？
数学の証明で公式が永遠に正しいことを保障するのと同じで、関数にバグが無いこと保証できれば、その関数の使い方を間違わなければ、その関数が原因のバグは無いと保証できる

分岐を関数で表現するのは難しくない。
T（x,y）=x
F（x,y）=y
IF（c,x,y）=c（x,y）
最後のは糖衣構文で、cはTかFが入る。

問題はこれを先行評価すると、
xの評価、yの評価、どっちかの選択と
進行してしまい、無駄な評価またはやっては
ならない評価をしてしまうことになる。

遅延評価では必要になるまで引数は評価されず、
c（x,y）にはxかyの一方しか含まれないので、
上記の問題は起こらない。

すでにコメントされていたか。

元ネタ書いたの誰か知らんが >>125 は酷すぎる。
上下に並べている壁が、それぞれ軸が違う。
壁２は型システムの問題だろ。
壁４も意味不明。
末尾再帰最適化の有無を越えられない壁とか書いてるのもアホ丸出し。
末尾再帰になるような処理は手続き型なら最初からループで書く方が自然。
だから要らないだけ。

型推論とオブジェクトの相性の悪さが問題だな
誤解を恐れずざっくり切るなら、
オブジェクト指向が適している分野に関数型言語は不適。

せんせー、OCamlさんが泣いてます

>>145
パターンマッチがすでに条件分岐機構なんだが…
条件分岐機構使って条件分岐書き換えてドヤ顔されてもな。

>>147
Smalltalkの宣伝乙w

一般論を書いたつもりだがどの部分がsmalltalk?

一般論を書いたつもりだがどの部分がsmalltalk?

T（x,y）=xがTrueクラスの定義
F（x,y）=yがTrueクラスの定義
IF（c,x,y）=c（x,y）がメソッドの動的束縛に相当した実装になっている。

具体的には、if式はifTrue:ifFalse:というメソッドで実装されている。
これがTrueクラスでは、第1引数のクロージャを評価するよう定義されていて、
Falseクラスでは、第2引数のクロージャを評価するよう定義されている。

クライアントコードでは例えば
x = y ifTrue: [do something] ifFalse: [ do something else]
というメッセージ式を評価する時に、
x=yがtrueならTrueクラスのifTrue:ifFalse:が束縛されて
第1引数の[do something]が評価される。([ ]で囲まれたものはクロージャ)
x=yがfalseならFalseクラスのifTrue:ifFalse:が束縛されて
第2引数の[do something else]が評価される。

>>154
Smalltalkで勉強したからそう言っただけだろ
プログラム言語が開発される以前に、ラムダ理論で
既に知られていたなんて知らなんだろ

>>157
いや、知ってたよ。
つーか、俺自身がSmalltalkより先に型なしラムダ計算やってたし。

現代の実用言語では>>147の定義の実装がSmalltalkに色濃く残っている
というだけの話にそこまで突っかかるかね？
関数型の人(特にLISP系とHaskell系)ってそうやって上から目線で小馬鹿にするから
逆に相手から冷笑されるんだよ。

悪いけどJava屋の俺からするとSmalltalkの人も同じだよ。
＞上から目線で小馬鹿にする

どっちも原理主義者で純血主義者ですもんね

ハスケラやSmallTalkはわかるがLISPerは純血主義の対極だろｗ

LispもHaskellも習得のコストさえ無視できれば
言語自体には使う価値があるけど
Smalltalkには何も無い

よほどSmallTalkに叩かれた暗い過去があるんだねｗ
もしかしてIDEスレじゃね？ぷぷぷ あのスレのジャバ厨は悲惨だったｗｗ

そんなにスモールトーク叩きたければ別スレ立てれば？

スレ違いウザｗ よほど悔しかったんだねｗｗ

Smalltalkを頭ごなしに馬鹿にする奴でSmalltalkをまともに使ったことある奴を見たことがない。

Pharoがゴミ過ぎて笑える
玩具で喜んでて滑稽

負け犬>>166の遠吠え

「俺は世間の奴らとは違う」という自尊心を満たすために
マイナーなものを選択するという変な層がいるから性質が悪い。

そういう人にとっては「世間はJava」でなければ困るわけだ。
「RubyでもJavaScriptでも普通に関数的にも書ける」と言われると

「中には手続き型言語で関数的に書いている人もいるだろうが、
それは(俺と同じ)一部の先進的な層で、世間一般はJavaだろ」

という主張をしてくる。自分が特殊でありさえすれば何でもいいというね。

自己紹介乙としか言いようがないw

関数型言語由来の機能で便利なところってのはクロージャとラムダ。
それはもう手続き型言語で普通に使える。

関数型言語の便利な機能は、
既にメインストリームである手続き型言語に取り込まれ、
今では世間一般のプログラマも当たり前に関数的な書き方をするようになっている。
めでたしめでたし。

現実的には、もうこれで終了してる話だろ。

パターンマッチは便利なので手続き型言語にも取り込んでほしい

で、パターンマッチは再帰と相性良いので、
ついでに末尾再帰最適化も取り込んでほしい

汎用的な関数から具体的な関数を定義するのに
カリー化は便利なので是非とりこんで欲しい

>>171
末尾再帰最適化はC/C++でやってるし
上でも出てるけど関数型とは無関係

＞汎用的な関数から具体的な関数を定義するのに
＞カリー化は便利なので是非とりこんで欲しい

こういう奴にカリー化という包丁を渡すと
オレオレ高階関数ライブラリを作り始めて
メンテナンス不可能なコードを量産されるのがオチ。

逆にダックタイピングは便利なので関数型言語にも取り込んでほしい

あ、型推論できないから取り込めませんね。失礼

>>175
構造的部分型で良ければOCamlで出来るけどな > ダックタイピング
もちろん型推論もできる

>>174はダックタイピングの誤用だな

>>172
パターンマッチ無いのに末尾再帰最適化だけ出来ても
正直そんなに嬉しくない

パターンマッチと再帰は無関係だし
視野が狭すぎ

代数的データ型使わないのにパターンマッチがあっても何も嬉しくない

代数データ型と再帰構造は直交する概念だろｗ
どこまで視野が狭いんだかｗ

>代数データ型と再帰構造は直交する概念だろｗ
>どこまで視野が狭いんだかｗ

何それ？
代数データ型を使って
再帰構造を表現することはできないって事？

便利な機能が全部ある言語を選んだらHaskellになった

いらない機能を全部つめこんだらSmalltalkになった

>>181
パターンマッチと再帰は直交する
代数的データ構造と再帰は直交する
パターンマッチと代数的データ構造は直交しない

>>156
ありがとうございます。
Smalltalkって、C++やJavaの先祖くらいにしか思っていなかったけれども、
結構おもしろいですね。FPとOOPはレイヤーを積み重ねると互いに相手を
模倣できるという話を聞いたことがあるが、Smalltalkを学習すると
その意味がわかるのではないかという気がした。

あちこちのスレを読んでいると、
Smalltalkの説明に対してだけ、丁寧な言葉でお礼が書き込まれることが多い。
この傾向が、とても面白いと思う。

> 関数型言語由来の機能で便利なところってのはクロージャとラムダ。
> それはもう手続き型言語で普通に使える。
体験するにはどういう言語がいい?知っている範囲では、
C++11: lambdaはあるが、スコープにかんするオプションがいっぱいあって
　頭痛がしてきた。
Fortran: Intel拡張に限り、内部手続きが渡せるのでクロージャが部分的に
　はあるといえる。うっかり使ってしまうとSparcマシンに移したときに
　がっくりくる。

結局はどの言語を使うかではなく、関数型的な考え方書き方が出来るかどうか、が問題になってくんだろうかね？

できなくても、ほとんど問題がないのが現実

>>166
Smalltalkといっても、実験的要素の多いSqueakやPharoとかばかりじゃなく、
VisualWorksとかDolphinみたいに商用志向の比較的作り込んである処理系もあるよ。

>>192
実行ファイル単位でしかスレッド数を決められないのか
イマイチだな…

一応増やせはするんだけど、
一度増やすと今度は減らせないんだよねえ・・・
そのうち改善はされるかもしれないのだけど

一般に一旦プロセスに割り当てたリソースをひっぺがすのは難しい

並列計算でスレッド数をcpuのコア数以外にすることがあまりないので、
よくわからないのだが、OpenMPのようにいったんスレッドを畳んで、
スレッド数を指定して再度スレッドを起動するのは難しいのかな。

リストなので単純にはいかないとおもうが、
!$omp parallel map
ys = map f xs
!$omp end parallel map
とかできるようになると結構うれしい。

ユーザスレッドを駆動するネイティブスレッド数の話だろ？
なら、動的な変更はそれほど必要ないんじゃ？

不毛だな

ふもっふ

catコマンドって、意外と奥が深いんだな・・・
こんなの見つけたんだけど(haskell)、他の言語だとどう書くの？

A cat in Haskell
http://madscientist.jp/~ikegami/diary/20050728.html#p01

ちなみに、このページはここからリンクされてた
Haskell
http://pub.cozmixng.org/~the-rwiki/rw-cgi.rb?cmd=view;name=Haskell

cat（オプション付き)って所

>>200
オプション無しの、単純に引数のファイルを繋いで出力するだけのものなら
AWK、Perl、Ruby辺りはアホみたいに短いな
(コマンド名含めて数バイト)
流石に複雑なオプション含むとそこまで差は出ないかも知れんが

>>200

正規表現を並べただけだけど、Perl だとこんなかんじ。
http://ideone.com/BCiGc

とりあえず -u と -v のメタ表示以外サポート(もとの Haskell でも
サポートしてなかったので)。

ちなみに Snow Leopard の cat には -A -E -T が存在しなかった。
Lion 以降?

>>201
オプション無しだとスクリプト言語よりは長いものの、静的型言語としては短いだろうな
と言うか、ここの一番上のruby版catは短すぎてなにやってるのか分からん
下2つのcatコードの方がコードの意図を読み易いな

http://www2.atwiki.jp/kmo2/m/pages/17.html


import System.Environment

main = getArgs >>= mapM readFile >>= putStrLn.unlines

奇しくも、do構文で見えにくい状態移管が見えやすい形になった

とりあえず >>200 のバグ。

1. -v と -t の結果が同じになる。本物の cat は -v では TAB を変更しない。
2. 入力が改行で終わっていないときに、勝手に改行を追加してしまう。
3. -e をつけたときに、入力が改行で終わっていなくても最後に $ をつける。

>>204
いや、静的だろうが何だろうが、この半分の長さで書けるでしょ。
もともとの >>200 が、シンプルに書く気がないみたいだし。

>>204
> while gets do puts $_ end
これのことか？Perlじみた動きをするコードだね

getsは一行入力する
EOFならnil、入力があればそれを文字列型として
グローバル変数 $_ に突っ込むと共に、戻り値としても返す

Rubyの文字列型は必ず真であり、逆にnilは必ず偽なので
while gets は「EOFになるまで毎行を $_ として繰り返す」イディオムになる
あとはそれをputsで出力してるだけ

>>207
それ自体は分かるよ
スクリプトだからなんだろうけど、標準入力とファイル読み込みの区別が無くて戸惑う
どこでファイル読んでるの？って

昔はプログラム側でファイルを開いたりしないものだったので、
たんに伝統的なやり方とも言える。

>>208
？ 標準入力とファイル読み込みの区別はむしろしっかりされてるコードだと思うけど…
ファイルからの読み込みならいきなりgetsなんて書かないよ
その場合はファイルを開いて、それに対してメソッド呼ぶのが基本
標準入力から読むからこそいきなりgetsを書く
まあ確かにgetsの読み先をファイルに繋ぎかえることも出来るし
逆に標準入力をIOオブジェクトとしてメソッド呼ぶとかも出来るけど
このコードではそんなことしてないっしょ？

ああ、ごめんそゆことか
標準入力じゃなくてARGFからの読み込みの話だったね

ええとgetsは既定ではARGFから読む
んで、その内容はファイルを渡していないなら標準入力、渡されればそのファイルを全て繋いだものになる

多分Perlの<>辺りがARGFの由来だろうなあ

>>211
HPに説明があったから良かったものの、所見であのコードだけ見てたら混乱してた
個人的には、>>204のページ探してるときに見つけた

http://uch-x40.seesaa.net/article/22908221.html
こっちのページのやり方の方が好きかな

このページのprintをputsにするだけで問題解決するんじゃないか？と思ったので、久しぶりにruby入れて試してみたら、
予想通り解決した

puts ARGF.read

これで、

>ruby cat.rb mycat.hs myecho.hs
import System.Environment
import System.IO

main = getArgs >>= mapM readFile >>= putStrLn.unlines
import System.Environment

main = getArgs >>= putStrLn.unwords

Haskell版と、ちょっと挙動が違うけど・・・
（Haskell版のputStrLnをputStrに変えれば同じになるけど、どっちが正しい挙動なんだろ)

あー・・・ごめん
ruby版、問題解決してないや
EOFで改行されないから、
import System.Environment
import System.IO

main = getArgs >>= mapM readFile >>= putStrLn.unlines[EOF]<-ここにEOFがある

この条件だと下のような表示になる

import System.Environment
import System.IO
↓ここから次のファイルが始まる
main = getArgs >>= mapM readFile >>= putStrLn.unlinesimport System.Environment

main = getArgs >>= putStrLn.unwords

>>213-215
率直に言う

　関数型言語が使える使えないうんぬんの前に、常識的な(日本語の)文章表現を使えるようになれ

単にコードをコピペしただけで、自分の意図が相手に通じると考えるな
まともなヤシなら以下のような推論を自然に行って、それを文章で表現できる

・.... を期待して ..... という条件で (* 仮説1 *)
・..... というコードを試したが.....となり、期待にそぐわなかった -- (* 実験1 *)
・おそらく ..... が原因ではないかと思う (* 帰納1 *)
・そこで、新たに .... を期待して ..... という条件で (* 仮説2 *)
・..... というコードを試したところ .....となり、期待どおりの結果を得た -- (* 実験2 *)

ここまで言って分からなければ、お前さんは重症の「ハスケラ症」患者であり、
本人には自覚できない深刻なコミュニケーション不全の状態にある
とっとと隔離病棟(=Haskell本スレ)に戻ってオナニーでもしてるのがお似合い

このスレが隔離病棟だという認識がない、ってあたりが重症だなw

型は制約 #プログラミング初心者のミス

↑
Zermeloを初心者呼ばわり、ワロスｗ

型付集合論自体がラッセルの逆説を回避するための制約ですし．

disることでしかアイデンティティを保てない可哀相な奴なんだよ。

オブジェクト指向 ＃プログラミング初心者のミス ←これとか

いやオブジェクト指向は糞

そうそうクラスとかインスタンスとかメソッドとかの用語を使う言語は100%糞！

いまどきは、組み込みみたいなリソースの厳しい案件でも使うけどな。

オブジェクト指向言語は使わなくても、設計では使うだろ

制御系やっているけど、OSはRedHatなのに、言語はCとアセンブラだ。

俺はよく知らんのだが、関数言語アンチとんの連中なの？
twitterやブログでも写真でもいいから見せてくれないか？

オブジェクト指向とは別名スパゲティ指向だと言われてる。

ねーよ

オブジェクト指向でスパゲティにするような奴は、ループ構文使おうが、例外を使おうが
スパゲティを作るんだよ。馬鹿は何を使っても同じ。

gotoやグローバル変数全盛時代、スパゲティコード生産しまくってた連中は
自分達がスパゲティ製造者だという自覚がなかったという

gotoでスパゲティにするような奴は、関数呼び出しを使おうが
スパゲティを作るんだよ、とか言ってね

お前ら立派なスパゲティ職人になれよ。
一芸に秀でりゃ食っていける。

関数型言語は別名ゴルフ指向言語と言われているなｗ

>>230
>gotoでスパゲティにするような奴は、関数呼び出しを使おうが
>スパゲティを作るんだよ、とか言ってね

いや、まさにその通りだろ。

スパゲティで塩やきそばを作ると結構いける

>>230
スパゲッティ・コードというのは、ウケ狙いの後付表現に過ぎないからな。

gotoを使ったからスパゲッティになった、なんていう理屈だと、
あと10年くらいして改善された手法が一般的になったら、
今コード書いてる連中は殆どスパゲッティメーカーになってしまう。

スゲパティシエ

>>235
いや、だから関数型言語使ってる連中がOOP使ってる連中に
「お前等スパゲティコード書いてるぜ」って言ってるんだろ？

スパゲティコードは読み辛く、読み解ける人は限られていた
一方、関数型言語のコードはそもそも読める人が限られていた

広まるといいですね関数型言語

関数型だって普通にスパゲッティになるしｗ

haskellのdo内はなぁ。。。 関数型スパゲティの宝庫だね。
ナポリタンにしますか？ミートソースにしますか？それとも、カルボナーラにします？

何故Haskellのdo内でスパゲティになるか
理由を>>240は説明できないだろう

関数型言語に馴染まないものを無理に突っ込んだ悪足掻きだからさ
生まれ付いての汚れ役だね

doはただの関数合成の構文糖なんだが
関数の合成が関数型言語に馴染まないとは面白いことを言うなぁ

まあ、>>242はdo構文を普通の関数合成の表記に
書き直す事すらできないだろうけど

流石は関数型言語ユーザー様
上から目線が板に付いてますねｗ

永遠に学習しない態度が板に付いている奴はほんとカスだな

>理由を>>240は説明できないだろう
>書き直す事すらできないだろうけど
>永遠に学習しない態度が

決め付けも大好きみたいすねｗ

構文糖衣が必要なのは相性が悪いからじゃないの？

良く使うから構文糖が用意されるって話は分かるが
相性が悪いから？なにそれ？

じゃあ何か。C言語で x=x+1 を x++ と書けたり
*(x+1) を x[1] と書ける構文糖が用意されてるのは、
C言語がインクリメントや配列と相性悪いからか？

>>248
> じゃあ何か。C言語で x=x+1 を x++ と書けたり

その２つが同じセマンティクスだと思っているのなら
もう二度とコードを書かないほうがいいぞｗ

x86ならおんなじじゃないの？

>>249
ああごめん。++xだったね

>>251
大分近くなったが、まだセマンティクスは完全に一致してないのだが…
マジでプログラマやめたら？

xが整数かポインタかで細かいところは変わるし、そこまでこだわる理由も無いように思うがw

Cリファレンスマニュアル5th edition読む限りでは ++x と x+=1 と x=x+1 は
等しいと読めるし、今手元に無いから記憶だけど規格書でもそうだった気がするが...
xが整数かポインタかで変わる？ありえんだろ

整数ならインクリメント命令にできるが、ポインタだとそうはいかない。

>>249 は x=x+1 において x の評価が 2 回起きる、と言いたいらしいが、
ここでは x は任意の式ではなくて、ただの変数なので、その違いは無い。

結論。>>249 は今すぐプログラマをやめて、一生 2 ちゃんねるもプログラムも書くな。

>>255
ポインタでもできるよ？何言ってんの？

そりゃ 4 増える「インクリメント命令」がありゃ、int を指してるポインタでもできるが。

ん？今は x=x+1と++xの違いの話だろ？
どっちもxがポインタなら sizeof(*x) だけ増加する

>>255
> ここでは x は任意の式ではなくて、ただの変数なので、
なにか鬼畜なマクロかもしれませんよ。小文字一字なマクロは私の好みではありませんが。

仮に (1+1) に展開されたら ++ なんてできない。以上

>>255
ねえ、君、本当にプログラマ？
プログラミングで給料取れるレベルじゃないよ。

>>259
マクロの引数だったりすると、小文字一文字はよくある話だなｗ

結局具体的には全く反論できないんだなw >>261

セマンティクスの話してるときに
字句レベルの置き換えであるCマクロ持ち出す馬鹿は
プログラマに向いてないから辞めた方が良い
まともに言語規格書読めないだろ

例えば
#define double int
とされてたら double x; でも x はdouble型とは言えない、
とか言い出すレベルでバカなわけで

セマンティクスとしては x の評価を 2 度する、というのは変わらんじゃないのかな。
その評価が状態に対して idempotent かどうかという違いであって。

>>249
その２つのセマンティクスの違いって何なの？
そろそろ答え教えてくだしあ

結論： 教えてクレクレ君は二度とコード書かないほうがいい馬鹿

>>264
> セマンティクスの話してるときに

ダウトｗ
構文の話をしていた>>248にセマンティクスを持ちだしたのが>>249だｗｗｗ
あまりにも馬鹿すぎるｗｗ

>>248
> 良く使うから構文糖が用意されるって話は分かるが
> 相性が悪いから？なにそれ？
> じゃあ何か。C言語で x=x+1 を x++ と書けたり

↓これがいつのまにか

>>264
> セマンティクスの話してるときに
> 字句レベルの置き換えであるCマクロ持ち出す馬鹿は
> プログラマに向いてないから辞めた方が良い

構文糖って「字句レベルの置換え」だよねｗ

> プログラマに向いてないから辞めた方が良い
> プログラマに向いてないから辞めた方が良い
> プログラマに向いてないから辞めた方が良い
> プログラマに向いてないから辞めた方が良い
> プログラマに向いてないから辞めた方が良い
> プログラマに向いてないから辞めた方が良い
> プログラマに向いてないから辞めた方が良い
> プログラマに向いてないから辞めた方が良い
> プログラマに向いてないから辞めた方が良い

構文（syntax）と字句（lexical）の違いも分からないとか
マジ終わってんな
yaccとlexも知らんのか

>>267
じゃあ僕が良いこと教えてあげる
>>249のようなレスしても論理的な説明しなかったら説得力0なんだよ^^

教えてクレクレ君とバカにすれば、どんな間違いを言っても逃げきれると思っているバカが一人w

>>270
へー、字句解析に手を入れずに構文糖衣かw
馬鹿が考えることは壮大だねえww

お前、完全にプログラマー失格。

プログラマ失格のバカはどう見てもおまえだw

>>274
いいから涙を拭けよ

見ていて痛々しすぎる
そうやって涙目で必死に弁解するぐらいなら
本当にプログラマー辞めればいいのに

その言葉が自分にあてはまってると気付かないあたり、完全に重篤の患者ですなw

>>276
どうしてプログラマーになろうなんて思っちゃったの？
間違いを正すのは恥ずかしいことじゃないよ。
だから今すぐ辞表を書きなさい。

>>277 >>277

最近の関数型言語は辞表も書けない

そうやって無限退行することしかできないんだな

なんか気持ち悪いのに粘着されてんな

つーか書き込みから漂うドカタ臭で鼻が曲がるから
もうちょっとマトモな職に就いてから書き込んでくれ

pythonpython言ってた人はどこ行ったの?

人口が少ない言語。一人減っただけでとたんに静になる。

結局、蓮ケラはx=x+1とx++の区別がつかないのねｗかわいそｗｗ

>>265 が理解できないならプログラマやめたほうがいいよ

ところで何故にセマンティクスの話をし始めたの？

構文糖って言葉を聞きかじって、使ってみたかったんだろ。察してやれｗ

検索してみたらセマンティクスって言い出したのは
>>249のアホじゃん

x=x++++++1

>>289はこう解釈されます

x=((x++)++) + +1

出来るやつならどっちも使える上に、C++のほうを好むと思うがね。

どっちもできるけどC言語のが良いってヤツ存在してんの？

Linus

お前らプログラマなの？

>>290
x++はsequence pointじゃない
ひとつのsequence pointに複数のside effectsを含むのは
未定義動作

>>292

レベルの低いヤツに合わせるためにあえてCを使ってるだけで、Cの方が良いってわけじゃないんでは？

Cの方がいいに決まってるだろｗ

関数型言語は遅いからね。
C言語に比べて100倍以上遅い。

やっぱりx=x+1と++xは式としてのセマンティクスが違うんだね。
納得。

そりゃそうだろう。

そもそも++というのはなんで存在するか。

まず1追加するというのはプログラムでよく出てくる処理。
ならばそれを高速にしようと、専用のアセンブラ命令(INC)を作った。
足し算はADD

昔のコンパイラは馬鹿だから+1を++に変換するなんてことはしない。
+1と書かれていたらADD、++と書かれていたらINCに
単純に置き換えるのみ。

さらに、CPU によっては命令の実行ごとにレジスタが自動的にインクリメントされるアドレッシングを備えるものもあった。

んで、ここ何のスレだっけ

>>298>>299
Cとは何かを決めてるのは言語規格書
違うというなら規格書を引用して説明しろよ

こんなトリビアルなピープホール最適化を「昔のコンパイラは馬鹿だから」だなんて
言っちゃうのは、コンパイラのことを全く知らないド素人です、と大声で宣伝するに等しい。

>>302
一番最初にCが作られた時に
言語規格書なんてないよｗ

規格書は後から作られたものです。

ピープホール最適化なんてのは
Cが一番初めに作られたときはなかったな。

> 規格書は後から作られたものです。

だから何。
規格を作る時に既存の実装を無視して作ったとでも思ってるおバカさん？

>>306
頭が悪いね。

（規格がない時代の）既存の実装がどうしてそうなっているか。
C言語は高級アセンブラと言われるように、
アセンブラを記述する代わりとして使えるように
コンピュータよりで仕様が作られている。ポインタとかね。

で、その一つが++という命令。CPUがインクリメントを速く実行できる
命令があるのなら、それに対応した文法をC言語に持たせるの自然な発想。

Cが作られたのは1971年だぞ。どんだけコンピュータが遅かったか。
その時代に、時間がかかる最適化処理をコンパイラにやらせるわけないじゃないか。
当時は人間が頑張ってC言語上で最適化する時代だったんだよ。

1973年だった。

現時点で規格書があるのに、それを無視して
昔はこうだったと言い出す奴は100%仕事できないだろうな

どうしてそうなっているかという
過去の話をしているのだから、同然だろ。

規格書を引用すればすむ話なのに？

そうそう企画なんて後付け、企画？

>>311
すむと思うなら自分でやってみれば？

そりゃ違う言い出したほうが出すべきだろ
書いてあるんだろ？違うって

「規格書に書いてある」と言い出した人はだれですか

規格書がない時代から++はあるのに、
規格書で決まってるんだから～って
言ってる奴は間抜けだなｗ

規格書に書いてなかったら同じとも違うとも言えんだろ
馬鹿じゃないの？

>>316
>>309

>>317
ほう。つまり君は規格書に書いてあると言いたいわけだな？
引用して見せてよ。

>>319
規格書に書いてなかったら「未定義」だ
でも「違う」と言い切ったんだろ？だったら書いてあるんだろうが

>>318
だからね。規格書がない時代にどうして++が生まれたかの話をしてるんだよ。
規格書は後から作られたもの。

教科書にそう書いてあるから正しいんだとか言うなよ？
恥ずかしいからｗ

>>320
もしかして「セマンティクス」の意味がわかってないのかな？

>>321
> だからね。規格書がない時代にどうして++が生まれたかの話をしてるんだよ。

>>249から読み直したが、全然そんな話じゃなかったぞ
それとも>>249は規格書がない時代のCの話をしてたのか？

とんでもない間違いを何度も晒されてしまう>>248がかわいそうすぎｗｗ

> Cが作られたのは1971年だぞ。どんだけコンピュータが遅かったか。
> その時代に、時間がかかる最適化処理をコンパイラにやらせるわけないじゃないか。
> 当時は人間が頑張ってC言語上で最適化する時代だったんだよ。

嘘八百をご苦労さーんw

世界最初のFortranコンパイラが、「コンパイラなんてそんなものか」と
バカにされないために、最適化に苦心した、という話とか、最適化を
勉強していれば普通は常識。

結局、シンタックスシュガーの話をしているところに
規格書がない時代のセマンティクスの話をしだして
>もう二度とコードを書かないほうがいいぞｗ
とかドヤ顔で言っちゃったということか

よう、俺に振り回された気分はどうだい？ｗ

事の発端はこれか。確かにこれは馬鹿すぎる。

>>248
> 248 名前：営利利用に関するLR審議中＠詳細は自治スレへ [sage]： 2012/04/07(土) 01:20:29.83
> 良く使うから構文糖が用意されるって話は分かるが
> 相性が悪いから？なにそれ？
>
> じゃあ何か。C言語で x=x+1 を x++ と書けたり
> *(x+1) を x[1] と書ける構文糖が用意されてるのは、
> C言語がインクリメントや配列と相性悪いからか？

スレタイすら読めない奴って、他スレで負けて逃げてきた連中だろうな。

自分が負け続きで逃げっぱなしなので、必死でそのように思い込もうとしているのですねわかります

リーナスがこのスレに書き込みしてるのか？

セマンティクスとは「データの意味」のことであり，

適材適所

>>328
これって、聞いた話だと、とあるCPUにレジスタの値を＋１するだけの特化命令があって
その命令に対応させるためだけに作った構文なんだってね

むかしは、構文木とかもメモリがないから、一行分づつに作って、マシンコードを生成してたから
そういう命令が必要だったんだとか

>>334
最後の行訂正
命令→構文

とあるも何も、大抵のCPUにはインクリメント命令ぐらいあるだろｗ
しかも、x += 1はステートメントじゃないしｗバカすぎｗ

最近のCPUは特化命令としてはないんじゃないの？
もちろん、命令デコードの段階で判断して、高速に実行するだろうけど

昔のCPUと違って、アセンブラ用コードに一対一で対応したマシン語で実行してる訳じゃないからなあ。

++とか--が用意されたのは

「アドレスレジスタが指す領域の値を参照/更新したあと、アドレスレジスタをインクリメント/デクリメントする」

「アドレスレジスタをインクリメント/デクリメントしたあと、アドレスレジスタが指す領域の値を参照/更新する」

上記あたりを1命令で実行可能なCPU向けに
最適化とか無しに上記の命令へダイレクトに解釈されるプログラムを書けるよう
用意されたものだと思ってた

大昔のPDP-11の頃はそうだったかもしれない、けど、1980年頃にはどうでもよくなって
たんじゃないかと思うけど。

後置の場合に変化前の値が式の値のなる点を除いて。

-----------まとめ----------
「馬鹿は死なねば治らないのであり、だからこそアナトール・フランスは
『愚かな者は、邪悪な者よりも忌まわしい』と言ったのだ。
　邪悪な者は休むときがあるが、愚かな者はけっして休まないからである。」
(ホセ・オルテガ・イ・ガセット 1883～1955)

http://toro.2ch.net/test/read.cgi/tech/1336122899/247
＞ゲームは作らんから知らんが、
224 == 247 == 704 == 717 == http://logsoku.com/thread/toro.2ch.net/tech/1335361193/46
口癖はコンポジション、ミサイルとホーミングミサイルの設計について1ヶ月間も考え続けてる
http://toro.2ch.net/test/read.cgi/tech/1336122899/772
＞ゲーム作らなくてもお前よりマトモ
タスクの実行順序を意識しないとゲームが作れない（笑）
http://toro.2ch.net/test/read.cgi/tech/1336122899/767
敵機　→　プレイヤー　の順序でタスクを実行するとタスクがぶっ壊れる
OOを得意げに語っているつもりが、やっている事が20年前のC言語だったという事実
バイナリの書き換えがわからない
コンパイラ言語のことをコンパイル言語とか言っちゃう
タイプミスの数々、右手の人差し指と中指をケガしてる模様
http://toro.2ch.net/test/read.cgi/tech/1336122899/190
http://toro.2ch.net/test/read.cgi/tech/1336122899/297
http://toro.2ch.net/test/read.cgi/tech/1325246820/837-839
http://toro.2ch.net/test/read.cgi/tech/1336122899/318-320
http://toro.2ch.net/test/read.cgi/tech/1336122899/332-334
http://toro.2ch.net/test/read.cgi/tech/1336122899/818
http://toro.2ch.net/test/read.cgi/tech/1336122899/956

なんで関数型の人は他パラダイムを全部「命令型」と呼ぶの？
こないだPrologまでリストに含めて「命令型」と呼んでる人がいて
ツナマヨ思いっきり噴いちゃったヨ

そいつが素人あるいはニワカなだけだろ
実際、そのカキコは誰からも相手にされていなかったしね
例外的な馬鹿一人をつかまえて、すべてが同じと考えるのもいかがなものかと

SQLは何言語になるのかね

ドメイン特化言語

確かに関数型言語が汎用である必要は無いのかもね。
汎用言語って括りだと、コンピュータの動作原理を考えても、
やっぱ手続き型が主流になるのは目に見えてるしな。
SQLみたいに何かに特化してしまってよいのかも。

関数型言語はアホには理解できないという意味で
汎用的じゃないな

つまり研究用に細々と使われるのがお似合いということ

>>346
と言うか手続き型で全部やることすら本来なら旧世代の考え方かと
(それが今も濃く残っちゃってるのだけど)
インラインアセンブラみたいな形で
本質的に手順を必要とする部分は手続き型、本質的に式を必要とする部分は関数型、
本質的に論理を必要とする部分は論理型、ごく低レベルな処理を必要とする部分はアセンブラ…

ってやればいいのではないかと思う

普通にCとHaskellを組み合わせて使ってる

バカは、他人がみんなバカということにしないと気が済まないから、
>>348 のような発想を、よくするんだよな。
80年代に、BASICさえ使えれば万全、とか言い張ってた人にそっくりだ。

つまり関数型言語を理解出来ないバカは少数ということ

それなのにユーザーが少ないのは使えない玩具だから

>>352
自分がその少数のバカに属する気分はどう？

へたくそな煽り乙ｗ

ふむ。関数型言語が理解できるって強がり言わないだけ素直でよろしい
バカの上に嘘つきで意地っ張りとか救いようが無いからね

関数型言語が理解できるって言うと、強がりになるの？

理解してない奴が言ったらそうなるだろう
関数型言語に限らずOOPLでも数学でも何でも

理解できない人って居るのかなぁ。
副作用がない分、簡単なんでしょ？

>>358
> 副作用がない分、簡単なんでしょ？

これ疑問系で訊くってことはお前は理解できてないんだろ

だから理解できない奴は居るよ。お前のことだよ

それ言ったらアセンブラだって簡単だよ
概念自体は理解できても、やりたいこと実現するとこまでいけないのが大概でしょ

手続き型でもそういう初心者が居るように
手続き型に慣れてても関数型という新たな概念に触れた人は関数型初心者になる
関数型のコードに慣れない内は「無理！わからん！」になるのは何らおかしくはない

でも関数型って基本的に手続き型から副作用を取ったものだから、
手続き型が出来れば関数型も出来るよ。
むしろ手続き型のほうがあれこれ副作用に頭を悩ませなければならないから
使いこなすのは難しいと思う。
そりゃ関数型で無理に副作用っぽい物を表現しようとすると難しいけど、
それは使い所を間違っているだけだからねぇ。
副作用を狙う箇所は手続きで書けば済む話だし。

ていうか OCaml 使えよ、っていう話だろ

だって、関数型が難しいって論調だったから。

ルーピーで関数型を気取られても

関数型って気取るものなのですか？

手続き型言語での状態書き換えを、「副作用」と呼ぶ事自体が迷走の始まり。
手続き型と同じアプローチで関数型言語を無理やり使おうとすると、関数型言語にとって副作用でしかないものが必要になるだけの事。

おっとScalaを勘違いして採用した現場の悪口はそこまでだ

勘違いして使ってりゃ、悲惨なことになるのは何でも同じだな。

>>367
Twitter社のことか

関数型コミュ、特にハスケラのdisり大好きっぷりを見ていると、
こいつらメジャーになったら速攻で内ゲバ始めるのが目に見えるから
距離を保つことにしたｗ

距離を保つも何も、お前が近づけたことなど一度も無いだろ

>>9
の
＞関数型言語が普及しない理由 - 偏見プログラマの語り！
＞http://d.hatena.ne.jp/kura-replace/20111114/1321236695


これ、俺がググって偶然そいつのその記事見つけたとき
＞　というわけで本稿を書くわけですが（ヤメテ！そんな冷たい目で僕を見ないで！）、
＞関数型言語*1についてはよく知りませんので、決して真に受ける事無く、
＞オブジェクト指向言語をようやっと使っている底辺プログラマのぼやきということで了解いただければと思います。（ヤメテ！その前置きはズルイとか言わないで！）

この発言にブチギレそうになった奴の記事だわ


なんで>>9は明らかに初心者みたいな奴のブログ引用してんの？
引用に見せかけた晒し？

関数型はやっぱ流行らないな

22 ：uy [sage] ：2012/06/13(水) 16:53:41.38
　静的言語はゴミでしかない

>>366
手続き型言語には元々、「副作用」なんて無いしな。
あるのは、状態書き換え。

printfが標準出力に出力するのも状態書き換えっていうの？

最終的にはストレージの書き換えやパイプバッファの書き換えになるんじゃね

そこらへんひっくるめて値を返す以外のことは副作用と呼んだらすっきりしていいじゃないか
手続き型であっても有用な概念だ

>>371を読んでしまえば>>370に賛同するしかないだろうよ

>>378
2chで世間が判った気になり始めたら、色んな意味でヤバイな。

>>377
Prologをやってる立場から言うと、手続き型の中で副作用なんていって欲しくない。

>>379
2chで世間が判った気になって他人にヤバイなとか言ってるバカｗ

殴ったら殴り返されただけだろ？
どっちもどっちだよ

どうしてあんなにdisるのが大好きなんだろう？依存症？

uyはどっかのスレで、コテではいかに相手を苛立たせるかに心血を注いで、
普通の内容は名無しで書くみたいなことを言ってたな。
昔は単なる馬鹿だったが、最近は馬鹿の一つ覚えで○○も知らない奴らが～○○位は当然～みたいなことを言い出して、ウザさに磨きがかかってきたな。

自己紹介乙

each_slice
transpose
chunk
inject
cycle
すら使えない奴らって生きてる価値ないと思う
例えば
10.times.cycle do |n| p n end
によって0~9をプリントする処理を無限ループなわけだけど、貴様らちゃんと扱えていますか？

mapM_ print $ cycle [0..9]

javaやC#に代数的データ型を導入して欲しい
関数型言語を使う気にはなれないけど、あれの素晴らしさには反論出来ない

関数型の人たちって、どうしてあんなに上から目線でdisるのかな？

静的型付け型の人たちって、どうしてあんなに上から目線で(動的型付けを)disるのかな？

だって関数型言語を批判してる連中（の大部分）って
物凄く低能で、批判も的を射てないんだもん。
しかも批判しといて反論されたら上から目線でdisるな、とか言い出すし。
ホント馬鹿の上に品性まで劣ってるよな。

だって動的型付け言語を批判してる連中（の大部分）って
物凄く低能で、批判も的を射てないんだもん。
しかも批判しといて反論されたら上から目線でdisるな、とか言い出すし。
ホント馬鹿の上に品性まで劣ってるよな。

排他的なのは大抵ニワカ

上から目線とか言っちゃう人は、永遠に底辺にいればいいと思うんだ。
向上心が欠片もない人間を引き上げてやる義理は無い。

引き上げてやるだってｗおもしろすぎｗｗ

自分の脳味噌を観察したほうが面白いと思うぞ

「上から目線」って言葉を聞いて「自分は上なんだ」と思うのがおもしろいんだが、そこが分からないとは…

上から目線と言い出す奴は
自分より下に居るんだなぁ、と思うだけだが

争いは同レベルの相手同士でなければ起き得ない(AA略

>>398
その発想が興味深いんだよ

バカが言う「興味深い」って、単に理解できてないだけだよなw

>>401
この場合の「上から目線」ってのは、馬鹿にされてるんだよ

バカに馬鹿にされても、何とも思わないけどな

バカにされているのは>>403だということに気付けｗ

ズレてね？

ズレてるよなw

軽量動的言語から来たけど
letとかのバインド？が何のために必要なのかわからない。
せっかく型推論で型記述しなくてすむのに意味なくない？

値の再利用と表現の簡潔化でしょ。
Don't Repeat Yourself的に。

letでも型の記述は（型推論できる式なら）いらないし。

何度も評価するより1度の評価で済むほうが速いだろw

一文字でも少なくタイプしたいなら ruby やってろ
っていう話じゃないの

let無しだと構文解析のルールがとても複雑になるんだな～

関数型言語ってループは末尾再帰で書くんですよね？
それってループするために関数定義の為に名前を消費する必要があるってことですか？
その、べつにそれがいいとか悪いとか言うんじゃなくて、単純に気になっただけなんですけど。

たいていは通用範囲がローカルなかたちで名前をつけることができるから問題ない

>>413
>関数型言語ってループは末尾再帰で書くんですよね？

関数型言語の原理、というか計算モデルという視点であれば、その認識は正しい

>それってループするために関数定義の為に名前を消費する必要があるってことですか？

関数型言語では(数値や文字列と同様に)関数そのものも式の要素になる
言い換えると、関数の引数として関数を渡したり、関数の戻り値も関数として定義でき、
こういった関数の使い方は「高階関数」と呼ばれている

一般に関数型言語には、この高階関数を応用したライブラリが標準で付属しており、
このライブラリ関数を利用する事によって、多くのケースでは関数再帰を意識せず
(手続き型言語における)ループ処理をプログラミングできるし、無駄な名前の消費も無い

高階関数の代表例にはリスト処理を提供する List.map, List.filter, List.fold があり、
たとえば Ruby では以下に示すようにモジュール Enumerable のメソッドとして定義されている

・List.map -> Enumuerable#map
・List.filter -> Enumerble#select, Enumerable#reject
・List.fold -> Enumerble#inject

ある集合の各要素へ、ある関数を適用した場合の、新たな集合を知るのがループの目的であるならば、
最初の集合と適用する関数を記述するだけで結果の集合を得られるので、他の言語のように何をするにもforループを書く的な書き方はあまりしない。

>>415では肝心な事を書き忘れていたので追記する

>>413も知っているように関数には名前を付けることができて、
これは「関数を定義する」と呼ばれることが多い
同時に、関数型言語には「無名関数」と呼ばれる概念があり、
「ラムダ式」あるいは「関数式」とも呼ばれる
つまり、(>>415で述べた)高階関数へ渡す関数や戻り値としての関数には
この無名関数を使えばいいから、無駄な名前を消費せずにプログラミングできることになる

たとえば Standard ML という関数型言語では、無名関数の文法は「fn <引数> => 式」であり、
その無名関数をリスト処理関数 map へ渡すサンプルコードは以下の様になる

　- map (fn x => x + 1) [1, 2, 3];
　> val it = [2, 3, 4] : int list

Ruby であれば、以下のように書く

　irb(main):001:0> [1, 2, 3].map { |x| x + 1 }
　=> [2, 3, 4]

>>414-417
回答ありがとうございます。

>>417
自分も無名関数についてはある程度知っていました。
Cのqsort関数なんかを使う時に、lambdaで直接関数を渡せたらいいななんて思うこともあります。
まあ、Cをアセンブリ言語のマクロと考えれば、欲張らない仕様の方がいいんでしょうけど。

そんなことを考えている時に、無名関数という仕様を持っている関数型言語でさえ、結局のところ、
余計な名前を使わなきゃならない場面があるのかと疑問に思って質問させて頂きました。
＃ 自分は関数名を考える作業があまり好きではないので。

>>414さんや>>416さんの話で関数型言語を使う人の意識というか感覚みたいなものが多少判ったような気がします。
「そんなことを気にする場面ってあんまりないよ」ってことだと思うのですが、それは

> 一般に関数型言語には、この高階関数を応用したライブラリが標準で付属しており、
> このライブラリ関数を利用する事によって、多くのケースでは関数再帰を意識せず
> (手続き型言語における)ループ処理をプログラミングできるし、無駄な名前の消費も無い

ということだからってことですね。
いろんな観点でのコメントがもらえて勉強になりました。
ありがとうございました。

lambda だけで再帰はむりかと

でもYコンビネータなら？

(λf . (λx . f (x x)) (λx . f (x x)))

>>420
評価器による。正規なら記述可能。

>>422
> >>420
> 評価器による。正規なら記述可能。

CurryのＹコンビネーター（そのλ式による表現は421にある通り）はどんな評価戦略でもリダクションだけでは進まない（逆向き、つまり一般のconversionが必要）。
しかし例えばTuringのΘコンビネーター（詳しくはBarendregtの百科事典を見ろ）ならば評価戦略がnormal orderの場合にはリダクションで再帰を表すことができる。
更にapplicative orderのリダクション戦略（かつλ束縛の本体にはリダクションが入らないweak戦略）という通常のcall-by-value関数的プログラミング言語の
評価戦略でも、λ束縛つまり高階関数によって再帰を表現する事は可能。FriedmanらのSeasoned Schemerに答えが書いてある。
つまり現実のSchemeを用いた関数的プログラミングで再帰呼び出しを完全に消しさることは実際に可能ってことだ。

>>423
「リダクションだけでは進まない」って何を指して言ってる？
y fを評価していってもf (y f)と構文的に同じにならないってこと？
再帰を記述するのが目的ならそれは別に必要ないんじゃね

import Unsafe.Coerce

main = print $ y (9:)

y :: (a -> a) -> a
y = \f -> (\x -> f (unsafeCoerce x x)) (\x -> f (unsafeCoerce x x))

>>424
> >>423
> 「リダクションだけでは進まない」って何を指して言ってる？
> y fを評価していってもf (y f)と構文的に同じにならないってこと？

（λｘ.．Ｍ）Ｎ　→　Ｍの中の自由なｘをＮで置き換えた項

という一種の書き換えによって左から右へと進めるのがリダクション。
この左から右への向きだけではＹｆからスタートしてｆ（Ｙｆ)は得られないということ。

カリーのＹでなくチューリングのΘを用いて最左最外のリデックスをリダクションする正規戦略ならば
Θｆからスタートしてｆ（Θｆ）までリダクションだけで辿り着くことが可能。

>>425
再帰をするのが目的ならf (Y f)を得る必要はないよね
なんか適当な意味論のもとでY fがf (Y f)と同じになればいい

プログラム言語における関数型言語っていうのは
OSにおけるLinuxみたいなものだと思っている

何年も前からユーザは「これからは関数型言語（Linux）の時代」と連呼しているのに
まったく流行しない。またユーザーは関数型言語（Linux）を使う事がカッコいいと信じているｗ

Windows信者のバカ君が今度はココに沸いたw

LinuxじゃなくてMacみたいな感じをうけるけどな

今時Mac信者で、Mac OSとLinuxが、どちらもUnix系という同類であることを知らないなんて、
相当のバカだぞ？

……相当のバカなのかw

おまえはなにをいっているんだ

そんなわかりきったことをドヤ顔で講釈する>>430って…

>>427
手段と目的を履き違える奴は
関数型言語には（Linuxもか）向いてない

で、流行でしかモノを判断できない奴の使っている言語はなんなんだ？

サンデープログラマーだから
業界で関数型が流行ってるって事すらわからん

JavaScriptって関数型言語とも見れる？？？

>>436
そんなこと言い出したらCでも関数型プログラミングはできる

いや、そういうマクロ的屁理屈じゃなくて
ラムダ式とか第一級関数とか、前向きな機能揃ってるんじゃないかなあと思って

>>436
いまさら

関数型プログラミングならどの言語でもできる
関数型言語と呼ばれるのは関数型プログラミング「しか」できない言語だ
だから「使えない」と烙印を押される
JavaScriptはそうじゃないだろう？

また意味不明な論理が来ました。

Haskell以外に『関数型プログラミング「しか」できない言語』ってあるか？

>>441
屁理屈乙
お前は０か１かしか考えれんのか

度合いを日本語で語るとかプログラマの恥。
勘違いして欲しくないんなら数値で語れ。

言語を作った人が「これは関数型だ」と言い張れば関数型になる。
そうでないなら外野があれこれ言うのは野暮というものだろう。

関数型は使えないというタイトルなんだから、そんな結論じゃダメでしょ。
関数型だとアピールしてる言語はクソが多いってことなら問題ないけど。

……あ、もしかしてそういう話？

関数型言語の問題点は「汎用的すぎる」って点にあると思う

低レイヤ…C
ゲーム…C++
言語処理系…C++
統計…R
CGI…Perl
Webアプリ…PHP
ブラウザ…JavaScript
Windowsアプリ…C#
iPhone…Objective-C
汎用スクリプト…Python, Ruby
業務システム…Java

「この用途ならこの言語」って言えるような分野って関数型言語にある？

なんか書き込みが多いと思ったら、どうでもいい書き込みばかりだな

関数型言語でググレカス

関数型ってGUIもI/Oも苦手分野じゃん。
いったいどうしろってんだ。

苦手なの？
手続き型みたいにかけるけど

それはもはや関数型プログラミングではない

モナドを持て囃している時点で、関数プログラミングは負けを認めたようなものだな。

モナドはマルチパラダイムだ、などと言い訳しているようだが、
結局は関数プログラミング単独では実用プログラムは書けない。
関数だけでなく、逐次実行と状態書き換えを導入しなければ使い物にならない。
そう認めたようなものだ。

>>452
>関数だけでなく、逐次実行と状態書き換えを導入しなければ使い物にならない。
いくら抽象的に書こうが実行できなければ使い物にならない、
と言ってるぐらい当たり前の話すぎてどう反応したらいいか。

IO型があるのは、単にプリミティブ型とボックス型を厳密に区別してるのとたいして変わらないのに、
モナドモナドモナドー、って叫んじゃうのが初心者なんだよねw

>>452
その通りだよ
いわゆる「関数型言語」は、言語全体を見て初めて便利なのであって、
関数プログラミングはできることの一つでしかない

>>453
実行メカニズムと言語表現の区別ぐらいつくようになってから出直してくださいまし。

>>454
全然違う

>>456
どういう意味だよ。現実に書けるだろ。

レスそれ自体は要求した事を行わなければ、
要求を満たす事はできないっていう言葉遊びだ。
無理な前提を想定して適用してるのだから無理に決まってる。

プログラムの実行を考えない実用性を含むなら、
定理証明支援系という使い道もあるから間違い。

俺的には関数型とかどうでもいいけど副作用の制限は制御したい

結局関数プログラミングとかは方法であって目的ではない
これに尽きる
目的にすり替わってしまったら、そりゃダメだろ

とりあえずjavaつかって
関数型プログラミングしたいところだけラムダ式だのなんだの使ってそれっぽくやればそれでいいじゃん。
最初から関数型言語を使う意義なんて無いね。

>>458
わからないんならいいよ。プログラミング言語意味論でも勉強して出直してきなw

>>462
言葉で飾るだけ飾ってるが一つも中身を語ってないな。
こんな阿呆に構った俺が馬鹿だった。

自分のレベルが果てしなく下であることがわからない奴ってたまにいるよなw

なんだこりゃ単語の関連の重みで文章を作成し無意味なことを言っている人工無能みたいな奴がいるw

> 関数型プログラミングしたいところだけラムダ式だのなんだの使ってそれっぽくやればそれでいいじゃん。
> 最初から関数型言語を使う意義なんて無いね。

MLなりHaskellなり、現代において普通に「関数型言語」だと認められるものも全く知らないことが丸出しw

リストと高階関数を使うことを関数型プログラミングと思ってる奴は多いな

えっ？lリストって関数型にしか無いの？
配列は？タプルは？ストリームは？

批判はしても具体的な主張はしない。
それが２ちゃんねらー

具体的に主張したら論破されちゃうからな
批判だけしていれば致命的に論破される可能性は低くなる

例えるなら文系（命令型）社長が
理系（関数型）社員を使いこなせてない状況に似てる

理系社長だと
理系社員で固めるから
そもそも使えないと言う評価が存在しなくなるしな

命令型が好きな奴は
仕様書の命令に従うのもお手の物

俺は命令するのもされるのも嫌いだ

２ちゃんねら(レス) : 批判
=> ...

所属 = function
　| 批判 -> ２ちゃんねら
　| _ -> 一般

文系理系って馬鹿だろｗ

この世は文系理系じゃなく体育会系とその他で分かれてるからな

このスレの流れでは
非関数型＝手続き型＝命令型＝体育会系型
ってことかね。

そう思ってる関数型の人は多いよね。

文系と理系というより自民と民主だな
関数型言語は20年くらい前の民主

現政権の手続き（命令）型言語には嫌なところがたくさんあるが実稼働してるという実績があり
なにより関数型言語のいいところを貪欲に取り入れるという動きもあり好印象
関数型言語はお花畑気分が抜けずチャンス与えるのすら怖い
って感じ

むしろ共産党か

出発点のLISPは共産主義者が作ったしな

手続き型はそのうち取り返しのつかない事をやってしまう
原発は安全です（ｷﾘｯみたいなｗ

それに比べて関数型は核融合炉のように安全

>>435
javaやPHPなんて仕事があるから選ぶだけで、日曜プログラマこそ関数型言語を使うべきだよ

>>483
だよな
何が楽しくてjavaやるのかわからん
マゾかな？

>>483-484
どの言語でどんなソフトウェアを作ってるのかも知らずに関数型を押し付けてる時点で
お前らが厨二病患ってるだけの素人だってわかるよ

素人とかそりゃそうだろｗ
サンデープログラマーなんだから
流石、手続き型は論理的でない馬鹿な事を言う

えっ

Javaは関数型言語だろ
ラムダ式あるし

ググったらマジだったｗ
javaも関数型の軍門に下ったか

リリースもされてないものを何言ってるんだ

Javaのはラムダと言ってもかなり制限されてるからな

>>491
ラムダありゃいいってもんじゃねーだろw

>>488
素の状態では変数の書き換えが出来ないのが関数型言語だと思うの
ごにょごにょすれば、関数型言語でも書き換えが出来るけど、手続き型よりは手軽じゃないって意味で

お前ら向きの最強言語教えてやるよ。Dだ。

「その辺の言語のよさそうな機能をぜんぶ集めてみました」みたいな言語って
美意識のカケラもないと思うの。

>>495
なんでそこだけオカマ口調なんだ

フフフ、いいわね、子どもって
あたしにもそんな純粋な頃があったわ

グフフ、いいわね、子どもって

生産性100倍スレがブレイクしてんな
こっちも盛り上げようぜｗｗｗ

>>498>>499
この間に1スレ消化してるからなあっち

煽り力が足りない

age

生産性100倍スレはpart1が
2013年の3月に立って756まで一気に消化。そこそこのヒットスレではあった。

そこから伸びが鈍化してたが
10月になって837からまた急に伸びだしそのまま1000。
そして勢いはとどまらずpart2をまるまる消化。
いまいちきっかけがよくわからん
暇があったらまとめてみるか

対となるこのスレももっと盛り上げないとバランスとれない

俺、いつも上げるだろ、
そこから顔真っ赤にした戦いが始まるんだよ。
戦いはいらないから、俺の書き込みにレスしろって話。
何勝手に戦っちゃってんの。
あと、夜中に盛り上がるのやめてくれる？
勝手に盛り上がるなら次の日まで続けろよな。

コンパクトな六尺コピペかと思った

イイエ違います。
魂の叫びです。

宇宙人だけど何か質問ある？

宇宙のどこ出身？

>>509
地球

足のサイズ何インチ？

これ三個の質問で個人を特定するメソッドだけどいい？

>>511
26.5

つうか板違いな質問はご遠慮願います。

673.1㎝ってことだよね？

足のサイズと行ったら足の長さのことに決ってるよな

26.5*2^-60光年

あっちのスレは
動的型付き言語派のほうが静的型付けをよく知っている奴が多い
という冗談みたいなスレだから。
TAPLも読んでないJaverに静的型付けを語られても迷惑なんだよ。

関数型言語のエッセンスのいいとこ取りしてあとはポイすればいいということだが
根幹の静的型づけというのがどうにもならないのでそれは無理だということだろう

>>517
こんなところで愚痴ってないで率直に反論しろよｗ負け犬ｗ

あのスレの負け犬はJS馬鹿だろ

>>519
こんなところで愚痴っていないで、素直に
「Null値のデータ型は何か？」
について答えてみろよw負け犬w

いや動的型付け言語でも別にかまわないけど
option explicit
はほしい、通さないと typo がわからないとか勘弁

nullは型不明だろ。premitive以外の型というのが地球では普通の認識だろ。
宇宙ではnullは連結リストの末尾型として定義される。

CやC++ではnullは0という数値だけどこれはどうかと思う。

>>524
必要なとき(C/C++いずれにもある）には (void *)0 とキャストして型情報を附し無問題
C/C++は静的片付けだしオールマイティは無理なのでは？

地球ではnullやnilの語源は無だから0ってことになっているけど
宇宙では0である必然性はなくてアドレス0にあるオブジェクトの機能は無しとも考えられる
宇宙では「無」ではなくリンクリストの末尾型オブジェクトとして定義されている。
Cでは
while(a!=NULL){...}を
while(a){...}と簡略化できた記憶があるが、while(ゼロ以外)ということだろう
そういう便利さがあるから0ってことになってるけど、
while構文自体が無い宇宙では別の認識になる。

過去の遺産などは捨ててしまおうホトトギス
作りなおせばいい

>>521
型なんて無いだろバーカ