http://toro.2ch.net/test/read.cgi/tech/1320743217/
http://ideone.com/CXMrq
要素数と実行時間が何の関係無くなるけど
そもそも何を比較してたんだっけ
前スレ>>992-993
なら、Haskellもコンパイラの進歩でpythonに並ぶ余地はあるって事か
元々、length関数や、++演算子（リストの連結演算子）が初心者にも簡単に作れるってのが気に入ってるだけだから、体感できない速度差は気にならんけど・・・
Haskellに惹かれるのは、defとか、forとか、（モナド使わない限りはifも）そう言うキーワードをなるべく見ないで済むってのが、一番大きい気がする
（というか、forとifが一番見たくない）
あと、基本的に右辺と左辺が=（等しい）なのも気に入ってる
コンパイラのmain=...と言うのも、あながち間違ってない
速度こそpythonに劣るだろうけど、自作のmap関数や、++演算子などの":"で区切られて、状態を次の再帰に引き摺らないものは、単純再帰でも、ループとして扱われる
（だからこそ、末尾再帰は、次の再帰に状態を引き摺らないのでループになる）
結局、アセンブラに実現できることは、関数型言語でも、命令型言語でも、最終的な最適化の形は同じになるだろうけど、それは時間が解決する話
関数型言語の最終的な最適化の形は
http://ideone.com/SaMJe と http://ideone.com/kzkty が同じ速度になる事
これは、参照透明性が確保されて無いと、最適化できない事の一つ
（まだ実現されてないけし、逆に言えば、参照透明性が確保された関数に限れば、命令型言語でも理論的には最適化可能なはず）
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
そこそこ重たい数値計算をやりだすと、関数型言語が謳う理想通りにいかない
場面はいろいろあるのだが、2chのように限られた字数でしかも関係者外にも
わかるように問題点を説明するのはなかなかうまくいかない。
各言語には目的によって向き不向きがあるから、用途を論じるとか、用途拡大方法を考えるならまだ判る。
同じような単純作業の比較で何を得たいのか判らないんだよね。
抽象度が低くてもチューリング完全なら最終的にできることは一緒
どれだけ簡潔に書けるかという意味でいうなら、reverseという簡単な例ですら
CとHaskellには大きな差がちゃんと在った
つーか前スレの配列版HaskellはCの次に速かったぞ
コード量もC並みだが
>reverseという簡単な例ですら
そういう単純な例で実行時間が違うのはわかるけどさ、それを言語全体の優劣判定に短絡するのが無意味だと思うんだが。
コンピュータの利用範囲が広がるに連れて、アセンブラだけでは実現に手間がかかるから色んな言語が開発された訳だから。
例えば金融商品企画のようなアプリを、リソースを大量に使えばCでも開発は理屈上は可能だが、
それはもはやHaskellのインタープリターをCで再発明するくらいの問題になる。
だから疑問は、リソースには色々あるのに、なぜ単純な例で時間だけに拘るのか？という事。
単純例しか経験がなくて、時間以外のリソースは微々たるものだと考えてる者なら必然だけどね。
事実としては「Haskellは遅い」それだけ
言語の優劣は各自で判断すべき
そりゃ価値を見出せないよ
自分はdefとかrecとか関数定義にプログラミング言語特有のキーワード使う機会が少ないのが気に入ってhaskell使ってるけど
>単純例しか経験がなくて、時間以外のリソースは微々たるものだと考えてる者なら必然だけどね。
このスレは、既存のHaskellコンパイラより早いHaskellインタープリターを自作出来る猛者が集う場所ですよ？
シートベルトって窮屈じゃん、って言ってるバカと同じなんだから。
>事実としては「Haskellは遅い」それだけ
そのとおり。
Haskellでできる事は全部、C、Pythonならもっと早く出来る。
時間は重要なリソースだという事は学生にはわからんだろうな。
えっ。Haskellの遅延評価のようなことがC、Pythonなら
もっと速くできるなんていっていいのですか。
少なくとも「早く」はできませんよね。
そういうときは、コードを書いて「これを書いてみろ」って言うくらいじゃないとね
ていうか、遅延評価は手段のひとつであって、それ自体が目的であることは滅多に無い
でも長いコードと、それと同性能で短いコードで
前者の方が早く作れたりするのは良くあることだから
コード量と開発時間の相関も割りと微妙なんだよね
学習コストだとか、命令型と関数型の両方を扱える人のうち
関数型の方が早く開発出来る人の割合とかも気になるところ
c/c++より遅い、あるいは静的言語の中では平均的に遅い、という意味なんだが、
時々文脈を（意図的に？）混同して、スクリプト言語よりも遅いとか言い出す輩が後を絶たない。
前スレで可変長配列と片方向連結リストを混同して勝利宣言してる馬鹿を見た時はまたかと思ったよ。
夢を壊して申し訳ないが...
OCaml
http://ideone.com/MqIzH （リスト）
http://ideone.com/LH93F （配列）
Haskellは可変長配列に代表されるような速いデータ構造を
扱おうと思ったら途端に面倒になるのが問題なんだろ
悔しかったらPythonより速いコードをPython並みに簡潔に書いてみろ
Haskellが安全？www
xs = head []
虫ケラ、じゃなかった、ハスケラはコミュ障だっていわれんの！
Pythonより速いコードをPython並みに簡潔に書けないという
ギブアップ宣言か
もう「Haskell = 遅い」が定着しそうな勢いだな
どっかでhaskellの人が永続=透明性と書かない人は理解してない人と断定してたけど、
どうしてhaskellの有名人はみんなアレなんだ？
古すぎるだろ・・・・
ふふふ残念ながら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
>コード量と開発時間の相関も割りと微妙なんだよね
その言語に慣れている者が書くという前提で、一日に書けるコード量は言語による大差は無いというのをどっかで見た。
ビルド, 実行, ソースとにらめっこ, ウロウロしながら思考
してる時間の方が長い希ガス
一般に低水準の言語の方がワード単位の入力時間が短くなる。
極端な場合、倍位にはなる。だから、よほど難しい問題でないかぎり、
>>37がいうように一日に書けるコード量は同じに、近い。
しかし、それだけ体力もいるから、プログラマの定年が若くなる。
高水準な言語だと60歳でも十分。この差は大きい。
ベンチマークも決まって実装計測して結果が揃ったところで
どうして時間だけとか言い出すのは完全にコミュ障だろw
なったらなったでメンテする人がいなくなりそうだけど
まあ元々、アッカーマンとか無視してる時点で、無意味だから。
（しかも言い出したのはHaskeller）
ライブラリのreverse関数呼び出してドヤ顔して馬鹿じゃないの？
目か頭のいずれかもしくは両方とも悪い。
???
ああ、自分の頭が悪いって告白ですか
そういうのはパパやママに言ってください
我々の所為じゃないので
アッカーマンを無視するってどういうこと？
ん、ああそういう流れだっけ？
じゃこれで
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に問題があるよねえ
（どういう意味にせよ）少しは実用的な話をしようぜ？
ああ、43のtypoだと解らない程度の頭なんだね。
カワイソス
おそ！
関数型が得意なベンチマークでなきゃヤダヤダ
ってこと。
λ
形が似てるんですが
関数型言語をすつもりか！
（一部のみ、先行評価より速い）
そもそも、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自体の最適化は弱い
>>11を受けて関数型言語/命令型言語の適材適所の話題になると期待したのだが。
まあここは隔離スレだし、目的が互いに異なる言語同士を単純作業で比較したがる人が集まる場所でもある。
鳥と魚を比較するのに、共通項目だからといって体重や肺活量で比較するようなもんで、最重要と言えるほどの意味は無いと思うが。
比較するなら、計算モデルからのアプローチ（CTMCPなど）も有るので、該当スレが宜しいかと。
>haskellの遅延評価は、元々先行評価よりも遅い傾向にあるんだけどな・・・
>（一部のみ、先行評価より速い）
評価する際の処理時間が先行評価より速い遅延評価って尊えば何だっけ？
遅延評価を使ったプログラムの総時間と混同してないか？
X 尊えば
O 例えば
>評価する際の処理時間が先行評価より速い遅延評価って尊えば何だっけ？
遅延評価とか先行評価とかいうのは評価『戦略』であって、『評価するかどうか』を決めるだけだ。
実際に『評価する際』には評価戦略の段階は通り過ぎてるからその問は無意味だろう。
そして遅延評価は評価するまでに猶予を置く意味合いしか無いから、
無駄な計算をしないという仮定のもとでは、遅延評価戦略が先行評価戦略よりも速くなることは有り得ない。
>>62のいう『一部』というのはたらい回し関数みたいなもののことを言ってるんだろうが、
あれはグラフ簡約がたまたまメモ化の役割を果たし無駄が省けているためであって遅延評価だからではない。
そもそも速度で評価戦略を語ることがナンセンスだよ。
あれは（たらい回しみたいな）一部の計算を無駄なく書くのを簡単にするためのものだ。
無駄なく書くのが難しくなってる計算の方が多くね、ってのが遅延評価に対して意味のある批判だろうよ。
>そもそも速度で評価戦略を語ることがナンセンスだよ。
別にそんな話はしてなくて、「先行評価より早いものがある」について具体例が知りたいだけ。
だから、総時間と混同してないか？って書いたんだがなあ。
どっかでの、Haskell=遅いって話のことなら俺は無関係。
評価戦略に対して「aはbより早い」とかいうのは論理的に間違ってるってこと。
これはhaskellerの負け惜しみとかそう言うんじゃなくてさ、
速度と評価戦略が別次元の問題だってことを言いたいだけ。
haskellのたらい回しとcのたらい回しは記述が似てても、
『そもそもやってることが違う』んだから。
それに同じ計算量、無駄を省いたCの処理とかに敵うわけないし
割と手軽に計算量を減らせる(処理系にお任せ出来る)ってくらいだろう
無限リストとかを評価しちゃうと氏ぬのは言語に関係無いから
その辺はCでも配列でなく関数とかで仮想化するし
いや、まったく同じ計算をするなら同じ処理時間になるよ。
ならないとしてもそれは遅延評価のせいではない。
よくみると俺もこんな発言をしていた。
俺も論理的に間違っているということだな（ｷﾘｯ
ネタの投下も無しに贅沢な
それに、>>62はプリミティブな関数が自作出来るのが楽しいって言ってるだろ
python版出すなり、新しいネタ出すなりすれば良い
というか『適うわけない』と思った根拠はなんなのだ？
論理的に同じ計算をするならあとはなんというか、言語の基礎体力だけの問題になるはずだが。
あれか、haskellではIntがボックス化されているからとかなんかそういうのか。
＞まったく同じ計算をするなら同じ処理時間になる
同じロジック書いても
遅延評価を実装するために発生するオーバーヘッドとかの影響で
まったく同じ計算(機械語レベルで)にはならないんじゃないの？
＞言語の基礎体力だけの問題
そうだよ、そういう話
例え同じロジックでもインタプリタ方式の方が遅いとかそういうの
Cは安全性を犠牲にしてでも速度優先するってコンセプトがあるわけだし
遅延させることに意味がある場合、それはオーバーヘッドとは言わないんでは？
計算結果を明示的にキャッシュするのだってもちろんスペース喰うわけで。
そういうことじゃなくてGHCの実装の深いところに基づくオーバーヘッドだというなら、
俺にもよく分からないが、お前にはそれが有意な差であると合理的に説明できるのか？
そのレスバグだろ
開始インデックスの指定漏れてんぞ
意味有る無しに関わらずオーバーヘッドと言うよ
機械語レベルでの違いによるものなら大小に関わらず有意だよ
呼ぶのか。なるほど。
それは明示的に計算結果をキャッシュするコストと比べてどうなの？
簡易なものなら是非見てみたい。
haskellはcと同じ速度ってことでさ
ここまで速度に拘るとは思わなかったからね
まあね。実際俺もあるとおもうよ。オーバーヘッド。
話として持ち出すからには根拠を持っていてほしいなと思っただけさ。
単にゼロオーバーヘッドでの実装は無理だろうと思ったのと
「c言語 haskell 速度比較」とかでググッた結果を見たというだけ
流石に個々の速度比較の詳細までは知らない
逆にオーバーヘッドが無いってのを示してくれたらもちろん前言撤回するよ
ていうかよくよく読み返すと>>78は疑問文だねえ。
俺が謝ったほうがいいのかも知れない。
だがわたしは(ry
先行評価だと、全部読み込んでから始まるか、最初の10要素だけ読み込む様に書き分ける
ファイル処理とかで、書き分ける必要が無い事になる
とは言え、最近の言語なら、オブジェクトにその辺の処理を押し込んでそうだが
全体の処理時間が同じなわけがないだろjk
遅延評価になると思うんだけど
計算量が減るところだけ遅延評価にした方がやっぱりいいと思うんだよね
そのかわり、ファイル読み込んで同じファイルに書き出すときとか
「あー、この辺で正格評価するべ」的なこと考えんといかんけどな
std::copy(in.rbegin(), in.rend(), std::back_inserter(out));
はてなあたりの選民気取りが「haskellはCより速い(ｷﾘｯ」とか言い始めたら俺もそろそろ関数型始めようかな
関数型言語って名前捨てて”モナド型言語”とでも呼べばいいんじゃね？
TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲
Androidアプリ制作依頼スレ (309)
【RAD統合環境】 Qt 総合スレ 13 【Win/Mac/Linux】 (199)
【RAD統合環境】 Qt 総合スレ 13 【Win/Mac/Linux】 (199)
オブジェクト指向の弊害 (131)
★初心者にVisual C++を教えるスレ★ Part38 (236)
【至急】助けてください。 (231)
--log9.info------------------
それをすてるなんてとんでもない！３ (271)
財形（勤労者財産形成制度）をやっているヤツ (789)
【ニート】専業主婦という生き方【同然】 (383)
餃子の王将【無料券割引券】でムッとされた奴集合 (745)
固定電話料金をケチろう Part.1 (582)
【PSE】電気用品安全法でリサイクルショップ死亡 (263)
TSUTAYAやゲオの半額のときだけDVDレンタルする人 (855)
【】 250ccのバイクと、軽自動車ではどっち? 【】 (829)
ドケチのためのオークション (878)
ケチくさいケチからケチくさくないケチへ (675)
【無料】タダで飲み物が飲める場所おしえれ (273)
ドケチのスマートフォン (412)
1000万貯まったが・・・ 【これからどうする】 (605)
ドケチの正月 (674)
働くよりも美味しい生活保護＠母子加算 (629)
月６５０００円で過ごす方法 (366)
--log55.com------------------
ホモラップ19
Ｎ
【東方神起】(´･Ｊ･｀)人(∵) part2024【TOMORROW】
実質民芸品243
【ホモ】銀魂なんでもあり雑談127【ノマ百合】
四千九百三十五
A.B.C-Z★176stars★8/24と9/17はMステに出るよ♪
きっずの噂1174
