[過去ﾛｸﾞ] 関数型プログラミング言語Haskell Part33 (1002ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
132: 2020/03/30(月)21:57:05.25 ID:6PZKu5o5(1) AAS
このゲームAIのコンテストにHaskellで参加して優勝してHaskellの強さを見せつけてやれ！
外部ﾘﾝｸ:www.codingame.com
325(1): 2020/05/23(土)01:44:01.25 ID:m+h1wlWJ(2/2) AAS
あ、コッチの方がかっこいいのか？
でも可読性を犠牲にしだすとperlみたいになるから良くない？
repM = (>>=(return.repeat))
378(1): 2020/08/14(金)23:21:17.25 ID:OycuixUd(2/2) AAS
>>374
コンパイルエラーの文章を読んでぐぐる癖をつけよう
覚えはじめの頃に出会うエラーは大抵は文法ミスか型エラーだろうから
ぐぐれば「何が悪いか」はだいたい解決する
「なぜ悪いか」はすごいHaskellあたりを読み進めていけば習得できるはず
379: 2020/08/15(土)17:24:00.25 ID:uxgG4TyL(1) AAS
>>377-378
ありがとうございました。
581: 2020/11/23(月)02:58:53.25 ID:v8DPq2Nr(1) AAS
イヤ、まぁ純粋に速度とか効率とか考えたら手続き型言語の方が優位なのはその通りでしょ？
だって現在の計算機がノイマン型の手続き型の処理をするために設計されてるんだから
そりゃバリバリにチューニングしたら手続き型言語には絶対勝てない
その時代時代の最新の計算機の性能をフル活用しないとできないような処理は当面関数型言語の出番は回ってこない
しかしそこまでの処理でないならやはり関数型言語の活躍できる場面も出てはくるだろうけど、しかし例えそうなったとしても手続き型言語も関数型言語も両方臨機応変に使いこなせるようになるとなると中々難しいから、結局どちらか選ぶなら手続き型言語という事になってしまう
しばらくは関数型言語が実務の場面でバリバリ使われるようになるのは中々難しい
当面研究者とか、サンデープログラマーの趣味の世界でしか出番ないかもしれない
747: 2021/02/17(水)16:22:11.25 ID:mAFPwKeZ(2/2) AAS
もちろんリストの要素の個数減って良い場合の話だけど
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.033s