次世代言語議論スレ[Go Rust Scala Haskell]第5世代 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
いざ、語ろうぞ。 スレタイ超過のため、一部省略。 その他もウェルカム。 前スレ 次世代言語議論スレ[Go Rust Kotlin Scala]第4世代 http://mevius.2ch.net/test/read.cgi/tech/1492631007/
なんだかんだ言ってもOS自体を書く言語は変わってないからな >>56 今ならSwift開発したクリス・ラトナーが絶賛求職中やで。 Googleってゴスリンやゲイドも飼ってたことあるよな 一瞬で辞めたけど 会社の体質に問題があるんだろうね Androidのアプリ作りたいのか、iOSのアプリ作りたいか それだけの話なのに何で自分で決められないんだろ kotlinは既にJavaをマスターしててサンプルコードの雰囲気を見ただけでなんとなく書き始められるくらいの人が使うもんだぞ 勉強するもんじゃない 今Haskellでよく使う処理をガンガン関数にしてライブラリ化してるけど、LLでもここまで短く書けないだろと言うか、 ここまでライブラリ化するには遅延評価じゃないとreverse使わないような処理でもメモリに溜め込むか、 遅延評価にする為にイテレータ作りまくりじゃないかと思った。 いあ、最上位の関数とかは短く書けるんだろうけど、ライブラリ内部の似たような処理を ガンガン関数にして行くのは流石に難しいと思う。 >>69 つづきはブログでおやり 具にもつかない報告を読まされる身にもなってみろ お前のレスは今後一切いらんからなこのスレには linux のソース見る限りは c にまともなマクロが用意されればそれで十分。 まあまともなマクロを用意するってのは言うほど簡単じゃないだろうけど。 >>70 じゃあLLでも何でもいいけど、手続き型言語でよく使う処理をガンガンライブラリ化してみてよ。 どっちがより汎用性と簡潔性を両立出来てるか競おうず。 Haskelは実装変更のインパクトがでかくてカプセル化的な考え方で作るには向かないんだよな 実用言語としてガチ関数型を流行らせるには厳密性を維持しつつ現実の大規模開発でのモジュール化も考慮した仕組みを作らないと >>73 Cでcatコマンド自作しようとした時、複数ファイルから一番長い一行あたりのバイト数(文字コードによって違うので文字数ではダメ)調べるコマンド作った時、 lengthはByteStringモジュールを使いたいけど、mapは標準のを使いたい(ByteStringのmapはByteString -> Char特化)って時に細かくどれは読み込んで、どれは読み込まないってしたけど、 それじゃあかんの? モジュール読み込みの設定だけ変えれば、main以下は全く同じコードがバイト数と文字数切り替えれるけど。 >>74 すまん全く意味がわからない 73からいきなり抽象度が下がりすぎだろ ハスケラならもうちょっと抽象的かつ厳密で明示的なレスを頼む >>72 なにが「じゃあ」なん? 脳みそ腐ってんの? しょーもないレスでスレ汚すのやめてくれマジで >>75 抽象度が高い=フワッとして概念的って思ってたんだが違うんか。。。 import書く時、この関数だけ読み込まない。 この関数だけ読み込むって指示できるから、そこだけ弄ればそこ以下のコードは書き換え無しに 文字数数えるかバイト数数えるか動作を切り替えられる。 >>76 うんうん。 分かるよ。 式と文が入り混じるから関数化する単位に限界あるもんね。 副作用と純粋部分の区分けが強制されないというか、遅延評価じゃないと強制されたらreverse使ってなくてもメモリに溜め込むコードになっちゃうし。 それを解消する為にイテレータ書きまくるのも面倒だもんね。 Cくらい速かったら、それを飲み込むのも我慢出来るのにね。 この勘違いしたハスケラを黙らせるには、 ハスケラ自慢のライブラリを見せてもらって、 それより簡潔なコードを書くしかないと思う >>77 例えば、引数の値のみにより完全に決定される値を返す関数があったとして ここに「ただし、前回と値が同じ場合は前回より1だけ大きい値を返す」という要件が増えたらどうする? >>80 Haskellも状態扱えない訳じゃないし、大量に状態保持す代名詞のGUIプログラミングが、HTMLやXAMLで書かれるのに一定の地位を確立した今となっては、そういうDSL、又はDBに状態保持させて、Haskellは同じ値が来たら外部に+1してってお願いすれば良いと思うけどね。 何言ってんのか分からんけど、Haskellでここまでよく使うパターンをライブラリ化出来るなら、もうLL要らんってなった。 速度が必要な時はCで書いて、速度求めないのはHaskellで良いや。 速度こそLLと変わらんけど、ここまで再利用し易いなら自分でよく使うパターンをライブラリにして行けば、すぐにLLより短くなる。 number.hsナンバリング import System.Environment import Myfunc main = getArgs >>= mfput (fnumbering id) revnumber.hsナンバリングと行の逆順 import System.Environment import Myfunc main = getArgs >>= mfput (fnumbering reverse) mygrepn.hs検索文字列含まれる行(行番号付き)抽出。 import System.Environment import Myfunc main = getArgs >>= \(w:fs) -> mfput ((replace w (redstr w)).(grep w).fnumbering id) fs rp.hs(文字列置換) import System.Environment import Myfunc main = getArgs >>= \(w:nw:fs) -> mfwrite (replace w nw) fs ライブラリ内部にも似た様なパターンを関数化して無駄に似た様な少し違うコードが少ない様にしてる。 Myfunc.hs自作ライブラリ module Myfunc where import Data.List import Text.Printf consnum::(Int,String) -> String consnum (i,xs) = printf "%4d:%s" i xs fline f = unlines.f.lines fnumbering f = fline ((map consnum).(zip [1..]).f) redstr::String -> String redstr [] = [] redstr w = printf "\ESC[1m\ESC[31m%s\ESC[39m\ESC[0m" w bluestr::String -> String bluestr [] = [] bluestr w = printf "\ESC[34m%s\ESC[39m" w grep w = fline (filter (isInfixOf w)) replace _ _ [] = [] replace [] _ cs = cs replace w nw cs | w == xs = nw ++ replace w nw ys where (xs,ys) = splitAt (length w) cs replace w nw (c:cs) = c:replace w nw cs putfc (f,c) = printf "%s\n%s" f c writefc (f,c) = writeFile f c mfptn fs f ofs output = mapM readFile fs >>= return.(zip ofs).map f >>= mapM_ output mfput f fs = mfptn fs f (map bluestr fs) putfc mfwrite f fs = let tfs = map (++ ".temp") fs in mfptn fs f tfs writefc >> mfptn tfs id fs writefc それライブラリ化する価値もなさそうな 汎用性の無いコードにしか見えんが、本気か...? >>79 ワザとウザい役したけど、実際問題再利用のし易さと速度はある程度トレードオフな関係だと思う。 それならHaskellとCで良いんじゃないかってなった。 個々人でバランス感覚違うから、他の言語を選択するものアリだけど。 >>86 まだ育ててる最中だしね。 複数ファイル読み出し、複数ファイルそれぞれ出力なパターンはこれで行ける。 複数ファイルから一つの結果求めるパターンはこれから作るし、他の関数と共通パターンあったら、関数化して行く。 正気か?って言うけど、forとかメソッドチェーンな中身とか途中のメソッド入れ替えるとか、そう言うことしてる様な感じ。 こんな関数化の方法、オブジェクト指向言語では考えもしなかったぞ。 Haskell使いのレベルの低さが知れるな こうゆうのを繰り返すならやっぱり次はまたHaskellはずそう ていうかHaskell自体は全然次世代言語じゃないじゃん Haskellの一部分を参考にした次世代言語はあるけど ええ。。。 最近こそラムダ式とか入ったけど、オブジェクト指向って相変わらず手続き型言語で、コンストラクタって結局構造化プログラミングで言うinit関数でしょ?みたいな感じで処理の分け方が上中下って感じなんだもん。 おまけに肝心の中身はインターフェースでそれぞれのクラスに別々に書いてねとか。 似た様なコード何度も何度も書いてるなー。。。って感じだった。 LLにしても、書き捨て毎に似た様なコード書いてるなー。。。って。 Haskellだからここまで関数化しても遅延評価でメモリを一定以上消費しないんだと思うし、mfput関数一つ書けば中身の処理を考えるのに集中出来た。 (mygrepnとか見つかった文字列を強調赤字にするオマケ付き。 rpとかコマンド名が競合するから短い名前だけど、地味にコード書き換えに活躍してる) 実際に上のコードと同じライブラリ書いてみてよ。 パターンは共通って分かってても、文が邪魔したり、メモリに溜め込む処理になるから断念する場面が出てくると思う。 >>89 >>76 >>70 まともに叩くことも出来ないレベルのクソ野郎は入ってくんなよ… お前らみたいなのがいるから、変なのが増長するんだろ >>92 結局パイプ的に繋いでく話してるだけだな はっきり言うが、Haskellでまともなプログラム組んでIO扱う途端にその手の使い方はできなくなるよ その言ってる方法突き詰めたとして、リアクティブプログラミング的になるが、 遅延評価が仇になってサンク作りまくる場合はあるし、遅延評価だから空間計算効率が良いなんて話にもならない Haskell自身もメモリの効率がいいわけでもない 女アクのGHCのランタイムがまずクッソでかいし 何よりリアクティブプログラミングじゃ、現代のGUIでまともなプログラム作れない IOなGUIツールキットをリアクティブに対応させるコード書いてる暇あったらIOで書いた方がマシだ 正確にはリアクティブプログラミングじゃなくてFunctional Reactive Programingだな リアクティブだけなら、一つのシグナルストリームでなく分散メッセージでいいし難しくはない >>94 空間計算効率が良いなんて一言も言ってないが。。。 悪魔で再利用し易さの割にってだけ。 んでもLLと同程度ならほとんどの場合で問題にならないので、このままライブラリ化進めればLLよりチマチマしたの作るのに都合が良い言語になると言うか、既になってる。 半端にLLで空間計算効率考えるよりは、普段はHaskellで富豪的だけどLLより再利用し易いコード書いて、そう言うの重要な場面ではCで書けば良いやってなった。 今時のメモリ搭載量だと小説10冊分が1ファイルに入ってても問題にならんから、実用上ほとんど問題にならん。 それが問題になる時は処理速度的にもLLでも対処出来ない。 >>96 お前さっきからメモリの話ばっかりしてるじゃん… それに再利用については、途中からIO入れたら使えないよね? っていうツッコミに全く反論できてないし 言ってる事めちゃくちゃだぞ >>97 「関数型で書いてもメモリを一定量以上使わない」を「空間計算効率が良い」と解釈するのはいくら何でも頭発達しすぎでしょ…… ちなみにCで書こうがIOの問題は付随するので変わらない そもそもパーサをTemplateHaskellとけ使って書いてるレベルならまだしも Haskellで型注釈も無しじゃコンパイル遅すぎだし、 リストを配列代わりにしたり、String使ってテキスト処理してるレベルじゃLLより遥かに動作遅いだろ 普段から使ってるとはとても思えない >>98 いつ帯どこに突っ込んでんだよ メモリに溜め込む云々は明確にそういう話だろ え、まさか本当にストリーム処理書けないとかそんな話? いくらなんでも違うよね? >>97 途中からとはなんぞな? CUIにしてもGUIにしても、HaskellだとIO部分と純粋部分は強制的に分けて書かざるを得ないから何を言ってるのか。。。 (mfwriteでは同名ファイルに書き込めないので一旦別名で保存して、別名で開く->元の名前で保存ってしてるけど、そう言うのはIOが途中で挟まるってのと違うのん?) ある意味手続き型言語みたく(と言うか他の関数型もそう言う意味じゃ途中でIO挟まる?)、途中でIO挟まらないパイプみたいな処理にCUIでもGUIでも強制されるのがHaskellの一見不便で長所。 mfptnからmfputとmfwrite作ってる通り、関数に渡す出力先を差し替えるだけで良い。 >>100 それはLLとは言え、手続き型言語がハードの仕組みに依存してるから、Haskellと同じ程度にライブラリ化進めると、普通に書くより遥かにメモリに負担かかるって意味。 Haskellがメモリ効率が良いって言ってるわけじゃ無い。 >>103 既存の物を状態を扱うように変更するのにコスト大きい、と突っ込まれとるよね あとGUIは純粋に分けることを強制される、なんて簡単に終わる話じゃないんだよね 新規に同規模の実装を強制されるわけで >>104 だから結局空間計算量の話ししてるじゃん… ちうか、出力先を変更する云々なんて別にHaskell関係なくないか? どこがHaskellでしか出来ない処理と言ってるわけ? >>99 うい。 ぶっちゃけ大きめのファイルだとLLより遅いの体感出来るw んでも実用的な時間だし、上でパイプの例えあったけど言い得て妙で、 LLでforとかeachとかでループとして処理するのもメソッドチェーンみたいにファイル名のリスト受け取って、 中身のリスト受け取って。。。ってパイプ処理して行くから、LLより考え方が流れを辿る感じでシンプルなんだよね。 速さよりも書き易さ優先。 速さ気にしてたらそもそもHaskell選んでない。 速さが我慢出来なくなったらCで書くよ。 ネットでperlで1000万行のファイルの行を逆順にしたいっての見つけて、Cで書いたんだが、3.1GBにもなるファイル読み込ませて逆順表示はCでも待ったな。。。 (一旦全部上から読んで位置情報を配列に入れて、最後に記録した位置から逆に辿る手法だったけど、メモリは4GBメモリの0.6%しか消費してなかった) Haskellでメモリに溜め込む書き方でも10万行くらいは我慢出来るレベル。 LLならCと同じ手法でメモリに負担かからない方法で書けるだろう。 実はHaskellにもhSeek関数あるから、多分メモリに負担かからない方法で書けると思う。 でも、もうそこまで行くんならCで気持ちよく書く。 やっぱり本気でパイプのようなストリーム処理がLLで書けないと思ってるのかな 今時はラムダなどのストリーム処理なんてJavaですら標準でついてるってのに >>108 何が「ほんまもん」なんですかね もしかしてどっちもO(1)で一緒とか言いたいの? 空間計算量って、それ自体はO-notationでの表記のことじゃないぞ? 「副作用で世界がどんどん変わって行くのを俺が全部コントロールして阻止しなければならない… そうでなければこの世界はバラバラになってしまう…」 「どうしたんですか?先輩」(もぐもぐ 「おお後輩!…なんだそれ?」 「売店がパンじゃなくて弁当扱い出したんですよ ゴミかさばるから売店とこで捨てろですって。 まぁ、どうせ僕が一括して持ってくんでしょうがw」 「後輩」 「はい?」 「カレーある?」 「たしか」 「じゃあ、それ一つ」 「はい」 >>107 うーん。。。出力先もだけど、差し替え易さとか、処理対象の単位を行き来し易いとか。。。かな? ループだとファイル単位、行単位、文字単位って決まっちゃうと、中々そこから抜け出せないけど、例えば複数ファイルの行で一番長い行を調べたいとする。 (実はCで上の逆順コード書く際のバッファの大きさを決めるために書いた) 最初、トーナメント形式に各ファイルで一番長い行出させて、そこからさらに一番を決めて出力してた。 んで、途中で全ファイルの行の長さ出た時点で一位決められるじゃん。と、数値のリストのリストを平坦化して一気に一位決めた。 そう言うループじゃ無くて、悪魔でリストのリストを受け取って〜。。。って考えると簡単に行単位とかそう言う枠を超えられる。 LLでも出来るだろうけど、思いつき易い。 >>110 いあ、書けるでしょうよ。 ただ柔軟性?こう、スタイルが決まっててあんま動かせない感じを受ける。 >>109 言いたい事はわからんでもないけど、そんなにhaskell使いやすい? 自分もHaskellは複雑な構造の解析とか、何か本質的な部分の問題解くときにghci使う事あるけどさ、 実装はやっぱりpythonとかのが楽ってなったよ Stackやcabalの設定編集も面倒だしコンパイル遅いし mapM_あたり使うような物で純粋を目標にしてると、本末転倒になる事が多いし >>112 ああなるほどね 難癖つけてる奴の同類か >>114 ポイントフリースタイルとの組み合わせは確かにHaskell特有だけど、 個人的には実装はIOの文脈で、パイプ演算子とパターンマッチを使える F#やLiveScript(altJS)のような言語方が楽だと思うぞ >>115 なんつーか、さすがにGUIとかはC#使うわってなるけど、確かにコンパイル遅くて微妙に感じもしたけど、上のライブラリみたくガンガン関数化すればPythonでループのシーケンスにargv[1:]ってしてー。。。 逆順だとReversed(list(sys.argv[1:]))でー。。。とか調べないとな場面が度々ね。 んで、毎回複数ファイルから読み込まるのにforって書いて、行毎だとまたfor。。。 Haskellもライブラリ作る前は似たり寄ったりだったけど、ライブラリ書いてからはmfputにファイル名のリストと、各ファイル向け(1ファイル向け)に処理させたい関数渡すだけで大体のツール作れる。 多少パターンが特殊でもmfptnで対応出来る。 ループ的なのを関数に押し込んで、開きたいファイルと処理させたい関数だけ気にしてれば良くなった。 (逆にサポート外のパターンには無力だが。関数化は使い方も規定しちゃうから仕方ない) Pythonだとあんまここまでライブラリ化出来る気がしない。。。 PythonやRubyの書き捨てでも楽だって思ってたけど、多分もう戻れない。 まずなー>>98 に>>100 をいっちゃう時点でなー >>96 で「空間計算効率が良いなんて一言も言ってない」って明言されてるにも関わらずこんなこと言ってる時点で読解力お察しだからなー 相手の意図を組めないという点ではエンジニアガイジと同類っぽいなー そう。 空間計算効率の話自体はしてても、Haskellと同程度にライブラリ化したらLLが今までより空間計算効率が落ちる(もしくはイテレータ地獄になる)って言ってるだけで、Haskellの空間計算効率が良いなんて言ってない。 初めてKotlinで書いてみたけど意外と悪くないな 驚きが非常に少なく無理がない C#みたいな天才肌とは違ってとにかく無難でつまらない印象だけど、 Javaからの乗り換えという意味では最適なとても筋のいい言語だと思うわ import java.io.File fun Sequence<String>.grep(w: String) = this.filter { w in it } fun redstr(w: String) = "赤(${w})" fun counsnum(i: Int, xs: String) = "%4d:%s".format(i, xs) fun numbering(lines: Sequence<String>) = lines.mapIndexed({ i, xs -> counsnum(i + 1, xs) }) fun main(args: Array<String>) { val (w, fs) = args val lines = File(fs). bufferedReader().lineSequence() numbering(lines).grep(w).map({ redstr(it) }) }.forEach({ println(it) }) } >>122 kotlinのコードこのスレで初めて見たし、他のスレでもここまでまともなの見なかった。 thanks. わざわざ見つかった文字列を赤文字にする所まで再現してくれるとは。。。 もうHaskellに惚れちゃってるからメインにならんだろうけど、確かに筋は良さそう。 GUIなコード書くのには良いかもしれんね。 行単位で受け取って行単位で出力する辺り、やっぱ手続き型言語と感じるけど。 だからこそ効率が良くて、そこを意識するからこそ柔軟性の限界感じる。 HaskellはStringが遅いだけで、バッファ効率自体は多分良い。 行単位とかじゃ無くて目一杯バッファに入れてると思う。 ByteString慣れないと説得力無いんだろうけど。。。 面倒いなぁ。。。 そこまでしないと勝負にならないなら、あんたの勝ちでいいよって思うもん。 手早く書けて使える速度なら充分だし。 >>119 明言してると言っても実際言ってるし やっぱり難癖つけたいだけじゃん >>120 お前もうただ言い方に突っかかってるだけだろそれ >>118 引数の逆順でファイル読み込んで一つのイテレータにするだけなら、pythonならこれだけじゃね? (x for f in argv[1:][::-1] for x in open(f)) これをイテレータを処理する関数の引数に渡せば、お前のやりたい事できてるよね? そうも書けるんだ。 でももうcatコマンドだったら main = getArgs >>= mfput fs id って書けば良いようにライブラリ作っちゃったし、もう良い。 mf = マルチファイル >>123 入出力関数が適切にバッファリングしてると思うけど? 逆順だとunlines.reverse.linesしないと改行が変になるから main = mfput fs (unlines.reverse.lines) unlines.f.limesパターンも良く使うから main = mfput fs (fline reverse) って書けるようにしたし。 あ、 main = getArgs >>= mfput fs (fline reverse) だった。 >>128 うい、行単位でね。 Haskellは基本ファイルの中身を丸ごと文字列で受け取って、文字列で返すから、行って考えはナンバリングしたいとか、行単位で処理したいって思った時に初めてunlines.f.linesパターンで行単位に分解する。 なので出力するHaskellランタイム側にも行単位って概念が無い。 >>131 行単位じゃないぞ 単純に間違ってるから事実だけ書くけど まあ、そんな事してるからHaskellは遅いんだろうなってのはある。 文字単位でバッファ目一杯入出力するけど、加工過程で分解して戻してってしてるんだし。 >>132 なるけど、見かけのコードは行単位でも、バッファリングはそれとは別に行を越えて処理すると。 これは失礼。 >>130 さらに馬鹿だ。。。 寝惚けてる。 部分適用し易いようにfsが第二引数だから main = getArgs >>= mfput (fline reverse) これだけで良いんだった。 KotlinはJava標準ライブラリに対する拡張も上手い Javaに背を向けたScalaとは違って、Java標準ライブラリの良いところ駄目なところを深く理解して 最小限でツボを押さえた拡張を入れてる Scalaが一瞬で要らない子になったのも納得 >>126 ついでに言えばPythonのは逆順でもメモリに溜め込まないはずで、大きなファイルだとPython使った方がいいってことになる。 でも、今時のスペックで問題になる程溜め込む場面自体が無い。 小説100冊分が1ファイルに入ってやっとちょっと気になるレベルだから。 なら、より短く書ける方がいい。 コンパイル遅いつっても書き捨てレベルなら毎度毎度定型的にPythonで書いてる時間で終わってる。 自分でライブラリ作ってからは完全にLL的な使い方はHaskellで良いやってなった。 素のままだとPythonのが良いけどね。 自分でライブラリ作るかどうかが決め手だった。 複数のファイルを順番に読んでいって、特定の文字列が見つかるまで入力をそのまま出力する 文字列が見つかったら即終了 ってプログラムを、その自慢のライブラリで書いてみてよ 行単位なのはダサいといいながら自分のライブラリはべったり行単位に依存してるのが笑いどころだな 結局行単位が便利だと思う人が多いからlineSequenceみたいなユーティリティが標準で用意されてるだけで、 やってることはunlines.f.linesと変わらんぞ >>138 import System.Environment import Data.List import Myfunc main = getArgs >>= (w:fs) -> mfput (unlines.lines.last.(takeWhile (not.isInfixOf w)).inits) fs import System.Environment import Data.List import Myfunc main = getArgs >>= (w:fs) -> mfput ((++ "\n").last.(takeWhile (not.isInfixOf w)).inits) fs unlines.lines要らんかった。 直後って書いてたから最初の検索文字列全部表示される前に終了かと思って上のコードにしたけど、最初の検索文字列表示した時点で終了なら、takeWhileをdropWhileにして、lastをheadにすれば良い。 >>122 >>136 メインプロジェクトとしていろいろ試して選んだって感じなのね androidの主力開発言語を急に乗り換える必要が発生したから当然だけど (な?うざいだろ?by 某M社) OCAMLを.netで記法(not構文)変えて作りましたって感じ>F# 冗長記法だとOCAML互換性高いし ***SLAMO*** } 000-"F","TAP","0","1M","L","E-07"/0B"[9BA%]"^"2*73B"="0"/"9GA" 001-"Do"[[[%9DE=HUF%%!%$0B1OTU"NE"]]]<\b> 002-<<%!!!HNDEL%!0DAI@$7[1B]!0#!@>> 3000-{{1\B%HUF!0$$\%6/0Q\%6/GA[[7BU]]%9TE!%$en$}} --- [[[C%%]]] } 000-"5802"/"α"="0.1888412376155482"%en{ F# は 関数型らしい抽象化機能※ を持っていないのが欠点 抽象化は .NET ( C# ) 互換の抽象クラスやインターフェースで実現することができる でも型推論が効かなかったり null 安全でなかったりして辛い ※OCaml では構造的部分型やモジュール抽象化 Haskell では型クラスや型族のこと 型だけを見ればC#とF#は同じだろ Haskellだって型だけを見れば他の言語で同じものは作れる 型だけを見るのが王道 逆に型を無視してHaskellにしかないものを強調するのは邪道だから 惑わされるなよ 次世代言語でHaskell並にちゃんとした型システムが入ってる言語ってある? Haskell並ならちゃんとしてるというのは本当か? ちゃんとしてないから「Haskell並」や「Haskellよりマシ」と言い訳するんじゃないか 構造的部分型が「ちゃんとしてる」かは大いに疑問 あんなもんドカタITで使ったら悪夢だろ >>151 Haskellの機能じゃないし、その上根拠もない >>150 静的型に限って言えばHaskellは上位でいいんじゃない? 強いて言うなら、TypeSynonymなクラスインスタンスぐらい言語標準で入れてほしいけど 中途半端な奴だな オレが一位だというならまだわかるが Haskellが上位だという主張の何が嬉しいのか 古い関数型言語関係の本だと、論理型言語が関数型言語の次の世代とか書いてて、まあ実際最近ワトソンやらペッパーやらAI関係で注目されてるのも論理型言語な訳で。 んじゃPrologはHaskellより使い易いんか?と勉強中。 早くもコレジャナイ感が。。。 もっと今時の論理型言語って無いんかな。 >>154 また話の流れ無視してケチつけてる ちゃんとしてるって意味だよ 競争に勝つためにケチをつける自由がある 負ける自由もある 好きな方を選べ あ、そう言うこと言っちゃう? おいらのライブラリ(>>84-85 )の肝はmfputとmfwriteだが、結局他の言語で同じ様な関数作ってない。 当然だ。 Haskellは手続き型言語のforにあたるmap系の関数もそのまんま関数だし、Haskellだと自然に出力系は最後尾に追いやられるから関数化しやすいんだよ。 普通の言語は処理しながら出力する。 確かに効率が良い。 だが、再利用し難い。 今時のPCなら効率より再利用性のが重要だと思うんだ。 異論は認める。 ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる