[過去ﾛｸﾞ] 関数型プログラミング言語Haskell Part33 (1002ﾚｽ)

関数型プログラミング言語Haskell Part33 http://mevius.5ch.net/test/read.cgi/tech/1581326256/

上下前次1-新
通常表示 512ﾊﾞｲﾄ分割 ﾚｽ栞
抽出解除 ﾚｽ栞

---

このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ

---

605: デフォルトの名無しさん [] 2020/12/08(火) 09:15:41.98 ID:VKXi32Vk 実際にちょっとしたプログラム書いてみると メモリ周りの最適化が困難なんだよなこの言語。 しかも最適化の方向性がアルゴリズムの改良ではなく 言語特有のボトルネックの回避がメインになるから コードを見ても最適化の意図が分かりにくくて 一見無駄に冗長に記述してるだけに見えるコードが出来上がる。 http://mevius.5ch.net/test/read.cgi/tech/1581326256/605

669: デフォルトの名無しさん [] 2021/01/21(木) 06:30:57.22 ID:mwzMDOkA https://stackoverflow.com/questions/35027952/why-is-haskell-ghc-so-darn-fast この辺 > thanks for the link. 80 lines is what I called "low-level style of programming not much different than programming in C itself." . "the higher level code", that would be the "stupid" fmap (length &&& length . words &&& length . lines) readFile. If that was faster than (or even comparable to) C, the hype here would be totally justified then. We still need to work hard for speed in Haskell as in C, is the point. >>605もそんなことをかいてる http://mevius.5ch.net/test/read.cgi/tech/1581326256/669

---

ﾒﾓ帳

(0/65535文字)

---

上下前次1-新書関写板覧索設栞歴

---

ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ

---

Google検索

Wikipedia

---

ぬこの手 ぬこTOP 0.042s