次世代言語10[Rust Swift TypeScript Dart]

**デフォルトの名無しさん** · 2018/04/25(水) 07:02:27.60

スレタイ以外の言語もok

前スレ
次世代言語9[Haskell Rust Kotlin TypeScript Dart]
http://mevius.5ch.net/test/read.cgi/tech/1520298555/

**デフォルトの名無しさん** · 2018/05/16(水) 06:47:58.51

LazyかStrictかってな。評価戦略も考えてかなならん。

まあ、Haskellも使いこなすには、それなりの背景知識がないとあかんという事だね。

**デフォルトの名無しさん** · 2018/05/16(水) 07:09:06.16

lazyは無限の計算を打ち切る
遅い計算をちょっと速くするだけの最適化とは次元が違う

**デフォルトの名無しさん** · 2018/05/16(水) 07:20:15.91

>>562
これは同意かな。
結局抽象論でドヤるの好きなだけなやつってのは
実測を嫌う傾向にあるから問題を引き起こす。

**デフォルトの名無しさん** · 2018/05/16(水) 07:35:27.07

>>564
初めから無限の計算をしないように書いた方が多くの場合(ずっと)速いのでないかみたいな話だろ

**デフォルトの名無しさん** · 2018/05/16(水) 07:51:39.34

そんなlazy全否定するような話題だったのか

**デフォルトの名無しさん** · 2018/05/16(水) 07:55:55.64

そういう話題だったら初めからそう言えばいいのに
現実的には後出しが便利だから後出ししてる
現実を実測しよう

**デフォルトの名無しさん** · 2018/05/16(水) 08:00:59.77

いや後出しも何も>>457のブログにlazy遅いよねとか書いてあってそれについて話してるわけだし…

**デフォルトの名無しさん** · 2018/05/16(水) 08:02:16.32

と俺は思ってたんだが違うのか？

**デフォルトの名無しさん** · 2018/05/16(水) 08:23:21.13

あってるよ。

**デフォルトの名無しさん** · 2018/05/16(水) 08:30:32.29

もう少し真剣に考えてもいいんじゃないか？
誰も最適化が完璧に行われてる、の追試しないの？
ghcの最適化結果のバイナリをgdbで眺めるだけでも全然違うと思うが。

俺がやるとおま環でオラつくなとか言われるの目に見えてるから静観してるけどさ。

**デフォルトの名無しさん** · 2018/05/16(水) 09:41:30.81

お前の静観ってうるさいのなｗ

**デフォルトの名無しさん** · 2018/05/16(水) 09:50:51.21

例がクソすぎて正直興味わかない

**デフォルトの名無しさん** · 2018/05/16(水) 09:51:48.57

>>573
やめたれｗ

**デフォルトの名無しさん** · 2018/05/16(水) 10:11:53.73

これ正味のところコンパイラのバックエンドの性能比較にしかなってないし、
その差も最適化オプションの違いと想像できる範囲だもの

**デフォルトの名無しさん** · 2018/05/16(水) 15:45:52.24

うーん、だったら異なる言語の速度比較に説得力を持たせるためには、どんなルールを定めればいいの？

**デフォルトの名無しさん** · 2018/05/16(水) 16:15:52.78

お題を設定して、そのお題を解く実行速度でも競えば

**デフォルトの名無しさん** · 2018/05/16(水) 17:11:19.52

これは反対意見が多いと思うんだけど任意の問題について各々の言語で素直な(読み書きしやすい/一般的な)書き方で解いた際の速度比較が一番だと思ってる
コンパイルオプションレベルでの最適化はアリだと思うけどソースでの最適化なんてほんとにそれするの？っていうのあるし

**デフォルトの名無しさん** · 2018/05/16(水) 17:35:38.66

問題の難度が低すぎるから早押しクイズになってしまう
正解者が1名いるかいないかの難問なら速度はどうでもいいだろ

**デフォルトの名無しさん** · 2018/05/16(水) 17:54:36.37

>>579
いや、そもそもソースを1つに限定しようとするのがダメだと思う
読みやすい(一般的な)コードと最適化を前提としたコードの両方を用意する
そうすれば両方のケースで比較できるようになる
あと、その任意の問題とやらも複数ケース用意する必要があるだろうな…
面倒臭いけどそれがベストだと思う

**デフォルトの名無しさん** · 2018/05/16(水) 18:10:24.62

>バカが書いたCのコードより天才が書いたHaskellのコードのほうが(多分)速い

一方ロシアは天才が書いたCのコードを用意した

**デフォルトの名無しさん** · 2018/05/16(水) 18:51:37.22

>>580
ある種の難問を解きやすいのが関数型言語のウリのはずだし、それはそれで一つの結果じゃない？

**デフォルトの名無しさん** · 2018/05/16(水) 19:03:04.49

それはそれとして
個人的に>>457の確認をしてみたいのだけど、
どんな main 書けばいいのか誰か教えてくれないか？

ghc -O2 で下記のようなコードをコンパイルすると
一切メモリ使わずレジスタだけで0.1ずつ増加させた数を積和していくからテストにならないし、
10M個の積和を100回実行するところも1回に省略される気しかしない…

https://ideone.com/gjFBNp

module Main (main) where
import Prelude hiding (sum, length, zipWith, map)
import System.Environment (getArgs)
import Data.Vector.Unboxed

test :: Data.Vector.Unboxed.Vector Double -> Double
test v = sum $ zipWith (*) v v

main :: IO ()
main = do
(n':_) <- getArgs
let n = read n' :: Int
let v1 = enumFromStepN 0.0 0.1 n
print n
print $ test v1

**デフォルトの名無しさん** · 2018/05/16(水) 19:11:48.70

いやごめん
Haskell スレで聞いてみます

**デフォルトの名無しさん** · 2018/05/16(水) 19:50:33.80

せっかくだから一応貼っておくと ghc -O2 は上記の sum zipWith をここまで最適化した

_c8Gb:
testq %r14,%r14 // 全て終わったら
jle _c8Gh // ループ終了
_c8Gi:
movsd %xmm1,%xmm0 // m0 <= m1
mulsd %xmm1,%xmm0 // m0 <= m1*m0
addsd %xmm0,%xmm2 // m2 <= m2+m0
addsd _n8GK(%rip),%xmm1 // m1 <= m1+0.1
decq %r14 // 回数カウンタ減らす
jmp _c8Gb // ループ

遅延評価と fusion すごいw

**デフォルトの名無しさん** · 2018/05/16(水) 19:58:05.30

ソースコードより短いのは流石に草

**デフォルトの名無しさん** · 2018/05/16(水) 21:37:36.10

これO(1)じゃなくてO(n)だけど速いのか？
聞くは一時の恥、聞かぬは一生の恥

**デフォルトの名無しさん** · 2018/05/16(水) 21:40:07.47

O(1)になるまで最適化って、それ1/6公式使わないと無理じゃね？

**デフォルトの名無しさん** · 2018/05/16(水) 21:43:37.16

つまり、鳥人間コンテストのような謎のルールで縛られてまともな飛行機作れない状態か

**デフォルトの名無しさん** · 2018/05/16(水) 21:50:17.17

1/6公式使うまで最適化してくれるようなコンパイラあんの？あったら見て見たいんだけど

**デフォルトの名無しさん** · 2018/05/16(水) 22:22:29.79

visualc の出したコードではループ回数が10の倍数だということを織り込んで
10回分ずつ loop unrolling して端数回を処理するコードは略されてた。

そこまでわかってるならもう全部計算しといて略せよという気がした。

**デフォルトの名無しさん** · 2018/05/16(水) 22:57:07.69

1/6公式使うのは違う計算をして微妙に違う値になるから最適化というより簡略化だな

**デフォルトの名無しさん** · 2018/05/16(水) 23:22:07.02

先に除算を分岐処理しないとオーバーフロー条件変わっちゃうからなぁ

**デフォルトの名無しさん** · 2018/05/16(水) 23:44:41.84

まあ最適化してるってことでコンパイル時に全て計算してしまえば
ランタイム速度はいつだってO(1)だよ。

**デフォルトの名無しさん** · 2018/05/17(木) 00:08:51.80

悪質な反則と正しいハックの違いを
理系の学問では説明できない

**デフォルトの名無しさん** · 2018/05/17(木) 01:23:03.74

コンパイル時に計算可能なのは>>457で
>>584は実行時の引数使ってるから計算しとくのは無理だな
いつだってO(1)に最適化できる、未来を予測する神のコンパイラがあれば別だけど。

積和しないで公式使うのがよろしくないってのは、
数学や算数の計算と違って丸め誤差のあるコンピュータ言語での
浮動小数点数演算は誤差に関する統一的な挙動、
通常 IEEE 754 に準拠した挙動が期待されるわけで、
式を変形したり変えたりすると丸め誤差の出方が違って結果の値が変わっちゃうから。

もちろん規格を守らなくて良いというオプションはあっても良いわけどけど。

…誰か何か他の話題を

**デフォルトの名無しさん** · 2018/05/17(木) 17:09:11.06

自分で考えろカス

**デフォルトの名無しさん** · 2018/05/22(火) 10:01:58.35

お前が考えろゴミ

**デフォルトの名無しさん** · 2018/05/22(火) 17:54:26.91

ほなワイが集めたるで～

**デフォルトの名無しさん** · 2018/05/22(火) 21:27:22.64

つまりRust最強

**デフォルトの名無しさん** · 2018/05/22(火) 21:57:35.93

何がどういう理屈で「つまり」なんだってばよ(；￣Д￣）？

**デフォルトの名無しさん** · 2018/05/22(火) 22:03:03.16

Rustは最近impl traitが実装されて使いやすくなった

**デフォルトの名無しさん** · 2018/05/22(火) 22:41:37.50

impl trait は確かに嬉しかった
これでやっとトレイトオブジェクト使わずにイテレータが返せるようになった

**デフォルトの名無しさん** · 2018/05/22(火) 22:50:22.39

rust わかりやすいくらいダメな方向に行ってるな。。

**デフォルトの名無しさん** · 2018/05/22(火) 23:12:28.14

Juliaは？
けっこう化けそうな希ガス

**デフォルトの名無しさん** · 2018/05/22(火) 23:20:40.27

何が理由で「ダメの方向」って言ってるのか分からない
C++の後継としてはRustは限りなく理想に近い言語だと思うが…

**デフォルトの名無しさん** · 2018/05/22(火) 23:23:35.78

>>606
去年も全く同じこと言ってたよなお前

**デフォルトの名無しさん** · 2018/05/22(火) 23:28:27.19

JuliaはPythonを殺せない気がする。ボトルネック以外速くてもあんまり意味ないし

**デフォルトの名無しさん** · 2018/05/22(火) 23:38:51.33

py 3.6で標準で型付けできるようになったし
av女優の名前借りたゲス言語なんてオワコンでしょ

**デフォルトの名無しさん** · 2018/05/22(火) 23:41:37.77

型システムだけはJuliaの方が好き。っていうかクラス嫌い

**デフォルトの名無しさん** · 2018/05/23(水) 00:06:43.07

結局Dartなんだよなあ

**デフォルトの名無しさん** · 2018/05/23(水) 00:10:03.78

数値計算の話をwebで流すのやめろ！

**デフォルトの名無しさん** · 2018/05/23(水) 00:24:34.00

Juliaいらね
数値計算に使う分には記述性はFortranと大差ない

**デフォルトの名無しさん** · 2018/05/23(水) 00:30:13.83

Julia使ってるとコンパイル不要のスクリプト系の強みをjitのプリコンパイルの時間で失ってる気がするんだけど分かる人いない？

**デフォルトの名無しさん** · 2018/05/23(水) 00:30:32.27

>>614
パ……パイプとより柔軟な内包表記があるから……
グラフも出せるし……

**デフォルトの名無しさん** · 2018/05/23(水) 00:32:43.88

>>614
第一級関数がFortranにはないじゃん？

**デフォルトの名無しさん** · 2018/05/23(水) 01:02:46.26

Rustはクラス嫌いなだけでなく第一級関数も嫌う方向に行った

**デフォルトの名無しさん** · 2018/05/23(水) 01:25:54.25

内包表記とかいうそびえ立つ糞
あのガイジ文法が読みやすいってpython作った低学歴はメクラのガイジなのか？

**デフォルトの名無しさん** · 2018/05/23(水) 01:28:00.60

使わなきゃいい

**デフォルトの名無しさん** · 2018/05/23(水) 01:48:18.92

内包表記読みにくいって方が理解できん

**デフォルトの名無しさん** · 2018/05/23(水) 01:52:39.56

包皮
放屁

やっぱ読みにくいわ

**デフォルトの名無しさん** · 2018/05/23(水) 01:55:25.46

ピリオド.でpropertyをつないでいく何たら記法ってやつ
Rubyのゴルフ好きがよく使うが
あれこそ読みにくい

**デフォルトの名無しさん** · 2018/05/23(水) 01:55:41.96

>>615
Juliaは数時間～数日単位の時間のかかる処理に使うもの
全く問題にならないオーバーヘッド

**デフォルトの名無しさん** · 2018/05/23(水) 02:34:11.07

>>618
なに言ってるんだ？
Rustは普通に第一級関数使えるんだが…
いろんなクレートがクロージャ使いまくってるんだが…
あとクラスを嫌ったのはむしろ正解だろ？
データと操作を一緒にするのは失敗で関連付けるのが正解
つまり、クラスは失敗でRustのimplかGoのレシーバが正解

**デフォルトの名無しさん** · 2018/05/23(水) 04:36:59.97

Haskellの移植だっけか？あっちは分かりやすい。

**デフォルトの名無しさん** · 2018/05/23(水) 04:38:52.45

Pythonic wwなリスト内包表記
もう少しうまくパクればいいのに。

**デフォルトの名無しさん** · 2018/05/23(水) 06:54:23.85

確かに for がネストしてたり if else がネストしてんのに内包表記するのは馬鹿だなと思うわ。
素直に for 文書いて append しろやと。

**デフォルトの名無しさん** · 2018/05/23(水) 07:02:28.47

>>607
後継っつーか、ほぼc++と同じ方向に行ってるだけになってるだろ。
それに意味があるか？

**デフォルトの名無しさん** · 2018/05/23(水) 09:26:47.69

Python の内包表記はややこしいって、Guido 自身が言ってるw

たぶん、a.b.c.d など、Ruby, jQuery みたいに、
Python では、関数型のメソッドチェーンができないからだろ

**デフォルトの名無しさん** · 2018/05/23(水) 09:50:48.87

>>629
GCがないこと以外はほぼ全て真逆の方向に進んでると思うんだが…
Rustほど信頼性に極振りしてる言語なかなかないぞ
アレのどこが同じ方向なんだってばよ？

**デフォルトの名無しさん** · 2018/05/23(水) 09:59:13.80

メソッドチェーン推しのくせにオプショナルチェーンに考えが至らず、多言語の後追いでパクリ導入したが?を識別子にできることとクソ命名習慣が相まり?.が使えず&.となった、もはやまともにパクることすら出来なくなってきた糞ジャップ言語があるらしい。

**デフォルトの名無しさん** · 2018/05/23(水) 14:15:18.86

pythonはもう機械学習の覇権言語として確固たる地位を確立してしまったので、
ITドカタどもが書きやすいと感じるかなんて、最早どうでも良い領域に到達してしまった

**デフォルトの名無しさん** · 2018/05/23(水) 14:49:50.61

機械学習を自分で書ける腕があるなら、既に人が作ってくれたものを捨ててわざわざ一からやるなら別にPython使わなくても良いのよ？

**デフォルトの名無しさん** · 2018/05/23(水) 17:28:38.80

自分のオリジナルのモデルを実装したら、比較検証用に他のモデルも動かす必要あるわけじゃん？
既存のモデルまで全部自前で実装するのはダルいんだわ。
で、既存のモデルはPythonで動かすってなったら、そのまま自分のモデルもPythonで動かせた方がデータの加工やグラフ化なんかを使い回せて便利ってなっちゃう。

**デフォルトの名無しさん** · 2018/05/23(水) 17:34:28.36

わかりみが深い

**デフォルトの名無しさん** · 2018/05/23(水) 19:47:24.32

でも例えばtensorflow.jsはpythonのtensorflowやkerasのモデルインポート出来るぞ。
こんな風に移行手段提供されるんだったら言語は何でもいいんじゃない？

**デフォルトの名無しさん** · 2018/05/23(水) 19:57:50.83

rustに信頼性？
あの言語で信頼できる書き方できるならc++でもできるほどのプログラマだわ。
機能追加しまくって聳え立つクソになりつつあるって意味で全く同一方向だと思うがね。

**デフォルトの名無しさん** · 2018/05/23(水) 20:04:05.38

>>631
お前がそう思うならそうなんだろう
お前ん中ではな

**デフォルトの名無しさん** · 2018/05/23(水) 20:08:16.04

>>637
まあライブラリ提供側の気分次第やね
提供してくれたら喜んで移行できる

**デフォルトの名無しさん** · 2018/05/23(水) 20:08:23.39

Rustでまともなプログラム書けるならC++でまともにプログラミングできるって点が一番のRustの致命的にゴミな部分な
Rustを使う意味はただのひとつもない

**デフォルトの名無しさん** · 2018/05/23(水) 20:42:05.12

Juliaはendがなあ……

**デフォルトの名無しさん** · 2018/05/23(水) 21:14:13.23

>>641
大きな違いがあるぞ。
C++はまともでないプログラムでもエラーや警告を吐かずにコンパイルできてしまうが、Rustは、少なくともメモリ周りがまともでないかどうかはチェックしてくれる。デバッグや保守を考えたらRustの方がありがたい。

**デフォルトの名無しさん** · 2018/05/23(水) 21:30:42.02

>>643
Sync, Sendのマーカートレイトのおかげでマルチスレッド下のデータ競合もチェックしてくれるぞ
もちろんNull安全も保証してくれる
むしろRustを使わずC++を使う理由の方が「既存資産」以外にはひとつもない

**デフォルトの名無しさん** · 2018/05/23(水) 21:53:37.23

前から気になってたんだけどWindowsのDLLみたいな動的リンク方式のライブラリを作ったり使ったりするのに適した言語って最近のである？
言い方を変えるとバイナリ形式のプラグインやアドオンを作ったり使ったりする言語を探してるんだけど
最近のプラグインやアドオンってスクリプトが主流なんだよね

**デフォルトの名無しさん** · 2018/05/23(水) 21:57:13.88

>>637
それ、Pythonで書いておけば何処でも動くから
Pythonで書こうってのが加速するだけじゃん
js では学習済みのモデルが動くだけなんだから

**デフォルトの名無しさん** · 2018/05/23(水) 22:05:53.52

>>646
ちがうよ。学習も出来るフルセットだよtensorflow.jsは。
たしかに学習済みモデルを動かすだけのライブラリもあったけどね。
そうではないから盛り上がってるんじゃん。

**デフォルトの名無しさん** · 2018/05/23(水) 22:10:00.62

あ、ホントだ。教えてくれてありがとう。

**デフォルトの名無しさん** · 2018/05/23(水) 22:14:28.24

数値計算の次世代言語雑魚すぎィ！
Fortress 復活させろよぉ！

**デフォルトの名無しさん** · 2018/05/23(水) 22:32:26.36

>>645
ネイティブならC++
ネイティブでなくてよければC#がベスト

**デフォルトの名無しさん** · 2018/05/23(水) 23:52:54.57

>>650
やっぱそうなるか
次世代言語への移行はまだまだ先になりそうだ
ありがとう

**デフォルトの名無しさん** · 2018/05/24(木) 00:56:23.12

>>643
そもそもRustでコンパイル通せるならC++で十分ってことへの答えになってないな

そもそもチェック自体も胡散臭い。当てにならん
https://github.com/rust-lang/rust/pull/50966

**デフォルトの名無しさん** · 2018/05/24(木) 01:01:49.92

>>644
Rustみたいな鬼のように複雑な言語使ってコンパイル通せるなら、
C++でバグ出さずに書けるっつってんだろ
コンパイル通せる前提で話すんなや

あんな数年の歴史しかないのにC++に匹敵する
サクラダファミリアに成長できた複雑怪奇な言語コンパイル通すのと
C++でバグなくプログラミングする難易度ほぼ同じなんだから
既存資産の分でC++に軍配あがるだろって単純な話よ

**デフォルトの名無しさん** · 2018/05/24(木) 01:06:34.50

>>653
桜田じゃない。サ「グ」ラダだ、タコ助。

**デフォルトの名無しさん** · 2018/05/24(木) 01:48:40.06

>>653
ああもう煩いな
おれの経験にのみ基づく話なので「それはおまえだけだろ？」
と言われた場合はぐうの音も出ないのであまり書きたくなかったが…

俺はRustを趣味で使い始めて１年半くらいで自分でもRust使いだと名乗れる
くらいには詳しくなったが、それでも未だにコンパイラには時々怒られてる
ただし、コンパイラのエラー情報を見れば何がダメなのか
すぐ理解できるようになったので少し考えれば修正できるようにもなったし
未だに怒られること自体はさほど大きな問題にはなっていない
ただ、始めた頃と比べれば、だいぶ怒られる回数は減ったが完全に無くなりはしなかったし、
今後もずっと俺はRustのコンパイラには時々怒られるような状態のままだと思う
そしてその状態の俺がC++で同じようにコードを書いた場合、
Rustだと時々コンパイラが怒ってくれてた部分をC++は全て無視してバグになってしまう
俺にはRustのコンパイルを(時々怒られつつ)通すことは出来るが
C++でバグを出さないことはできない。だから俺はRustを使う

他のRust使いはどうなんなんだろうな？俺と同じヤツはいないのか？

**デフォルトの名無しさん** · 2018/05/24(木) 08:03:37.58

サクラダファミリアwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww
チェリーブロッサムボーイかよwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww

**デフォルトの名無しさん** · 2018/05/24(木) 08:09:10.38

だいたいそんなもんじゃない？
今まで静的解析かけてたようなものが、コンパイラに標準実装されたようなもんかと。
無自覚にガバガバのCpp書くよりはよっぽど良いかと。

**デフォルトの名無しさん** · 2018/05/24(木) 08:14:37.42

どっちに対しても言えるけど
そいつ本人の説得力ってのは
そいつのコードを見るまでわかんねえ

口では色々言ってるやつのコードが結局「えｗ」みたいなこともあるし
「えｗ」みたいなコード書いてるやつがそれを恥じて黙るどころか
むしろ誇ってるみたいな態度でどんどん発言をさらにするケースまであり

>>655
どっちかってーとコンパイラやボローチェッカが怒ってくれることは重視してない
言語の仕様とか、クロージャがすっきりかけたりするとことかすこ
C++のクロージャとか哀れで涙出てくるわ

**デフォルトの名無しさん** · 2018/05/24(木) 08:15:09.80

ageちゃったぃ
すんまそ

**デフォルトの名無しさん** · 2018/05/24(木) 08:35:15.47

自分のコードを見せなければ正体がバレないというのは楽観的すぎる
他人が書いたものをを正しく読めなかったらすぐバレる

**デフォルトの名無しさん** · 2018/05/24(木) 08:39:58.30

誰がそんなこと言ったんですかね……

**デフォルトの名無しさん** · 2018/05/24(木) 09:12:00.44

やっぱりお題必要だな