次世代言語議論スレ[Rust Kotlin Haskell]第6世代 [無断転載禁止]©2ch.net

**デフォルトの名無しさん** · 2017/08/28(月) 21:53:37.12

※前スレ
次世代言語議論スレ[Go Rust Scala Haskell]第5世代
http://mevius.2ch.net/test/read.cgi/tech/1497311647/

**デフォルトの名無しさん** · 2017/09/19(火) 20:25:33.85

コードで言われているのに自然言語で返すガイジ
Haskellの時に具体的に書いた結果無知を晒して大恥をかいたことがよほどトラウマになっているものと見える

**デフォルトの名無しさん** · 2017/09/19(火) 21:17:03.18

前原も就任した後のTV出演で
モリカケ問題ばかりをやるきはないっていったそばから
モリカケ問題トーク始まったからなｗ

**デフォルトの名無しさん** · 2017/09/19(火) 21:20:11.16

>>531
誤爆シマスタｗ

あ · 2017/09/19(火) 22:09:51.81

>>529
それは独立した関数が最適ではない、と言う話ではないか。
何が最適化なんだよ。

>>530
別に恥とは思っとらんよ。勉強にはなった。
しかし余程、自分は恥だと思うんだろうなぁ、他人に対してそういう風に「恥ずかしいに違いない」と断定的に言うところ見ると。
余程恥ずかしいな、その思考回路が。

**デフォルトの名無しさん** · 2017/09/19(火) 22:37:12.49

>>533
ウダウダ言い訳してないで言われた通りコードで書けよ

**デフォルトの名無しさん** · 2017/09/19(火) 22:39:47.10

>>533
いやあれは流石に恥ずかしすぎ。あれを恥ずかしいと思わない思考回路がまず恥ずかしい。

勉強になったとかじゃなくて、最低限の勉強すらせずしったかしてたのがバレただけだろ美化すんな

**デフォルトの名無しさん** · 2017/09/19(火) 22:40:22.21

なんで最適化の話になってんだか。
javaのGraal使って人間がハンドアセンブルしたマシン語をJITに使える新時代くるで。
いちいちjava bytecode生成しなくて済むよ。TruffleRubyが速い。

**デフォルトの名無しさん** · 2017/09/19(火) 23:17:20.17

あの人にボロクソに論破されて発狂して何とか揚げ足取りたいガイジがおるようやね

**デフォルトの名無しさん** · 2017/09/19(火) 23:20:27.89

具体的にコード書くとやっぱりいろいろ明確になる。

**デフォルトの名無しさん** · 2017/09/19(火) 23:27:50.73

>>533
直行する問題だと言ってるんだよ
等価なものは同じものとして扱ったほうが最適化の実装は容易になるだろ

あ · 2017/09/20(水) 07:03:02.13

>>535
そーかー。
そら楽しかっただろうな、嗤うだけのお前はw

最適化の話は、話の発端>>502で、最初から言うとるぞ。

**デフォルトの名無しさん** · 2017/09/20(水) 08:20:53.05

>>537
Haskellの件は擁護不可能だろ
こいつScalaとかOCamlとか関数型全般で知ったかしてたわけだし

**デフォルトの名無しさん** · 2017/09/20(水) 08:21:44.46

ちな上で叩いてるやつとは別人だぞ

あ · 2017/09/20(水) 08:32:31.84

最適化を知ったかしてる人にヤイヤイ言われる程度の事っしょ。
間違ってたら正せば良いし、積極的に正されてるつもりだぞ。
「間違ってるウゥ！」って指差して笑い転げるのは中学生くらいで終わらせとけよ。。

あ · 2017/09/20(水) 08:33:34.51

>>530
ADDEQがどんな命令か知ってれば必要最低限のコードでは？

**デフォルトの名無しさん** · 2017/09/20(水) 08:42:59.18

その文章のどこがコードなのか
自分が何言ってるか考えてからレスしろ

**デフォルトの名無しさん** · 2017/09/20(水) 08:44:43.32

そして抽象度の異なる最適化という事さえ理解してない

あ · 2017/09/20(水) 08:54:13.08

>>545
オペコードはコードでない、と。
面白いな。

>>546
理解してないんじゃない。
着地点が定義されてない最適化なんぞ、どのレイヤであっても無意味。
末尾再帰を解釈できるコンパイラと関数呼び出しとしてしか解釈できないコンパイラの話をしないうちに、
ループの最適化の話しても無駄でしょ。

**デフォルトの名無しさん** · 2017/09/20(水) 09:02:56.02

誰もループの最適化の話なんかしてないでしょ
今の論点は、
・クロージャ変換によりガベージの増加を低減できる
・インライン展開により関数呼び出しのコスト低減を図ることも実行速度の向上には効果的である
・クロージャ変換を行うことによりインライン展開などのより低レベルな最適化が行えなくなることはない
・したがって、両者は直行する問題であり、それらを相反するものとするあDHDの懸念は誤りである
これでいいだろ？

**デフォルトの名無しさん** · 2017/09/20(水) 09:12:41.36

>>540
嗤うだけっていうのはただのディスやね。決めつけはニート認定みたいで、頭悪そうなのでやめといたほうがいいと思うよ

少なくとも、めっちゃ読みづらい知ったかぶり長々書かれて全然楽しくなかったぞ
あの時からずっとおまえのレスは普通に邪魔

**548** · 2017/09/20(水) 09:14:30.17

いやインライン展開を先にやっちゃったらクロージャ変換はできなくなるから正確には直行する問題ではないか
何事も負荷逆な操作をできるだけ後回しにするのは基本だよね

**デフォルトの名無しさん** · 2017/09/20(水) 09:24:37.99

>>543
最適化知ったかぶりしてる奴って誰だよ

間違い自体は全然問題にされてなくて、Haskellの実装を知ってるとまで言っておきながら、その基本文法すらわかってなかった酷い知ったかぶりを責められてるのわかってる？

**デフォルトの名無しさん** · 2017/09/20(水) 09:40:23.50

あと全く知らないものを、まるで知ってるかのように振舞ってディスってたっていうのも問題だな
あんだけ散々ディスってたくせに知らんのんか～いって思った

あれ以来、こいつは知ったかぶりする傾向があるから動くコード書くまで信頼出来んと思ってる

**デフォルトの名無しさん** · 2017/09/20(水) 09:43:04.73

そいつは極度の知ったか自己弁護野郎だから、みんなよく観察するように。

**デフォルトの名無しさん** · 2017/09/20(水) 09:53:58.35

どっちもどっちだな

**デフォルトの名無しさん** · 2017/09/20(水) 10:04:00.22

Cのマクロは人でも読めるコードを生成してくれるから良かった
だがマクロよりインライン関数の方がすごいんだという謎のマウンティングが始まった
人にコードを見せる習慣がなくなったのはそういう歴史の影響があるんだろう

**デフォルトの名無しさん** · 2017/09/20(水) 11:12:40.40

インライン関数は展開されないときもあるからマクロの方つかっちゃうな

**デフォルトの名無しさん** · 2017/09/20(水) 11:30:55.10

展開されない時って、コンパイラ判断として展開しないほうが良い時なのでは……？
いやコンパイラに任せるより手動で最適化したほうが良いような実力者なら知らんけど

**デフォルトの名無しさん** · 2017/09/20(水) 11:36:58.65

コンパイラーの判断は機械的に判断するから間違ってることも多いからな。

**デフォルトの名無しさん** · 2017/09/20(水) 11:47:06.69

実力者になった後で手動にするか、手動にした後で実力者になるか
現金で買うのとカードで買うのはどちらが賢いかというのに似ている

**デフォルトの名無しさん** · 2017/09/20(水) 11:49:12.59

はえー。俺はコンパイラより正しい判断が出来る自信はないから全部コンパイラに任せてるわ
いやすごいな。-O0でコンパイルして-O3並みの速度出せたりすんの？

**デフォルトの名無しさん** · 2017/09/20(水) 12:03:51.93

コンパイラの最適化は速度を優先するかメモリを優先するかバランスとってるからね。
俺みたいな速度最優先の少数派のことなんか考えてくれてないから自分でやるだけ。

**デフォルトの名無しさん** · 2017/09/20(水) 13:32:21.76

-Ofast は速度最優先だと思ってたけどそうでもないのか

**デフォルトの名無しさん** · 2017/09/20(水) 14:02:50.79

>>547
詭弁もいいとこだな
どこがコードなんだよ

オペランドすら記述していない上に、
結局大部分を文章で説明している
それでも、すべて支離滅裂な文よりはいくらかマシだが

**デフォルトの名無しさん** · 2017/09/20(水) 14:07:16.46

そしてオペコードをコードと言いながら>>528で、最適化でコードが変わる事ではないという言い草
恣意的にレスしてるのがまるわかり

**デフォルトの名無しさん** · 2017/09/20(水) 14:50:54.31

あのー結局のところHaskellが良さそうだけどモナドっていうのが分からないとつかえないの？
それともモナドとか分からなくてもそこそこ普通に使えて、しばらく使ってたらモナドとかも雰囲気でなんとなく分かってくるものなの？

YouTuberで圏論の勉強会ビデオ四回目まで見たけどなんとなく理解はできたの
結局のところ集合と関数をより抽象化して記号化していろいろやってるんだよね？

**デフォルトの名無しさん** · 2017/09/20(水) 15:00:39.54

モナドはまあ満たすべき性質ではあるけれど、別に理解してなくても問題ない。
コンパイラもモナド則をチェックするわけでもないし。

**デフォルトの名無しさん** · 2017/09/20(水) 15:30:18.35

俺はネットに無料で上がってる凄いH本よんだけど圏論何て一つもでてこなかったけど
モナドはわかったぞ。

あ · 2017/09/20(水) 15:44:48.04

テンションすげえな。水曜なのに。

**デフォルトの名無しさん** · 2017/09/20(水) 17:03:51.19

モナドとか分からなくてもなんとかいけるんやー
ちょっとがんばっておぼえてみよーっと
ありがとー

**デフォルトの名無しさん** · 2017/09/20(水) 18:09:54.14

Ryzenとか出てきてこれからは6コア、8コアあたりまえになったらマルチスレッドとか大切になるんだとおもうの
それでちょびっとぐぐったらどうも関数型プログラミング言語はどれもマルチスレッドが得意らしいの
だからやっぱり関数型プログラミング言語が流行よね
そんな気がするの

**デフォルトの名無しさん** · 2017/09/20(水) 18:21:45.19

もうみんなコテハンつけたら？
ここにいるのって、どうせいつも同じ人間じゃね？

**デフォルトの名無しさん** · 2017/09/20(水) 18:29:38.52

Haskellの並列ってあんまりマルチスレッドって認識してなかったけど、たしかにマルチスレッドあるな

**デフォルトの名無しさん** · 2017/09/20(水) 18:35:57.38

関数型の入門書はパターンマッチができるデータ構造ばっかり教える
クロージャやモナドはパターンマッチができない構造なのに

**デフォルトの名無しさん** · 2017/09/20(水) 19:12:54.78

そういや、なんでこのスレOCamlいないんだっけ？

**デフォルトの名無しさん** · 2017/09/20(水) 21:15:05.03

関数型全般はさておきHaskell自体は並列処理書きづらいイメージがあるんだけど気のせいか

**デフォルトの名無しさん** · 2017/09/20(水) 21:36:57.21

あんまり詳しくないんだけど、Haskellの並列だと、いくつかの関数をそれぞれ1スレッド（プロセスだったかも？）に割り当てて並列で計算するのが印象に残ってる。
えらい簡単に並列化出来るんだなって思った記憶ある
なんだっけなあのライブラリ

**デフォルトの名無しさん** · 2017/09/20(水) 21:42:45.54

純粋な関数は並列化簡単だからね

**デフォルトの名無しさん** · 2017/09/20(水) 21:59:48.39

インターネットとマルチスレッドを区別しないと
マルチスレッド派はガベコレ廃止してborrowチェックしないと

**デフォルトの名無しさん** · 2017/09/20(水) 23:27:02.45

Kotlinの気に入らないところ
http://anopara.net/2017/09/16/kotlin%E3%81%AE%E6%B0%97%E3%81%AB%E5%85%A5%E3%82%89%E3%81%AA%E3%81%84%E3%81%A8%E3%81%93%E3%82%8D/

**デフォルトの名無しさん** · 2017/09/20(水) 23:43:37.21

>>576
HaskellだとControl.Parallel.Strategiesを使うと
map関数が容易に並列化できてお手軽だった
ちゃんと使おうとするとWHNF(Week Head Normal Form)だとかの理解を要求されるので
そういう敷居の高さはあるけど

**デフォルトの名無しさん** · 2017/09/21(木) 01:50:38.06

>>579
この人はScala大好きのようだが
同様に誰かにのScalaここが嫌だと言われそうなレベルの話で
ふーんでおしまいだなあ。

**デフォルトの名無しさん** · 2017/09/21(木) 05:23:51.87

{ "aaa" }
このラムダ式の凄さが分かって無いな。
ルビーでいうとブロックが何個でも持てるるのと同じことなのにな

**デフォルトの名無しさん** · 2017/09/21(木) 06:47:08.30

>>582
どういうことだってばよ？

**デフォルトの名無しさん** · 2017/09/21(木) 07:06:13.16

>>579
に言っている

**デフォルトの名無しさん** · 2017/09/21(木) 07:08:49.84

わかりやすくいうと
javascriptのcallbackのfunction()という邪魔な奴が消えて見やすくなるということ

**デフォルトの名無しさん** · 2017/09/21(木) 08:36:52.83

Kotlinのパターンマッチは確かにC#の最新版にすら抜かれたダメな子だが、
nullのくだりは全く同意できないな
そもそもScalaにnull safetyなんか無くね

**デフォルトの名無しさん** · 2017/09/21(木) 09:32:12.51

>>586
c#のパターンマッチはまだ中途半端なのに、それに抜かれたとはヤバイな

**デフォルトの名無しさん** · 2017/09/21(木) 12:19:06.27

>>555
inlineの方がいいのは型チェックあるからだろ

**デフォルトの名無しさん** · 2017/09/21(木) 12:30:12.98

俺の場合引数が殆どdoubleかintだから型チェックは意味ないんだよな。

**デフォルトの名無しさん** · 2017/09/21(木) 14:07:02.73

doubleかintしか使わないなら意味あるが、2つ使うなら意味あるだろ。
しかも、完全にじゃなくて殆どならなおさら。
型の意味わかってないだろ。

**デフォルトの名無しさん** · 2017/09/21(木) 14:11:01.15

JavaScript「型なんて飾りです」

**デフォルトの名無しさん** · 2017/09/21(木) 15:01:32.35

>>590
間違いやすくてかつ間違うと致命的なバグを生むからな

**デフォルトの名無しさん** · 2017/09/21(木) 15:22:16.77

一番間違えるのは引数の順番と数

**デフォルトの名無しさん** · 2017/09/21(木) 15:43:39.40

>>593
doubleとintの順番ミスったら大変だもんな

**デフォルトの名無しさん** · 2017/09/21(木) 16:29:56.24

C のデバッグしてると int -> double も明示的に変換するように設計されてりゃよかったのにと思うことが多い。
python3 の int と float をごっちゃにあえてしたのなんてありゃ失敗だろ。型を弱くしてどうすんだっていう。

**デフォルトの名無しさん** · 2017/09/21(木) 18:44:57.78

次世代言語では、データとかを引数で渡すって方法に新たな工夫が欲しいね

**デフォルトの名無しさん** · 2017/09/21(木) 20:03:14.13

>>596
たとえば？

**デフォルトの名無しさん** · 2017/09/21(木) 22:58:59.34

doubleとintを間違える可能性は確かにあるけど
座標とかはdoubleとdoubleだったりintとintだったりするだろ
それを間違える可能性まで網羅しないと致命的じゃないか

型システムに都合の良い範囲を想定してしまったらかえって想定外の盲点が増えてしまう

**デフォルトの名無しさん** · 2017/09/22(金) 01:01:11.41

>>598
型システムがきちんとしてる言語であなたが考えてるような設計はしない

**デフォルトの名無しさん** · 2017/09/22(金) 01:09:22.44

intとdoubleを明確に区別するといえばOCamlだが、あれは流石にやりすぎと感じる。にわか感想だけど

**デフォルトの名無しさん** · 2017/09/22(金) 03:19:07.10

暗黙の型変換の邪悪さは経験積めばわかる
あとIntへの型変換はHaskellが一番ドイヒー

**デフォルトの名無しさん** · 2017/09/22(金) 05:18:45.27

経験積めばわかる、ですむなら静的型いらねぇよ

**デフォルトの名無しさん** · 2017/09/22(金) 05:39:47.03

>>602
ソースの見通しが悪くなってバグの検出が難しくなる

**デフォルトの名無しさん** · 2017/09/22(金) 07:53:43.74

IDE補完が効きまくるという点で静的型が好き。
phpStormとか使うとphpでも補完効きまくるようになるん？

**デフォルトの名無しさん** · 2017/09/22(金) 08:34:49.37

>>601
10年以上Haskellメインで使ってますが、
あなたの言うIntへの型変換の「酷さ」が分かりません。

他言語と比べて何か問題あるのでしょうか。

**デフォルトの名無しさん** · 2017/09/22(金) 09:10:52.08

>>605
Haskellメインの現場ってどういう環境です？研究職？

**デフォルトの名無しさん** · 2017/09/22(金) 09:45:24.85

Haskellみたいなのを研究に使っていたら逆にやう゛ぁいわ
メインはホビーだろ

**デフォルトの名無しさん** · 2017/09/22(金) 09:49:39.95

まず初めに現場かホビーかの分岐があるのになぜ現場に限定するのか

**デフォルトの名無しさん** · 2017/09/22(金) 11:00:09.62

>>605
え？計算毎にいちいちNum経由にするのが酷くないって？
お前もしかしてHaskell使ったこと無いんじゃないの？

**デフォルトの名無しさん** · 2017/09/22(金) 11:06:23.68

Haskellメイン(仕事とは言ってない)

コンパイラとかの文字列処理や、モデルの妥当性検証とかに使うならまだしも、
数値計算でHaskellw
Repa位しか優位性ないだろ

**デフォルトの名無しさん** · 2017/09/22(金) 11:40:01.90

>>609
Numは型ではなく型クラスです。

具体的には、どの型からInt型への変換が酷いのでしょうか。
Stream Fusion は働かないのでしょうか。

**デフォルトの名無しさん** · 2017/09/22(金) 11:45:22.74

>>609
失礼、Stream Fusion と言うより、書き換え規則ですね。

書き換え規則が働けば、大抵の型変換は必要最小限のオーバーヘッドで行われる筈です。

**デフォルトの名無しさん** · 2017/09/22(金) 11:47:26.66

>>611
Numが型だとも型クラスでないとも言ってないし、
Stream Fusionだろうと変換はいるけど？
お前さっきから何知ったかぶってるの？

**デフォルトの名無しさん** · 2017/09/22(金) 11:48:26.85

>>612
「はずです」って、それ結局自分で書くだけだろ？

**デフォルトの名無しさん** · 2017/09/22(金) 11:49:20.78

こういう机上だけで語るクソ野郎がいるからHaskellは嫌い

**デフォルトの名無しさん** · 2017/09/22(金) 12:01:58.15

例えばInt型の３って名前の関数をNumタイプクラスの３って名前の仮想関数に変換する関数で
変換してそれをDoubleを使う関数にいれるパターンだよな。

**デフォルトの名無しさん** · 2017/09/22(金) 12:09:13.20

だから具体的なコード書けって。変な勘違いしてるかもしれないんだから

**デフォルトの名無しさん** · 2017/09/22(金) 12:33:30.94

仮想関数は酷いってのは常識になりつつある
オーバーロードはいいがオーバーライドは酷い
だがオーバーロードとオーバーライドを勘違いする非常識なやつもまだいっぱいいる

**デフォルトの名無しさん** · 2017/09/22(金) 12:52:13.95

オーバーロードこそゴミだろ
型が柔軟になればなるほど邪魔になる

**デフォルトの名無しさん** · 2017/09/22(金) 13:14:10.74

>>601
ある型の値をInt型の値へ変換する際にあなたにとって酷いことが起きる、
あるいはあなたにとって酷いプログラムコードになる、という話ですよね。

>>609
Int型への変換の話の中で「Numを経由する」という言い方を聞いて、
あなたが Num を型だと勘違いしていると思いました。
大変失礼しました。

ある型の値をInt型の値へ変換する際は一度Num型クラスのインスタンス型の値へ変換し、
それを改めてInt型の値へ変換しないといけない、
あるいはそういう型が多い。
あなたはそう思っているのでしょうか。

もしそのような場合でも、私書き換え規則があれば経由しないようにできると私は言いました。
標準ライブラリの中で定義されている型で、
頻繁にInt型への変換が必要と思われる型に対しては、
書き換え規則がライブラリ内に書かれています。
自分で書く場合も一度書けば済むだけみます。
これが酷いのでしょうか。

改めて聞きますが、具体的にはどの型の値をInt型の値へ変換する際に、
Num型クラスのどの型の値を経由しなければならないのでしょうか。

**デフォルトの名無しさん** · 2017/09/22(金) 13:37:46.62

>>620
>改めて聞きますが、具体的にはどの型の値をInt型の値へ変換する際に、
>Num型クラスのどの型の値を経由しなければならないのでしょうか。
だから全部自分で書いた話だろそれ
VanillaじゃIntとIntegerすら必要だろ

そんな事言ったら何らかの形で暗黙の型変換許してる言語全部そうだわ
お前マジで頭の病院行ったほうがいいんじゃねえの？

**デフォルトの名無しさん** · 2017/09/22(金) 13:55:56.62

どっちもどっちだな。
両方病院言ったほうがいいかも。

**デフォルトの名無しさん** · 2017/09/22(金) 14:14:32.59

言語の問題を医学部に丸投げするなよ
今ここで必要なのは法学部か文学部のような能力だという現実を受け入れろよ

**デフォルトの名無しさん** · 2017/09/22(金) 14:19:32.05

>>621
Integer型の値をInt型へ変換する際に、
Num型クラスのどのインスタンス型にまず変換する必要があるのか、
その型を教えて頂けないでしょうか。

**デフォルトの名無しさん** · 2017/09/22(金) 14:52:17.51

具体的なコードを示せないのは、具体的なコードを示すとボロが出るからｗ

**デフォルトの名無しさん** · 2017/09/22(金) 14:56:44.72

>>624
はあ？Int側にするならNum Integer経由だろ？
お前さっきから関係ない話ばっかりじゃねーか

**デフォルトの名無しさん** · 2017/09/22(金) 15:01:10.70

>>625
書くまでもない気がするが一応な
https://ideone.com/MjF75Z
https://ideone.com/es7fao

**デフォルトの名無しさん** · 2017/09/22(金) 15:10:56.24

ほわ？そのコードの何が問題なんだ？
上も下も非常に妥当な挙動に見えるんだけど、いったいどうなって欲しいんだ？

**デフォルトの名無しさん** · 2017/09/22(金) 15:11:44.73

ああ、意図がわかった
こいつIntegralをNumって言った事とっかかりに揚げ足取りしたいんだな
IntegralはReal通してNumのサブクラスですよクソ野郎