次世代言語議論スレ[Go Rust Scala Haskell]第5世代

1 名前：デフォルトの名無しさん mailto:sage [2017/06/13(火) 08:54:07.99 ID:O1HnBMDk.net] いざ、語ろうぞ。 スレタイ超過のため、一部省略。 その他もウェルカム。 前スレ 次世代言語議論スレ[Go Rust Kotlin Scala]第4世代 mevius.2ch.net/test/read.cgi/tech/1492631007/ 24 名前：デフォルトの名無しさん mailto:sage [2017/06/13(火) 19:35:55.51 ID:lP4lhg4O.net] >>20 何のためにdebやrpmに「foobar-dev(el)」ってパッケージがあると思ってる 言語自前のライブラリ管理システムがないからディストリビューションのパッケージ管理に乗っからないとやってけないからだろ そういうものをCプログラミングと認めないなら好きにしろ 25 名前：デフォルトの名無しさん mailto:sage [2017/06/13(火) 19:41:20.40 ID:wCVClZJy.net] そういや、まともな検証プロセスの無いままライブラリが提供される 言語独自のパッケージ管理システムは、OS全体の安全性を脅かしてるってDebianの中の人が嘆いてたな 26 名前：デフォルトの名無しさん mailto:sage [2017/06/13(火) 19:41:27.69 ID:lP4lhg4O.net] 別に全手動を否定するつもりはないが、 debやrpmが積み上げてきたものを蹴飛ばして 全手動こそがCって言われると違和感があるって話な 27 名前：デフォルトの名無しさん mailto:sage [2017/06/13(火) 19:51:19.56 ID:lP4lhg4O.net] >>25 npm pip gem辺りはひどそうだ goはシステムとは完全にパス分けてる cargoはどうだっけ？ 28 名前：デフォルトの名無しさん mailto:sage [2017/06/13(火) 19:53:36.19 ID:o0nyK+Xq.net] ソースコードを読む人は時間の感覚が違うだろ インストールに1日かかっても1日損したと思ってない 自分で書くより早いから得してるし 読むだけでも1日や2日では終わらない 29 名前：デフォルトの名無しさん [2017/06/13(火) 20:32:10.33 ID:+kV5cJp9.net] >>24 「ライブラリが野良orOS配布だから良くない」という意見に「それは別に良い」って言ってるだけやん。ちょっと言葉は過ぎたかもしらんけどそんな噛み付かんといてよ 30 名前：デフォルトの名無しさん mailto:sage [2017/06/13(火) 22:35:13.45 ID:ZpGuJRaH.net] 環境含めて考えれば 簡易な言語 + チェックツール のが正解な気はする。 rust みたいに言語で縛るってのがそもそも間違いじゃねーの。 31 名前：デフォルトの名無しさん mailto:sage [2017/06/13(火) 22:41:55.07 ID:blSfEUfZ.net] >>30 より安全なC言語（チェッカーだったり、標準ライブラリの置換だったり）って今までたくさんあったけど、どれも普及しなかった Microsoftも作ってたはず なので、Rustは今度こそは！感がある 32 名前：デフォルトの名無しさん mailto:sage [2017/06/13(火) 22:52:41.30 ID:Hy7s+J5v.net] >>29 言葉きつかったなすまん 33 名前：あ mailto:sage [2017/06/14(水) 13:01:02.27 ID:0gE91xz7.net] >>24 何のためにって、そりゃ、ソースを検証せず、各配布元見てアーカイブのハッシュも見ず、 正しいとコミュニティが認めたものをコミュニティへの無限の信頼で横着して手に入れるためにじゃん。 現実的だけど。 >>30 チェックツールを実用レベルまで持ってくと、言語への縛りが結局キツ 34 名前：くなるよ。 停止性問題みたいな話になってくる。 [] [ここ壊れてます] 35 名前：デフォルトの名無しさん [2017/06/14(水) 14:06:06.69 ID:4UjMkIWv.net] Cの文化とPythonの文化は方向性が全然異なる 昨今の統計事情から察するに、応用を考えるにあたってはPythonの文化の方が優れているだろう つまり、細かいことは言語作者やライブラリ作者に全部任せて、考えたいことに集中できる文化の方が発展が速い 36 名前：デフォルトの名無しさん mailto:sage [2017/06/14(水) 14:32:38.36 ID:SGVDPQnB.net] Cの中に全然異なる二択があると言われたのをもう忘れたか 忘れるの速すぎ 37 名前：デフォルトの名無しさん [2017/06/14(水) 14:35:24.56 ID:4UjMkIWv.net] >>35 二択って何？このスレで二択で調べても「野良orOSのパッケージ管理」しか出ないんだけど 38 名前：デフォルトの名無しさん mailto:sage [2017/06/14(水) 14:38:55.46 ID:SGVDPQnB.net] リテラシーゆとり教育orバイナリまとめサイト 39 名前：デフォルトの名無しさん [2017/06/14(水) 14:47:06.53 ID:4UjMkIWv.net] よくわからんしまあいいや Pythonの例から考えるに、少なくとも応用分野では次世代に流行る言語は強力なライブラリを簡単に導入でき、すぐに目的コードが書けてしまうと言った特性を有しているでしょう 40 名前：デフォルトの名無しさん mailto:sage [2017/06/14(水) 14:59:43.37 ID:W7dgH5v3.net] FORTRANの駆逐に長い時間が掛かったのはライブラリ遺産のせいだって聞いたことがある。 41 名前：デフォルトの名無しさん [2017/06/14(水) 15:11:13.20 ID:4UjMkIWv.net] その通り。Fortran77はクソだけど、新しい言語を使おうとしても移植作業も新規に書き直す作業も面倒なので、そんならいいやとFortranを使い続けてきた そこに持ってきてpip install scipyのワンコマンドでblas lapackの多くのサブルーチンの良質なラッパーをインストールし、よくわかってない学生でもfrom scipy.linalg import eig 出来てしまうPythonは本当に偉大であった 42 名前：デフォルトの名無しさん mailto:sage [2017/06/14(水) 20:07:23.71 ID:rnctBDZd.net] まあ今ある blas より速いの作るなんて普通のプログラマには不可能だしな。。 43 名前：デフォルトの名無しさん [2017/06/14(水) 21:17:37.82 ID:i/E7QqbY.net] Haskell復活してるやん 44 名前：デフォルトの名無しさん mailto:sage [2017/06/15(木) 01:45:20.34 ID:wmi6uQsI.net] >>42 Kotlin引退で繰り上がり 45 名前：デフォルトの名無しさん mailto:sage [2017/06/15(木) 03:30:08.09 ID:TdjK6zBT.net] つまり実用できる状態になるとスレタイから外されるって事だよな ここに残ってるのはいつまでも「次世代」言語 46 名前：デフォルトの名無しさん mailto:sage [2017/06/16(金) 00:53:52.07 ID:NKsegnSN.net] 現時点のKotlinレベルでいいならGo,Rust,Scalaは実使用されつくしてるような 47 名前：デフォルトの名無しさん mailto:sage [2017/06/16(金) 02:31:19.78 ID:57lFqmer.net] Go ScalaはともかくRustは絶対にねえよ 48 名前：デフォルトの名無しさん mailto:sage [2017/06/16(金) 08:26:01.05 ID:VSZ6CfqO.net] 実用できる次世代言語はkotrin typescript だよね 実用できない次世代言語がスレタイ 49 名前：デフォルトの名無しさん mailto:sage [2017/06/16(金) 09:11:14.72 ID:XLEAF0GD.net] mozilaの落ちぶれっぷりがやばい 50 名前：デフォルトの名無しさん mailto:sage [2017/06/16(金) 10:10:44.42 ID:sGqUlQsg.net] >>48 元からあいつらただのヤクザ 大義名分のメッキの裏がGoogleやAppleの経済活動で暴かれただけ 51 名前：デフォルトの名無しさん [2017/06/16(金) 10:22:55.63 ID:Elc9SXXc.net] 個別スレある言語の話はそっちでヤレばいいじゃん ここは個別スレ無いやつ専用にしろよ 52 名前：デフォルトの名無しさん mailto:sage [2017/06/16(金) 10:54:04.49 ID:is6DCp5t.net] パッケージ管理システムとかガベコレの一般論専用かな 一般論の個別スレないよね 53 名前：デフォルトの名無しさん [2017/06/16(金) 11:04:24.01 ID:yA2bsaGi.net] 日産自動車栃木工場 塗装課、車軸課の正社員の方々の要求はコピペ継続の保守 ２ちゃんねる愛用の方々にお知らせ 栃木県上三川町3-5-2 日産自動車上三川寮 管理人は合鍵を使い従業員の部屋に無断で侵入 。 抜き打ちで従業員の私物を全て調べるブラックの中のブラック企業。 期間工が看護師を殺害する事件もあった危険企業。 離職票を発行するのに一月以上もかかるとの情報もあり期間工の生活事情はお構い無し。 このコピペによる日産の悪事の拡散は日産正社員の断固たる要望である。これには日産と無関係の第三者が便乗している可能性が高く自分は不自然に感じている。 0647 FROM名無しさan 2017/06/01 21:21:43 いいからこんなとこで油売ってないで早く100万コピペ達成してこいよｗｗｗ ほら早よ行けやホラホラｗｗｗ 返信 ID:bEv8YiM0(7/7) ↑↑このように必死で日産の悪事を拡散しろと煽っている。俺は脳無しで馬鹿なので日産正社員が日産悪事を公表するように煽ってきた理由が分からない。不本意ながらコピペを続けている。 54 名前：デフォルトの名無しさん [2017/06/18(日) 01:50:03.42 ID:LYWH9ARf.net] 個別スレない言語オンリーならRacket無双になるがよろしいか 55 名前：デフォルトの名無しさん mailto:sage [2017/06/18(日) 13:22:25.92 ID:BG5e9Vcc.net] あとは歴史的変遷からみる次世代言語とか 56 名前：こんな？ mailto:sage [2017/06/19(月) 16:27:30.01 ID:PFGmiz2v.net] 今SunがJavaっての作ってるらしーぜ どんな言語だろうな？ 57 名前：デフォルトの名無しさん mailto:sage [2017/06/24(土) 15:20:30.76 ID:+EJLhPmM.net] Googleがヘルスバーグ（C#）級の人をスカウトしてきて メインプロジェクトとして本気の新言語作ったとしたらどうなるか見てみたい GoもDartも最初の言語設計がイマイチ感は否定できないんだよね 58 名前：デフォルトの名無しさん mailto:sage [2017/06/24(土) 16:06:03.03 ID:iOfeax4r.net] 静的型と動的型のハイブリッドはTypeScriptで早くも完成させちゃったから、 次にヘルスバーグが手がけるとしたら完全な型推論ベースの静的型言語をやってほしい 59 名前：デフォルトの名無しさん [2017/06/24(土) 16:23:53.98 ID:pQNLYnE6.net] ヘルスバーグすこ Googleの作る言語はゴミばっかや 60 名前：デフォルトの名無しさん [2017/06/24(土) 16:28:25.84 ID:TM1thEne.net] ヘルスバーグだってMSが敵わなかったからライバルから引っこ抜いたんだろ 61 名前：デフォルトの名無しさん mailto:sage [2017/06/24(土) 16:51:36.76 ID:aCsrIsWK.net] なんだかんだ言ってもOS自体を書く言語は変わってないからな 62 名前：デフォルトの名無しさん mailto:sage [2017/06/24(土) 21:54:51.34 ID:UUr+9hAP.net] >>56 今ならSwift開発したクリス・ラトナーが絶賛求職中やで。 63 名前：デフォルトの名無しさん mailto:sage [2017/06/24(土) 23:50:07.30 ID:UHmd/ofd.net] Googleってゴスリンやゲイドも飼ってたことあるよな 一瞬で辞めたけど 会社の体質に問題があるんだろうね 64 名前：デフォルトの名無しさん mailto:sage [2017/06/25(日) 08:44:29.52 ID:JxQEbk3c.net] kotlinとswiftどっちが有望？ 65 名前：デフォルトの名無しさん mailto:sage [2017/06/25(日) 08:59:11.73 ID:JM0saPft.net] どっちも有望だが、どこを比較してほしいんだ 66 名前：デフォルトの名無しさん mailto:sage [2017/06/25(日) 09:10:38.04 ID:JxQEbk3c.net] 学ぶならどっちがいいのかなと思って 67 名前：デフォルトの名無しさん [2017/06/25(日) 10:07:31.69 ID:ZFXP5+sH.net] Androidのアプリ作りたいのか、iOSのアプリ作りたいか それだけの話なのに何で自分で決められないんだろ 68 名前：デフォルトの名無しさん mailto:sage [2017/06/25(日) 10:21:57.72 ID:JM0saPft.net] 何のために学びたいんだ 69 名前：デフォルトの名無しさん mailto:sage [2017/06/25(日) 10:24:20.80 ID:by7iMnGq.net] kotlinは既にJavaをマスターしててサンプルコードの雰囲気を見ただけでなんとなく書き始められるくらいの人が使うもんだぞ 勉強するもんじゃない 70 名前：デフォルトの名無しさん [2017/06/25(日) 12:21:22.67 ID:BOhr0vIe.net] 今Haskellでよく使う処理をガンガン関数にしてライブラリ化してるけど、LLでもここまで短く書けないだろと言うか、 ここまでライブラリ化するには遅延評価じゃないとreverse使わないような処理でもメモリに溜め込むか、 遅延評価にする為にイテレータ作りまくりじゃないかと思った。 いあ、最上位の関数とかは短く書けるんだろうけど、ライブラリ内部の似たような処理を ガンガン関数にして行くのは流石に難しいと思う。 71 名前：デフォルトの名無しさん mailto:sage [2017/06/25(日) 12:39:35.65 ID:mZBbGFn8.net] >>69 つづきはブログでおやり 具にもつかない報告を読まされる身にもなってみろ お前のレスは今後一切いらんからなこのスレには 72 名前：デフォルトの名無しさん mailto:sage [2017/06/25(日) 12:53:31.73 ID:ETAvV0eF.net] linux のソース見る限りは c にまともなマクロが用意されればそれで十分。 まあまともなマクロを用意するってのは言うほど簡単じゃないだろうけど。 73 名前：デフォルトの名無しさん [2017/06/25(日) 13:33:53.23 ID:BOhr0vIe.net] >>70 じゃあLLでも何でもいいけど、手続き型言語でよく使う処理をガンガンライブラリ化してみてよ。 どっちがより汎用性と簡潔性を両立出来てるか競おうず。 74 名前：デフォルトの名無しさん mailto:sage [2017/06/25(日) 13:58:29.36 ID:by7iMnGq.net] Haskelは実装変更のインパクトがでかくてカプセル化的な考え方で作るには向かないんだよな 実用言語としてガチ関数型を流行らせるには厳密性を維持しつつ現実の大規模開発でのモジュール化も考慮した仕組みを作らないと 75 名前：デフォルトの名無しさん [2017/06/25(日) 14:13:01.18 ID:/Sm2Vorl.net] >>73 Cでcatコマンド自作しようとした時、複数ファイルから一番長い一行あたりのバイト数(文字コードによって違うので文字数ではダメ)調べるコマンド作った時、 lengthはByteStringモジュールを使いたいけど、mapは標準のを使いたい(ByteStringのmapはByteString -> Char特化)って時に細かくどれは読み込んで、どれは読み込まないってしたけど、 それじゃあかんの？ モジュール読み込みの設定だけ変えれば、main以下は全く同じコードがバイト数と文字数切り替えれるけど。 76 名前：デフォルトの名無しさん mailto:sage [2017/06/25(日) 14:24:06.30 ID:WUy1L4jW.net] >>74 すまん全く意味がわからない 73からいきなり抽象度が下がりすぎだろ ハスケラならもうちょっと抽象的かつ厳密で明示的なレスを頼む 77 名前：デフォルトの名無しさん mailto:sage [2017/06/25(日) 15:21:38.85 ID:mZBbGFn8.net] >>72 なにが「じゃあ」なん？ 脳みそ腐ってんの？ しょーもないレスでスレ汚すのやめてくれマジで 78 名前：デフォルトの名無しさん [2017/06/25(日) 16:41:08.55 ID:p9Z6xhSy.net] >>75 抽象度が高い=フワッとして概念的って思ってたんだが違うんか。。。 import書く時、この関数だけ読み込まない。 この関数だけ読み込むって指示できるから、そこだけ弄ればそこ以下のコードは書き換え無しに 文字数数えるかバイト数数えるか動作を切り替えられる。 79 名前：デフォルトの名無しさん [2017/06/25(日) 16:53:53.40 ID:p9Z6xhSy.net] >>76 うんうん。 分かるよ。 式と文が入り混じるから関数化する単位に限界あるもんね。 副作用と純粋部分の区分けが強制されないというか、遅延評価じゃないと強制されたらreverse使ってなくてもメモリに溜め込むコードになっちゃうし。 それを解消する為にイテレータ書きまくるのも面倒だもんね。 Cくらい速かったら、それを飲み込むのも我慢出来るのにね。 80 名前：デフォルトの名無しさん mailto:sage [2017/06/25(日) 17:24:16.31 ID:rLWYKb/E.net] この勘違いしたハスケラを黙らせるには、 ハスケラ自慢のライブラリを見せてもらって、 それより簡潔なコードを書くしかないと思う 81 名前：デフォルトの名無しさん mailto:sage [2017/06/25(日) 17:39:45.42 ID:wtr2uEYx.net] >>77 例えば、引数の値のみにより完全に決定される値を返す関数があったとして ここに「ただし、前回と値が同じ場合は前回より1だけ大きい値を返す」という要件が増えたらどうする? 82 名前：デフォルトの名無しさん [2017/06/25(日) 17:56:09.21 ID:pYBZiqDJ.net] >>80 Haskellも状態扱えない訳じゃないし、大量に状態保持す代名詞のGUIプログラミングが、HTMLやXAMLで書かれるのに一定の地位を確立した今となっては、そういうDSL、又はDBに状態保持させて、Haskellは同じ値が来たら外部に+1してってお願いすれば良いと思うけどね。 83 名前：デフォルトの名無しさん mailto:sage [2017/06/25(日) 17:59:09.81 ID:wtr2uEYx.net] >>81 つまりインパクトが大きいってことだね 84 名前：デフォルトの名無しさん [2017/06/25(日) 18:12:35.96 ID:pYBZiqDJ.net] 何言ってんのか分からんけど、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 85 名前：デフォルトの名無しさん [2017/06/25(日) 18:17:06.53 ID:pYBZiqDJ.net] ライブラリ内部にも似た様なパターンを関数化して無駄に似た様な少し違うコードが少ない様にしてる。 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)) 86 名前：デフォルトの名無しさん [2017/06/25(日) 18:17:18.21 ID:pYBZiqDJ.net] 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 87 名前：デフォルトの名無しさん mailto:sage [2017/06/25(日) 19:00:45.29 ID:rLWYKb/E.net] それライブラリ化する価値もなさそうな 汎用性の無いコードにしか見えんが、本気か...？ 88 名前：デフォルトの名無しさん [2017/06/25(日) 19:04:10.51 ID:pYBZiqDJ.net] >>79 ワザとウザい役したけど、実際問題再利用のし易さと速度はある程度トレードオフな関係だと思う。 それならHaskellとCで良いんじゃないかってなった。 個々人でバランス感覚違うから、他の言語を選択するものアリだけど。 89 名前：デフォルトの名無しさん [2017/06/25(日) 19:11:04.69 ID:pYBZiqDJ.net] >>86 まだ育ててる最中だしね。 複数ファイル読み出し、複数ファイルそれぞれ出力なパターンはこれで行ける。 複数ファイルから一つの結果求めるパターンはこれから作るし、他の関数と共通パターンあったら、関数化して行く。 正気か？って言うけど、forとかメソッドチェーンな中身とか途中のメソッド入れ替えるとか、そう言うことしてる様な感じ。 こんな関数化の方法、オブジェクト指向言語では考えもしなかったぞ。 90 名前：デフォルトの名無しさん mailto:sage [2017/06/25(日) 20:27:51.46 ID:k3/0SUsA.net] Haskell使いのレベルの低さが知れるな こうゆうのを繰り返すならやっぱり次はまたHaskellはずそう 91 名前：デフォルトの名無しさん mailto:sage [2017/06/25(日) 20:33:29.70 ID:h1su++jx.net] ていうかHaskell自体は全然次世代言語じゃないじゃん Haskellの一部分を参考にした次世代言語はあるけど 92 名前：デフォルトの名無しさん mailto:sage [2017/06/25(日) 20:59:18.08 ID:+XToNy/r.net] Idrisとか？ 93 名前：デフォルトの名無しさん [2017/06/25(日) 21:00:59.61 ID:pYBZiqDJ.net] ええ。。。 最近こそラムダ式とか入ったけど、オブジェクト指向って相変わらず手続き型言語で、コンストラクタって結局構造化プログラミングで言うinit関数でしょ？みたいな感じで処理の分け方が上中下って感じなんだもん。 おまけに肝心の中身はインターフェースでそれぞれのクラスに別々に書いてねとか。 似た様なコード何度も何度も書いてるなー。。。って感じだった。 LLにしても、書き捨て毎に似た様なコード書いてるなー。。。って。 Haskellだからここまで関数化しても遅延評価でメモリを一定以上消費しないんだと思うし、mfput関数一つ書けば中身の処理を考えるのに集中出来た。 (mygrepnとか見つかった文字列を強調赤字にするオマケ付き。 rpとかコマンド名が競合するから短い名前だけど、地味にコード書き換えに活躍してる) 実際に上のコードと同じライブラリ書いてみてよ。 パターンは共通って分かってても、文が邪魔したり、メモリに溜め込む処理になるから断念する場面が出てくると思う。 94 名前：デフォルトの名無しさん mailto:sage [2017/06/25(日) 21:18:47.33 ID:8QFIS7Xe.net] >>89 >>76 >>70 まともに叩くことも出来ないレベルのクソ野郎は入ってくんなよ… お前らみたいなのがいるから、変なのが増長するんだろ 95 名前：デフォルトの名無しさん mailto:sage [2017/06/25(日) 21:38:11.91 ID:8QFIS7Xe.net] >>92 結局パイプ的に繋いでく話してるだけだな はっきり言うが、Haskellでまともなプログラム組んでIO扱う途端にその手の使い方はできなくなるよ その言ってる方法突き詰めたとして、リアクティブプログラミング的になるが、 遅延評価が仇になってサンク作りまくる場合はあるし、遅延評価だから空間計算効率が良いなんて話にもならない Haskell自身もメモリの効率がいいわけでもない 女アクのGHCのランタイムがまずクッソでかいし 何よりリアクティブプログラミングじゃ、現代のGUIでまともなプログラム作れない IOなGUIツールキットをリアクティブに対応させるコード書いてる暇あったらIOで書いた方がマシだ 96 名前：デフォルトの名無しさん mailto:sage [2017/06/25(日) 21:42:36.54 ID:8QFIS7Xe.net] 正確にはリアクティブプログラミングじゃなくてFunctional Reactive Programingだな リアクティブだけなら、一つのシグナルストリームでなく分散メッセージでいいし難しくはない 97 名前：デフォルトの名無しさん [2017/06/25(日) 22:00:46.32 ID:pYBZiqDJ.net] >>94 空間計算効率が良いなんて一言も言ってないが。。。 悪魔で再利用し易さの割にってだけ。 んでもLLと同程度ならほとんどの場合で問題にならないので、このままライブラリ化進めればLLよりチマチマしたの作るのに都合が良い言語になると言うか、既になってる。 半端にLLで空間計算効率考えるよりは、普段はHaskellで富豪的だけどLLより再利用し易いコード書いて、そう言うの重要な場面ではCで書けば良いやってなった。 今時のメモリ搭載量だと小説10冊分が1ファイルに入ってても問題にならんから、実用上ほとんど問題にならん。 それが問題になる時は処理速度的にもLLでも対処出来ない。 98 名前：デフォルトの名無しさん mailto:sage [2017/06/25(日) 22:10:00.00 ID:8QFIS7Xe.net] >>96 お前さっきからメモリの話ばっかりしてるじゃん… それに再利用については、途中からIO入れたら使えないよね？ っていうツッコミに全く反論できてないし 言ってる事めちゃくちゃだぞ 99 名前：デフォルトの名無しさん [2017/06/25(日) 22:16:17.15 ID:GaCuKOAB.net] >>97 「関数型で書いてもメモリを一定量以上使わない」を「空間計算効率が良い」と解釈するのはいくら何でも頭発達しすぎでしょ…… 100 名前：デフォルトの名無しさん mailto:sage [2017/06/25(日) 22:20:20.12 ID:8QFIS7Xe.net] ちなみにCで書こうがIOの問題は付随するので変わらない そもそもパーサをTemplateHaskellとけ使って書いてるレベルならまだしも Haskellで型注釈も無しじゃコンパイル遅すぎだし、 リストを配列代わりにしたり、String使ってテキスト処理してるレベルじゃLLより遥かに動作遅いだろ 普段から使ってるとはとても思えない 101 名前：デフォルトの名無しさん mailto:sage [2017/06/25(日) 22:21:53.78 ID:8QFIS7Xe.net] >>98 いつ帯どこに突っ込んでんだよ メモリに溜め込む云々は明確にそういう話だろ 102 名前：デフォルトの名無しさん mailto:sage [2017/06/25(日) 22:22:12.23 ID:8QFIS7Xe.net] 変換ミス 一体どこに突っ込んでんだよ 103 名前：デフォルトの名無しさん mailto:sage [2017/06/25(日) 22:24:18.08 ID:8QFIS7Xe.net] え、まさか本当にストリーム処理書けないとかそんな話？ いくらなんでも違うよね？ 104 名前：デフォルトの名無しさん [2017/06/25(日) 22:27:27.12 ID:pYBZiqDJ.net] >>97 途中からとはなんぞな？ CUIにしてもGUIにしても、HaskellだとIO部分と純粋部分は強制的に分けて書かざるを得ないから何を言ってるのか。。。 (mfwriteでは同名ファイルに書き込めないので一旦別名で保存して、別名で開く->元の名前で保存ってしてるけど、そう言うのはIOが途中で挟まるってのと違うのん？) ある意味手続き型言語みたく(と言うか他の関数型もそう言う意味じゃ途中でIO挟まる？)、途中でIO挟まらないパイプみたいな処理にCUIでもGUIでも強制されるのがHaskellの一見不便で長所。 mfptnからmfputとmfwrite作ってる通り、関数に渡す出力先を差し替えるだけで良い。 105 名前：デフォルトの名無しさん [2017/06/25(日) 22:32:23.46 ID:pYBZiqDJ.net] >>100 それはLLとは言え、手続き型言語がハードの仕組みに依存してるから、Haskellと同じ程度にライブラリ化進めると、普通に書くより遥かにメモリに負担かかるって意味。 Haskellがメモリ効率が良いって言ってるわけじゃ無い。 106 名前：デフォルトの名無しさん mailto:sage [2017/06/25(日) 22:33:19.85 ID:8QFIS7Xe.net] >>103 既存の物を状態を扱うように変更するのにコスト大きい、と突っ込まれとるよね あとGUIは純粋に分けることを強制される、なんて簡単に終わる話じゃないんだよね 新規に同規模の実装を強制されるわけで 107 名前：デフォルトの名無しさん mailto:sage [2017/06/25(日) 22:33:55.06 ID:8QFIS7Xe.net] >>104 だから結局空間計算量の話ししてるじゃん… 108 名前：デフォルトの名無しさん mailto:sage [2017/06/25(日) 22:38:50.94 ID:8QFIS7Xe.net] ちうか、出力先を変更する云々なんて別にHaskell関係なくないか？ どこがHaskellでしか出来ない処理と言ってるわけ？ 109 名前：デフォルトの名無しさん [2017/06/25(日) 22:44:55.19 ID:GaCuKOAB.net] ヤバい、ほんまもんや（笑） 110 名前：デフォルトの名無しさん [2017/06/25(日) 22:56:39.77 ID:pYBZiqDJ.net] >>99 うい。 ぶっちゃけ大きめのファイルだとLLより遅いの体感出来るw んでも実用的な時間だし、上でパイプの例えあったけど言い得て妙で、 LLでforとかeachとかでループとして処理するのもメソッドチェーンみたいにファイル名のリスト受け取って、 中身のリスト受け取って。。。ってパイプ処理して行くから、 111 名前：LLより考え方が流れを辿る感じでシンプルなんだよね。 速さよりも書き易さ優先。 速さ気にしてたらそもそもHaskell選んでない。 速さが我慢出来なくなったらCで書くよ。 ネットでperlで1000万行のファイルの行を逆順にしたいっての見つけて、Cで書いたんだが、3.1GBにもなるファイル読み込ませて逆順表示はCでも待ったな。。。 (一旦全部上から読んで位置情報を配列に入れて、最後に記録した位置から逆に辿る手法だったけど、メモリは4GBメモリの0.6%しか消費してなかった) Haskellでメモリに溜め込む書き方でも10万行くらいは我慢出来るレベル。 LLならCと同じ手法でメモリに負担かからない方法で書けるだろう。 実はHaskellにもhSeek関数あるから、多分メモリに負担かからない方法で書けると思う。 でも、もうそこまで行くんならCで気持ちよく書く。 [] [ここ壊れてます] 112 名前：デフォルトの名無しさん mailto:sage [2017/06/25(日) 22:57:17.16 ID:8QFIS7Xe.net] やっぱり本気でパイプのようなストリーム処理がLLで書けないと思ってるのかな 今時はラムダなどのストリーム処理なんてJavaですら標準でついてるってのに >>108 何が「ほんまもん」なんですかね もしかしてどっちもO(1)で一緒とか言いたいの？ 空間計算量って、それ自体はO-notationでの表記のことじゃないぞ？ 113 名前：デフォルトの名無しさん mailto:sage [2017/06/25(日) 23:05:34.61 ID:CvCdLd6J.net] 「副作用で世界がどんどん変わって行くのを俺が全部コントロールして阻止しなければならない… そうでなければこの世界はバラバラになってしまう…」 「どうしたんですか？先輩」(もぐもぐ 「おお後輩！…なんだそれ？」 「売店がパンじゃなくて弁当扱い出したんですよ ゴミかさばるから売店とこで捨てろですって。 まぁ、どうせ僕が一括して持ってくんでしょうがw」 「後輩」 「はい？」 「カレーある？」 「たしか」 「じゃあ、それ一つ」 「はい」 114 名前：デフォルトの名無しさん [2017/06/25(日) 23:09:52.30 ID:GaCuKOAB.net] ヤバいこいつ論点分からず突っかかってる 115 名前：デフォルトの名無しさん [2017/06/25(日) 23:11:04.64 ID:pYBZiqDJ.net] >>107 うーん。。。出力先もだけど、差し替え易さとか、処理対象の単位を行き来し易いとか。。。かな？ ループだとファイル単位、行単位、文字単位って決まっちゃうと、中々そこから抜け出せないけど、例えば複数ファイルの行で一番長い行を調べたいとする。 (実はCで上の逆順コード書く際のバッファの大きさを決めるために書いた) 最初、トーナメント形式に各ファイルで一番長い行出させて、そこからさらに一番を決めて出力してた。 んで、途中で全ファイルの行の長さ出た時点で一位決められるじゃん。と、数値のリストのリストを平坦化して一気に一位決めた。 そう言うループじゃ無くて、悪魔でリストのリストを受け取って〜。。。って考えると簡単に行単位とかそう言う枠を超えられる。 LLでも出来るだろうけど、思いつき易い。 116 名前：デフォルトの名無しさん [2017/06/25(日) 23:12:43.68 ID:pYBZiqDJ.net] >>110 いあ、書けるでしょうよ。 ただ柔軟性？こう、スタイルが決まっててあんま動かせない感じを受ける。 117 名前：デフォルトの名無しさん mailto:sage [2017/06/25(日) 23:15:11.08 ID:8QFIS7Xe.net] >>109 言いたい事はわからんでもないけど、そんなにhaskell使いやすい？ 自分もHaskellは複雑な構造の解析とか、何か本質的な部分の問題解くときにghci使う事あるけどさ、 実装はやっぱりpythonとかのが楽ってなったよ Stackやcabalの設定編集も面倒だしコンパイル遅いし mapM_あたり使うような物で純粋を目標にしてると、本末転倒になる事が多いし 118 名前：デフォルトの名無しさん mailto:sage [2017/06/25(日) 23:17:22.59 ID:8QFIS7Xe.net] >>112 ああなるほどね 難癖つけてる奴の同類か 119 名前：デフォルトの名無しさん mailto:sage [2017/06/25(日) 23:27:50.72 ID:8QFIS7Xe.net] >>114 ポイントフリースタイルとの組み合わせは確かにHaskell特有だけど、 個人的には実装はIOの文脈で、パイプ演算子とパターンマッチを使える F#やLiveScript(altJS)のような言語方が楽だと思うぞ 120 名前：デフォルトの名無しさん [2017/06/25(日) 23:45:27.87 ID:pYBZiqDJ.net] >>115 なんつーか、さすがにGUIとかはC#使うわってなるけど、確かにコンパイル遅くて微妙に感じもしたけど、上のライブラリみたくガンガン関数化すればPythonでループのシーケンスにargv[1:]ってしてー。。。 逆順だとReversed(list(sys.argv[1:]))でー。。。とか調べないとな場面が度々ね。 んで、毎回複数ファイルから読み込まるのにforって書いて、行毎だとまたfor。。。 Haskellもライブラリ作る前は似たり寄ったりだったけど、ライブラリ書いてからはmfputにファイル名のリストと、各ファイル向け(1ファイル向け)に処理させたい関数渡すだけで大体のツール作れる。 多少パターンが特殊でもmfptnで対応出来る。 ループ的なのを関数に押し込んで、開きたいファイルと処理させたい関数だけ気にしてれば良くなった。 (逆にサポート外のパターンには無力だが。関数化は使い方も規定しちゃうから仕方ない) Pythonだとあんまここまでライブラリ化出来る気がしない。。。 PythonやRubyの書き捨てでも楽だって思ってたけど、多分もう戻れない。 121 名前：デフォルトの名無しさん [2017/06/25(日) 23:47:28.90 ID:GaCuKOAB.net] まずなー>>98に>>100をいっちゃう時点でなー >>96で「空間計算効率が良いなんて一言も言ってない」って明言されてるにも関わらずこんなこと言ってる時点で読解力お察しだからなー 122 名前：デフォルトの名無しさん [2017/06/25(日) 23:54:14.28 ID:GaCuKOAB.net] 相手の意図を組めないという点ではエンジニアガイジと同類っぽいなー 123 名前：デフォルトの名無しさん [2017/06/26(月) 00:09:44.62 ID:jZyN4LOL.net] そう。 空間計算効率の話自体はしてても、Haskellと同程度にライブラリ化したらLLが今までより空間計算効率が落ちる(もしくはイテレータ地獄になる)って言ってるだけで、Haskellの空間計算効率が良いなんて言ってない。 124 名前：デフォルトの名無しさん mailto:sage [2017/06/26(月) 00:15:26.29 ID:f2qWRibY.net] 初めて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) }) }

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef