X
次世代言語議論スレ[Go Rust Scala Haskell]第5世代 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
0002デフォルトの名無しさん
垢版 |
2017/06/13(火) 09:00:09.39ID:O1HnBMDk
よく話題にあがる言語
Go, Rust, Scala, Haskell, kotlin, Erlang

対象言語のどこがクソかでなく、どこが次世代かで語りましょう

🙅 Rustはコンパイルが通らないからクソ！
🙆 Goは学習コストが低い！
0003デフォルトの名無しさん
垢版 |
2017/06/13(火) 09:31:03.24ID:WHieLZYY
標準的なライブラリは言語の持つ重要な文化の一つだ
Pythonが機械学習で天下を取った理由にはNumpyが大きく寄与している
データ構造としてNumpyを使えば他の大抵のライブラリと連携を取れる。例えば、TheanoやChainerで機械学習して、結果をそのままNumpyで加工してmatplotlibで出力できる。
だからPythonは機械学習分野で流行した。この裏にはNumpyのもつ大きな文化が存在する
言語の持つ文化と流行には密接な関係があるだろう
0005デフォルトの名無しさん
垢版 |
2017/06/13(火) 09:45:32.13ID:kbGi5rrA
F#くん言語仕様は悪くないけど使い所がわからん
0007あ
垢版 |
2017/06/13(火) 10:29:07.84ID:MZxut8VL
おお、お疲れ様。
そこまでアンチってわけでも無いがな。
手当り次第中途半端に取り込んだc#がそこそこ実用言語になってんのに、何やってんのあいつらって感じだけど。
どーせ入ったし、逆に最近のHaskellの良さをもっと教えて欲しい。
0008デフォルトの名無しさん
垢版 |
2017/06/13(火) 10:36:45.13ID:o0nyK+Xq
Pythonの標準的文化って
JavaとC#とaltjsとスマホを完璧に無視したからできたんだよな
0009デフォルトの名無しさん
垢版 |
2017/06/13(火) 10:49:04.84ID:WpoKav5t
>>7
型の強力さと遅延評価のクソさを身をもって示したリファレンスって点は評価ポイントだと思う
あとは実用にはならんかったがdarcsというVCSを世に放ったこと
0012デフォルトの名無しさん
垢版 |
2017/06/13(火) 11:34:29.62ID:KA4hHDRK
>>10
OS標準の開発言語はOSと文化を共有しているからな
マルチプラットフォームを視野に入れないなら最良の言語だと思うわ
0013デフォルトの名無しさん
垢版 |
2017/06/13(火) 11:41:51.61ID:r6njVaEB
OS標準てLinux=C, Windows=C++/C#, Mac/iOS=ObjC/Swift, Android=Java/Kotlin・・・こんな感じ？
0014デフォルトの名無しさん
垢版 |
2017/06/13(火) 11:49:00.99ID:+kV5cJp9
Cは基本的にいい言語だけどラムダとクロージャがない所だけはどうにもならん。でもそれ以外は本当にいい言語だと思う
0015デフォルトの名無しさん
垢版 |
2017/06/13(火) 12:13:37.35ID:WpoKav5t
サードライブラリ管理が野良orOSのパッケージ管理依存の二択なとこも駄目というかここが致命的では
0017デフォルトの名無しさん
垢版 |
2017/06/13(火) 13:00:17.07ID:WpoKav5t
Rustはトレイト境界の特殊化に束理論適用できるようになったら次世代っぽくなるか？
今はただの気難しい言語って感じで次世代感が薄い
0019デフォルトの名無しさん
垢版 |
2017/06/13(火) 17:58:36.02ID:/dWEWAyw
Goはいらん
ScalaとKotlinはどっちかだけでいいけどKotlinが後発だからKotlinでいい希ガス
TypeScriptは実用的だけど次世代化と言われると微妙
Rustは他の言語にない機能多いから次世代
0020デフォルトの名無しさん
垢版 |
2017/06/13(火) 18:04:11.72ID:+kV5cJp9
>>15
それってCのこと？ Cは一切隠蔽しない文化だから、パッケージ管理ソフトとかの隠蔽してしまうものは基本的に相性悪いと思う。Cを書く者はライブラリも自分でMake installするし、インストール場所も自分で指定するから全貌の把握を邪魔するものはないって感じ。
裏を返せば全貌を把握できないと何も出来ないという事も言えるけど。
そういう文化の言語としてはCって完成度高いと思うし、現状超えるものはないと思う。まあ、Cで応用寄りのプログラム書くのは嫌なんだけどさ
0021デフォルトの名無しさん
垢版 |
2017/06/13(火) 18:22:10.72ID:1lda3qQJ
>>19
KotlinとTypeScriptにはほとんど差はないだろ
どっちもC#フォロワーだから、機能的には既に十分メジャーであるという意味ではどちらも次世代とは言えない
0022デフォルトの名無しさん
垢版 |
2017/06/13(火) 18:52:45.36ID:qZ9zsjQ6
Kotlinはあまり興味がなかった他の言語と違う何かがあるなあ、自分にとっては
0023デフォルトの名無しさん
垢版 |
2017/06/13(火) 19:06:12.09ID:huEjF5Un
俺の母ちゃんのあだ名コトリンなんだが
0024デフォルトの名無しさん
垢版 |
2017/06/13(火) 19:35:55.51ID:lP4lhg4O
>>20
何のためにdebやrpmに「foobar-dev(el)」ってパッケージがあると思ってる
言語自前のライブラリ管理システムがないからディストリビューションのパッケージ管理に乗っからないとやってけないからだろ

そういうものをCプログラミングと認めないなら好きにしろ
0025デフォルトの名無しさん
垢版 |
2017/06/13(火) 19:41:20.40ID:wCVClZJy
そういや、まともな検証プロセスの無いままライブラリが提供される
言語独自のパッケージ管理システムは、OS全体の安全性を脅かしてるってDebianの中の人が嘆いてたな
0026デフォルトの名無しさん
垢版 |
2017/06/13(火) 19:41:27.69ID:lP4lhg4O
別に全手動を否定するつもりはないが、
debやrpmが積み上げてきたものを蹴飛ばして
全手動こそがCって言われると違和感があるって話な
0028デフォルトの名無しさん
垢版 |
2017/06/13(火) 19:53:36.19ID:o0nyK+Xq
ソースコードを読む人は時間の感覚が違うだろ
インストールに1日かかっても1日損したと思ってない
自分で書くより早いから得してるし
読むだけでも1日や2日では終わらない
0029デフォルトの名無しさん
垢版 |
2017/06/13(火) 20:32:10.33ID:+kV5cJp9
>>24
「ライブラリが野良orOS配布だから良くない」という意見に「それは別に良い」って言ってるだけやん。ちょっと言葉は過ぎたかもしらんけどそんな噛み付かんといてよ
0030デフォルトの名無しさん
垢版 |
2017/06/13(火) 22:35:13.45ID:ZpGuJRaH
環境含めて考えれば
簡易な言語 + チェックツール
のが正解な気はする。
rust みたいに言語で縛るってのがそもそも間違いじゃねーの。
0031デフォルトの名無しさん
垢版 |
2017/06/13(火) 22:41:55.07ID:blSfEUfZ
>>30
より安全なC言語（チェッカーだったり、標準ライブラリの置換だったり）って今までたくさんあったけど、どれも普及しなかった
Microsoftも作ってたはず

なので、Rustは今度こそは！感がある
0033あ
垢版 |
2017/06/14(水) 13:01:02.27ID:0gE91xz7
>>24
何のためにって、そりゃ、ソースを検証せず、各配布元見てアーカイブのハッシュも見ず、
正しいとコミュニティが認めたものをコミュニティへの無限の信頼で横着して手に入れるためにじゃん。
現実的だけど。
>>30
チェックツールを実用レベルまで持ってくと、言語への縛りが結局キツくなるよ。
停止性問題みたいな話になってくる。
0034デフォルトの名無しさん
垢版 |
2017/06/14(水) 14:06:06.69ID:4UjMkIWv
Cの文化とPythonの文化は方向性が全然異なる
昨今の統計事情から察するに、応用を考えるにあたってはPythonの文化の方が優れているだろう
つまり、細かいことは言語作者やライブラリ作者に全部任せて、考えたいことに集中できる文化の方が発展が速い
0036デフォルトの名無しさん
垢版 |
2017/06/14(水) 14:35:24.56ID:4UjMkIWv
>>35
二択って何？このスレで二択で調べても「野良orOSのパッケージ管理」しか出ないんだけど
0038デフォルトの名無しさん
垢版 |
2017/06/14(水) 14:47:06.53ID:4UjMkIWv
よくわからんしまあいいや
Pythonの例から考えるに、少なくとも応用分野では次世代に流行る言語は強力なライブラリを簡単に導入でき、すぐに目的コードが書けてしまうと言った特性を有しているでしょう
0039デフォルトの名無しさん
垢版 |
2017/06/14(水) 14:59:43.37ID:W7dgH5v3
FORTRANの駆逐に長い時間が掛かったのはライブラリ遺産のせいだって聞いたことがある。
0040デフォルトの名無しさん
垢版 |
2017/06/14(水) 15:11:13.20ID:4UjMkIWv
その通り。Fortran77はクソだけど、新しい言語を使おうとしても移植作業も新規に書き直す作業も面倒なので、そんならいいやとFortranを使い続けてきた
そこに持ってきてpip install scipyのワンコマンドでblas lapackの多くのサブルーチンの良質なラッパーをインストールし、よくわかってない学生でもfrom scipy.linalg import eig 出来てしまうPythonは本当に偉大であった
0041デフォルトの名無しさん
垢版 |
2017/06/14(水) 20:07:23.71ID:rnctBDZd
まあ今ある blas より速いの作るなんて普通のプログラマには不可能だしな。。
0042デフォルトの名無しさん
垢版 |
2017/06/14(水) 21:17:37.82ID:i/E7QqbY
Haskell復活してるやん
0044デフォルトの名無しさん
垢版 |
2017/06/15(木) 03:30:08.09ID:TdjK6zBT
つまり実用できる状態になるとスレタイから外されるって事だよな
ここに残ってるのはいつまでも「次世代」言語
0047デフォルトの名無しさん
垢版 |
2017/06/16(金) 08:26:01.05ID:VSZ6CfqO
実用できる次世代言語はkotrin typescript だよね
実用できない次世代言語がスレタイ
0049デフォルトの名無しさん
垢版 |
2017/06/16(金) 10:10:44.42ID:sGqUlQsg
>>48
元からあいつらただのヤクザ
大義名分のメッキの裏がGoogleやAppleの経済活動で暴かれただけ
0050デフォルトの名無しさん
垢版 |
2017/06/16(金) 10:22:55.63ID:Elc9SXXc
個別スレある言語の話はそっちでヤレばいいじゃん
ここは個別スレ無いやつ専用にしろよ
0051デフォルトの名無しさん
垢版 |
2017/06/16(金) 10:54:04.49ID:is6DCp5t
パッケージ管理システムとかガベコレの一般論専用かな
一般論の個別スレないよね
0052デフォルトの名無しさん
垢版 |
2017/06/16(金) 11:04:24.01ID:yA2bsaGi
日産自動車栃木工場
塗装課、車軸課の正社員の方々の要求はコピペ継続の保守

２ちゃんねる愛用の方々にお知らせ
栃木県上三川町3-5-2
日産自動車上三川寮
管理人は合鍵を使い従業員の部屋に無断で侵入
。
抜き打ちで従業員の私物を全て調べるブラックの中のブラック企業。
期間工が看護師を殺害する事件もあった危険企業。
離職票を発行するのに一月以上もかかるとの情報もあり期間工の生活事情はお構い無し。

このコピペによる日産の悪事の拡散は日産正社員の断固たる要望である。これには日産と無関係の第三者が便乗している可能性が高く自分は不自然に感じている。



0647 FROM名無しさan 2017/06/01 21:21:43
いいからこんなとこで油売ってないで早く100万コピペ達成してこいよｗｗｗ
ほら早よ行けやホラホラｗｗｗ
返信 ID:bEv8YiM0(7/7)

↑↑このように必死で日産の悪事を拡散しろと煽っている。俺は脳無しで馬鹿なので日産正社員が日産悪事を公表するように煽ってきた理由が分からない。不本意ながらコピペを続けている。
0053デフォルトの名無しさん
垢版 |
2017/06/18(日) 01:50:03.42ID:LYWH9ARf
個別スレない言語オンリーならRacket無双になるがよろしいか
0055こんな？
垢版 |
2017/06/19(月) 16:27:30.01ID:PFGmiz2v
今SunがJavaっての作ってるらしーぜ
どんな言語だろうな？
0056デフォルトの名無しさん
垢版 |
2017/06/24(土) 15:20:30.76ID:+EJLhPmM
Googleがヘルスバーグ（C#）級の人をスカウトしてきて
メインプロジェクトとして本気の新言語作ったとしたらどうなるか見てみたい
GoもDartも最初の言語設計がイマイチ感は否定できないんだよね
0057デフォルトの名無しさん
垢版 |
2017/06/24(土) 16:06:03.03ID:iOfeax4r
静的型と動的型のハイブリッドはTypeScriptで早くも完成させちゃったから、
次にヘルスバーグが手がけるとしたら完全な型推論ベースの静的型言語をやってほしい
0058デフォルトの名無しさん
垢版 |
2017/06/24(土) 16:23:53.98ID:pQNLYnE6
ヘルスバーグすこ
Googleの作る言語はゴミばっかや
0059デフォルトの名無しさん
垢版 |
2017/06/24(土) 16:28:25.84ID:TM1thEne
ヘルスバーグだってMSが敵わなかったからライバルから引っこ抜いたんだろ
0062デフォルトの名無しさん
垢版 |
2017/06/24(土) 23:50:07.30ID:UHmd/ofd
Googleってゴスリンやゲイドも飼ってたことあるよな
一瞬で辞めたけど
会社の体質に問題があるんだろうね
0066デフォルトの名無しさん
垢版 |
2017/06/25(日) 10:07:31.69ID:ZFXP5+sH
Androidのアプリ作りたいのか、iOSのアプリ作りたいか
それだけの話なのに何で自分で決められないんだろ
0068デフォルトの名無しさん
垢版 |
2017/06/25(日) 10:24:20.80ID:by7iMnGq
kotlinは既にJavaをマスターしててサンプルコードの雰囲気を見ただけでなんとなく書き始められるくらいの人が使うもんだぞ
勉強するもんじゃない
0069デフォルトの名無しさん
垢版 |
2017/06/25(日) 12:21:22.67ID:BOhr0vIe
今Haskellでよく使う処理をガンガン関数にしてライブラリ化してるけど、LLでもここまで短く書けないだろと言うか、
ここまでライブラリ化するには遅延評価じゃないとreverse使わないような処理でもメモリに溜め込むか、
遅延評価にする為にイテレータ作りまくりじゃないかと思った。

いあ、最上位の関数とかは短く書けるんだろうけど、ライブラリ内部の似たような処理を
ガンガン関数にして行くのは流石に難しいと思う。
0070デフォルトの名無しさん
垢版 |
2017/06/25(日) 12:39:35.65ID:mZBbGFn8
>>69
つづきはブログでおやり
具にもつかない報告を読まされる身にもなってみろ
お前のレスは今後一切いらんからなこのスレには
0071デフォルトの名無しさん
垢版 |
2017/06/25(日) 12:53:31.73ID:ETAvV0eF
linux のソース見る限りは c にまともなマクロが用意されればそれで十分。
まあまともなマクロを用意するってのは言うほど簡単じゃないだろうけど。
0072デフォルトの名無しさん
垢版 |
2017/06/25(日) 13:33:53.23ID:BOhr0vIe
>>70
じゃあLLでも何でもいいけど、手続き型言語でよく使う処理をガンガンライブラリ化してみてよ。
どっちがより汎用性と簡潔性を両立出来てるか競おうず。
0073デフォルトの名無しさん
垢版 |
2017/06/25(日) 13:58:29.36ID:by7iMnGq
Haskelは実装変更のインパクトがでかくてカプセル化的な考え方で作るには向かないんだよな
実用言語としてガチ関数型を流行らせるには厳密性を維持しつつ現実の大規模開発でのモジュール化も考慮した仕組みを作らないと
0074デフォルトの名無しさん
垢版 |
2017/06/25(日) 14:13:01.18ID:/Sm2Vorl
>>73
Cでcatコマンド自作しようとした時、複数ファイルから一番長い一行あたりのバイト数(文字コードによって違うので文字数ではダメ)調べるコマンド作った時、
lengthはByteStringモジュールを使いたいけど、mapは標準のを使いたい(ByteStringのmapはByteString -> Char特化)って時に細かくどれは読み込んで、どれは読み込まないってしたけど、
それじゃあかんの？

モジュール読み込みの設定だけ変えれば、main以下は全く同じコードがバイト数と文字数切り替えれるけど。
0075デフォルトの名無しさん
垢版 |
2017/06/25(日) 14:24:06.30ID:WUy1L4jW
>>74
すまん全く意味がわからない
73からいきなり抽象度が下がりすぎだろ
ハスケラならもうちょっと抽象的かつ厳密で明示的なレスを頼む
0076デフォルトの名無しさん
垢版 |
2017/06/25(日) 15:21:38.85ID:mZBbGFn8
>>72
なにが「じゃあ」なん？
脳みそ腐ってんの？
しょーもないレスでスレ汚すのやめてくれマジで
0077デフォルトの名無しさん
垢版 |
2017/06/25(日) 16:41:08.55ID:p9Z6xhSy
>>75
抽象度が高い=フワッとして概念的って思ってたんだが違うんか。。。
import書く時、この関数だけ読み込まない。
この関数だけ読み込むって指示できるから、そこだけ弄ればそこ以下のコードは書き換え無しに
文字数数えるかバイト数数えるか動作を切り替えられる。
0078デフォルトの名無しさん
垢版 |
2017/06/25(日) 16:53:53.40ID:p9Z6xhSy
>>76
うんうん。
分かるよ。
式と文が入り混じるから関数化する単位に限界あるもんね。
副作用と純粋部分の区分けが強制されないというか、遅延評価じゃないと強制されたらreverse使ってなくてもメモリに溜め込むコードになっちゃうし。
それを解消する為にイテレータ書きまくるのも面倒だもんね。
Cくらい速かったら、それを飲み込むのも我慢出来るのにね。
0079デフォルトの名無しさん
垢版 |
2017/06/25(日) 17:24:16.31ID:rLWYKb/E
この勘違いしたハスケラを黙らせるには、
ハスケラ自慢のライブラリを見せてもらって、
それより簡潔なコードを書くしかないと思う
0080デフォルトの名無しさん
垢版 |
2017/06/25(日) 17:39:45.42ID:wtr2uEYx
>>77
例えば、引数の値のみにより完全に決定される値を返す関数があったとして
ここに「ただし、前回と値が同じ場合は前回より1だけ大きい値を返す」という要件が増えたらどうする?
0081デフォルトの名無しさん
垢版 |
2017/06/25(日) 17:56:09.21ID:pYBZiqDJ
>>80
Haskellも状態扱えない訳じゃないし、大量に状態保持す代名詞のGUIプログラミングが、HTMLやXAMLで書かれるのに一定の地位を確立した今となっては、そういうDSL、又はDBに状態保持させて、Haskellは同じ値が来たら外部に+1してってお願いすれば良いと思うけどね。
0083デフォルトの名無しさん
垢版 |
2017/06/25(日) 18:12:35.96ID:pYBZiqDJ
何言ってんのか分からんけど、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
0084デフォルトの名無しさん
垢版 |
2017/06/25(日) 18:17:06.53ID:pYBZiqDJ
ライブラリ内部にも似た様なパターンを関数化して無駄に似た様な少し違うコードが少ない様にしてる。

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))
0085デフォルトの名無しさん
垢版 |
2017/06/25(日) 18:17:18.21ID:pYBZiqDJ
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
0086デフォルトの名無しさん
垢版 |
2017/06/25(日) 19:00:45.29ID:rLWYKb/E
それライブラリ化する価値もなさそうな
汎用性の無いコードにしか見えんが、本気か...？
0087デフォルトの名無しさん
垢版 |
2017/06/25(日) 19:04:10.51ID:pYBZiqDJ
>>79
ワザとウザい役したけど、実際問題再利用のし易さと速度はある程度トレードオフな関係だと思う。
それならHaskellとCで良いんじゃないかってなった。
個々人でバランス感覚違うから、他の言語を選択するものアリだけど。
0088デフォルトの名無しさん
垢版 |
2017/06/25(日) 19:11:04.69ID:pYBZiqDJ
>>86
まだ育ててる最中だしね。
複数ファイル読み出し、複数ファイルそれぞれ出力なパターンはこれで行ける。
複数ファイルから一つの結果求めるパターンはこれから作るし、他の関数と共通パターンあったら、関数化して行く。

正気か？って言うけど、forとかメソッドチェーンな中身とか途中のメソッド入れ替えるとか、そう言うことしてる様な感じ。
こんな関数化の方法、オブジェクト指向言語では考えもしなかったぞ。
0089デフォルトの名無しさん
垢版 |
2017/06/25(日) 20:27:51.46ID:k3/0SUsA
Haskell使いのレベルの低さが知れるな
こうゆうのを繰り返すならやっぱり次はまたHaskellはずそう
0090デフォルトの名無しさん
垢版 |
2017/06/25(日) 20:33:29.70ID:h1su++jx
ていうかHaskell自体は全然次世代言語じゃないじゃん
Haskellの一部分を参考にした次世代言語はあるけど
0092デフォルトの名無しさん
垢版 |
2017/06/25(日) 21:00:59.61ID:pYBZiqDJ
ええ。。。
最近こそラムダ式とか入ったけど、オブジェクト指向って相変わらず手続き型言語で、コンストラクタって結局構造化プログラミングで言うinit関数でしょ？みたいな感じで処理の分け方が上中下って感じなんだもん。
おまけに肝心の中身はインターフェースでそれぞれのクラスに別々に書いてねとか。
似た様なコード何度も何度も書いてるなー。。。って感じだった。
LLにしても、書き捨て毎に似た様なコード書いてるなー。。。って。

Haskellだからここまで関数化しても遅延評価でメモリを一定以上消費しないんだと思うし、mfput関数一つ書けば中身の処理を考えるのに集中出来た。
(mygrepnとか見つかった文字列を強調赤字にするオマケ付き。
rpとかコマンド名が競合するから短い名前だけど、地味にコード書き換えに活躍してる)

実際に上のコードと同じライブラリ書いてみてよ。
パターンは共通って分かってても、文が邪魔したり、メモリに溜め込む処理になるから断念する場面が出てくると思う。
0093デフォルトの名無しさん
垢版 |
2017/06/25(日) 21:18:47.33ID:8QFIS7Xe
>>89 >>76 >>70
まともに叩くことも出来ないレベルのクソ野郎は入ってくんなよ…
お前らみたいなのがいるから、変なのが増長するんだろ
0094デフォルトの名無しさん
垢版 |
2017/06/25(日) 21:38:11.91ID:8QFIS7Xe
>>92
結局パイプ的に繋いでく話してるだけだな
はっきり言うが、Haskellでまともなプログラム組んでIO扱う途端にその手の使い方はできなくなるよ
その言ってる方法突き詰めたとして、リアクティブプログラミング的になるが、
遅延評価が仇になってサンク作りまくる場合はあるし、遅延評価だから空間計算効率が良いなんて話にもならない
Haskell自身もメモリの効率がいいわけでもない
女アクのGHCのランタイムがまずクッソでかいし

何よりリアクティブプログラミングじゃ、現代のGUIでまともなプログラム作れない
IOなGUIツールキットをリアクティブに対応させるコード書いてる暇あったらIOで書いた方がマシだ
0095デフォルトの名無しさん
垢版 |
2017/06/25(日) 21:42:36.54ID:8QFIS7Xe
正確にはリアクティブプログラミングじゃなくてFunctional Reactive Programingだな
リアクティブだけなら、一つのシグナルストリームでなく分散メッセージでいいし難しくはない
0096デフォルトの名無しさん
垢版 |
2017/06/25(日) 22:00:46.32ID:pYBZiqDJ
>>94
空間計算効率が良いなんて一言も言ってないが。。。
悪魔で再利用し易さの割にってだけ。
んでもLLと同程度ならほとんどの場合で問題にならないので、このままライブラリ化進めればLLよりチマチマしたの作るのに都合が良い言語になると言うか、既になってる。

半端にLLで空間計算効率考えるよりは、普段はHaskellで富豪的だけどLLより再利用し易いコード書いて、そう言うの重要な場面ではCで書けば良いやってなった。

今時のメモリ搭載量だと小説10冊分が1ファイルに入ってても問題にならんから、実用上ほとんど問題にならん。
それが問題になる時は処理速度的にもLLでも対処出来ない。
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況