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

**デフォルトの名無しさん** · 2017/04/20(木) 04:43:27.12

いざ、語ろうぞ。

スレタイ超過のため、一部省略。
Go, Erlang, Kotlin, etcもウェルカム。
Haskellは協議により次世代失格になりました

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

あ · 2017/04/20(木) 07:32:05.38

乙

**デフォルトの名無しさん** · 2017/04/20(木) 08:19:51.38

TypeScriptも次世代言語に入れてくれ。

https://trends.google.co.jp/trends/explore?q=Golang,Typescript,Kotlin
Google社内の標準言語としてTypeScriptが承認される。ng-conf 2017
http://www.publickey1.jp/blog/17/googletypescriptng-conf_2017.html
TypeScriptが標準言語になっても、Dartのことは忘れてませんよとGoogle担当者がフォロー
http://www.publickey1.jp/blog/17/typescriptdartgoogle.html

**デフォルトの名無しさん** · 2017/04/20(木) 08:44:47.83

208 デフォルトの名無しさん[sage] 2017/04/19(水) 12:20:37.70 ID:rIlDsUIc

継承もカプセル化もオブジェクト指向には必要ない
クラスを作る、つまり型を定義する事こそがオブジェクト指向

265 デフォルトの名無しさん[sage] 2017/04/19(水) 23:10:42.57 ID:2dTlCsss

>>208
代数的データ型で型を定義できるHaskellはオブジェクト志向言語だった……？

266 デフォルトの名無しさん[sage] 2017/04/19(水) 23:12:01.85 ID:qOdNs+TP

>>265
代数的データ型とはなんぞや？

269 デフォルトの名無しさん[sage] 2017/04/19(水) 23:19:37.80 ID:qOdNs+TP

type c = a or b
みたいな？

270 デフォルトの名無しさん[sage] 2017/04/19(水) 23:20:37.20 ID:qOdNs+TP

これもオブジェクト指向と言ってもいいでしょう！

こんなん草生える

**デフォルトの名無しさん** · 2017/04/20(木) 12:21:47.82

TypeScriptはJavaScriptのクソな点をまともに直しただけで
次世代というものを感じないのだがなんかあるの？

**デフォルトの名無しさん** · 2017/04/20(木) 19:50:17.61

TypeScriptは次世代を担うってよりも
旧世代の資産をなんとか次世代まで持ちこたえさせるつなぎって感じ

**デフォルトの名無しさん** · 2017/04/21(金) 00:32:39.17

別に便利ならそれでいいと思うけど。

**デフォルトの名無しさん** · 2017/04/21(金) 13:54:11.80

>>5
とはいえ次世代は次世代でしょ

あ · 2017/04/21(金) 16:45:28.52

TypeScriptは手段が目的化してきてるからな。
構文は嫌いじゃないけど。

**デフォルトの名無しさん** · 2017/04/21(金) 23:38:23.47

なんでHaskell無くなってるの？もう学ぶの諦めたの？

**デフォルトの名無しさん** · 2017/04/21(金) 23:42:05.24

うん
Haskell学ぶなんて時間の無駄だってことに気づいたの

**デフォルトの名無しさん** · 2017/04/21(金) 23:59:18.37

>>10
前スレでHaskellは次世代言語ではなく遅延評価に問題があるとされた。
でもHaskellの考え方を学んで他の言語で活かすならありだと思う。

**デフォルトの名無しさん** · 2017/04/22(土) 00:57:02.64

問題とされたのは遅延することではなく何秒遅れるか予測不可能なことだと思う
タイミングを何秒後と指定して評価するのは問題ないとされる
現にそういう問題が出題されたしね

**デフォルトの名無しさん** · 2017/04/22(土) 02:36:22.27

いやHaskellを声高にプッシュしていた奴が例題のコードも出さずに逃亡して、Haskellそんなに詳しくない人が替わりに書くという事態になったからだよ
Haskellに詳しい人もHaskellについて議論できる人もいなかったんで対象として取り上げるには不適切になった(このスレでは)
Haskell上げの意見は説得力が無いしHaskell下げの意見はただのレッテル貼りにしかならない

**デフォルトの名無しさん** · 2017/04/22(土) 07:18:18.45

で、Haskellよりも劣った言語が次世代言語候補として残ったわけか
おもしれーw

**デフォルトの名無しさん** · 2017/04/22(土) 07:49:13.55

次世代言語なんだから、現行の言語を語っても意味ないよね。

**デフォルトの名無しさん** · 2017/04/22(土) 09:34:02.47

>>14
逃亡というレッテル貼りをおそれて多くの人が努力したんだな
レッテル貼りには人を努力させる効果があった
レッテル貼りは悪という意見にはあまり説得力がない
この場合、逃亡は悪ではかったと考える方が説得力がある

**デフォルトの名無しさん** · 2017/04/22(土) 09:54:38.02

>>17
最後の１行がそれより前とつながらないんだが

**デフォルトの名無しさん** · 2017/04/22(土) 10:24:05.10

糞問題、糞設計、糞実装だの言うわりにどれ一つ代替案は出てこなかった（つまりパラダイムは変えない）
加えて、正直な感想として現行言語の方が次世代と称される言語よりずっとすっきり書けていた
という現状をふまえると次世代の「売り」って何なのだろう

クラスや付随する言語機能を捨ててシンプルさを求めたこと（継承のデメリットの排除と学習コストの軽減）と
それで生じる表現力・抽象度の低下を型チェックや型推論機構の充実で補ってバランスをとったところ？

**デフォルトの名無しさん** · 2017/04/22(土) 10:33:00.05

HaskellとDが最底辺であることに変わりはない。
実用性皆無なプログラム言語は存在価値無し。

**デフォルトの名無しさん** · 2017/04/22(土) 10:40:11.00

訂正
逃亡は悪ではかった→逃亡は悪ではなかった

>>18
レッテル貼りは悪とは限らないし、そもそも悪と戦うことが目的ではない
戦いが目的でないなら逃亡は合理的だ

**デフォルトの名無しさん** · 2017/04/22(土) 11:00:51.13

>>21
そこじゃない！ｗｗｗ＞訂正

逃亡というレッテル張りを恐れて他の善意のファンが努力
→レッテル張り自体は悪だが結果はそう悪いものでもなかった

という流れからどうして逃亡自体が悪でないという帰結が導かれるのか？
ひたすら机上の空論を展開し、他を貶め、蔑み、悪態をつくだけついて
じゃあ動くコードやよりよい設計を出せというと逃げるのはどうみても身勝手だろう

**デフォルトの名無しさん** · 2017/04/22(土) 11:14:59.00

悪口を言われたから賠償してほしいって？
そんな出題者の意図があるとは知らなかった

**デフォルトの名無しさん** · 2017/04/22(土) 11:36:19.62

>>23
この場合、出題者は関係ないだろう
「他を」は「他言語（あるいはその使い手、ファン、コミュニティ）を」だ

**デフォルトの名無しさん** · 2017/04/22(土) 11:53:17.53

なんかいちいち噛み合わないな
もしかしてHaskell儲がまだいるのか？
なら逃亡行為を好意的に解釈したがるのも頷ける

**デフォルトの名無しさん** · 2017/04/22(土) 12:24:45.77

あんまり荒らしたくはないが、できるかできないかで言えばできたんだから問題ないだろ
それにType Classのコード理解できるやつ何人いた？
単なる継承だと勘違いしてるっぽい奴はいたが

**デフォルトの名無しさん** · 2017/04/22(土) 12:38:09.97

そもそも単価の高いHaskellerにタダでコード書けというほうが間違っている

**デフォルトの名無しさん** · 2017/04/22(土) 13:11:14.86

>>27
旧世代言語なら実質50行程度せいぜい10分で書けるコードにいくら請求するつもりだよｗｗ

それに単価ならカンブリア言語のSmalltalkerの方がよほど高いわ
奴ら呼べばきっと頼まれなくてもホイホイ書くぞ
Rust使いに次いで自分言語大好きだからな
https://developers.srad.jp/story/17/03/31/0448232/

**デフォルトの名無しさん** · 2017/04/22(土) 13:55:32.78

どうせお前ら、フレームワークに用意されたメソッドを
サンプル通りに呼び出すだけのドカタだろ？
次世代言語なんて要らんだろ

**デフォルトの名無しさん** · 2017/04/22(土) 14:38:27.32

そういう言語こそ切望されている。

**デフォルトの名無しさん** · 2017/04/22(土) 19:55:27.63

次世代言語ならおっさんにマウントされずに
仕事できると思ってるバカが多いってだけなんだよ結局。

**デフォルトの名無しさん** · 2017/04/23(日) 13:37:29.12

新スレ

abc系でみんなで人工知能を作ろう！
http://echo.2ch.net/test/read.cgi/tech/1488681839/

**デフォルトの名無しさん** · 2017/04/23(日) 14:04:42.00

個人的にはスレタイからRustも抜いてほしい。まともに物が作れないのにクソモジラのステマだけで話題になってる、言語未満のクソの塊。

**デフォルトの名無しさん** · 2017/04/23(日) 14:08:54.35

このスレは何を目指してるの？

**デフォルトの名無しさん** · 2017/04/23(日) 15:35:02.72

よく分からんよね
いつか知らないけど、次に主流になる言語が何かを決めたいんだろう

**デフォルトの名無しさん** · 2017/04/23(日) 15:41:50.81

もう全部C++でいいんじゃないかな
これから100年先までずっとC++だ

**デフォルトの名無しさん** · 2017/04/23(日) 16:07:52.01

>>36
それでいいそれで。他を圧倒的に突き放して一番早くて実用的な言語だ。

**デフォルトの名無しさん** · 2017/04/23(日) 16:10:21.34

多次元配列弱いC++はFortran以下
まず配列アクセス演算子が引数一つしか取れない時点で終わってる

**デフォルトの名無しさん** · 2017/04/23(日) 16:16:54.85

そりゃ、関数で十分だからな。テンプレートとオーバーロードと参照があれば
配列アクセス演算子なんて最初から必要なかった。

**デフォルトの名無しさん** · 2017/04/23(日) 16:20:47.89

まあ確かにEigenなんかは関数呼び出し演算子で代用してるな
そのEigenでさえ3次元以上には対応してないっていうのがC++の自由度の低さを物語ってるが

**デフォルトの名無しさん** · 2017/04/23(日) 16:24:19.41

逆に聞くけどそれなくて何か実用的なプログラミングで困るの？

**デフォルトの名無しさん** · 2017/04/23(日) 16:29:32.67

C++++あくしろよ

**デフォルトの名無しさん** · 2017/04/23(日) 17:38:01.40

>>41
深層学習とか統計処理とかには必須だぞ
量子化学にもあれば便利だな
データ整理一般にも使うしな

**デフォルトの名無しさん** · 2017/04/23(日) 19:47:31.29

いや、そんな要素一つ一つに対して別個の処理をするようなコードは
あんまいらんだろ。
本当に必要な場合は結局、配列レベルで高速化が望まれる場合だけだし。
誰かが用意した python のライブラリでも使ってなさいってこった。
カスが個人的に作ったものよりもよっぽど速くて正確なものがあるんだから。

**デフォルトの名無しさん** · 2017/04/23(日) 20:12:53.69

Python >>>> C++が証明されたな
速度においてもCython擁するPythonが負ける要素はないし

**デフォルトの名無しさん** · 2017/04/23(日) 20:19:34.87

C++er「もう全部C++でいい」
配列マン「多次元配列需要あるのにC++にはないやん」
C++er「そんなもんあんまいらんだろ。Pythonでも使ってなさいカス」

C++erってやっぱダブルスタンダードのカスだわ

**デフォルトの名無しさん** · 2017/04/23(日) 20:36:30.78

用途によって使い分けるという当たり前の発送のないバカと一緒にされたくないんだけど。。

**デフォルトの名無しさん** · 2017/04/23(日) 21:11:17.67

皮肉なのにマジで取られても

**デフォルトの名無しさん** · 2017/04/23(日) 21:15:41.28

あとはID:UJAzDyB2だけか

**デフォルトの名無しさん** · 2017/04/23(日) 21:50:20.49

多次元配列とはいえ結局は仮想メモリ上に一次元に乗るデータになるんだから、多次元→一次元マッピングを最初から最適にデータ設計出来てればいらんだろそんなもん。
そこを処理系任せにしてメモリ上のデータ構造チューニングできないようなものが次世代言語なのか？

**デフォルトの名無しさん** · 2017/04/23(日) 21:51:12.16

あ、ID変わったけどID:UJAzDyB2。

**デフォルトの名無しさん** · 2017/04/23(日) 22:10:15.66

最先端のアルゴリズムで実用ライブラリを書く言語としてのC++はこの先100年安泰で、
ラッパ用スクリプトのPythonとはそもそも言語としての立ち位置が違うって話。

**デフォルトの名無しさん** · 2017/04/23(日) 22:22:19.93

100年後の言語ってどうなってんだろな
頭にチンポ型の伝送デバイスハメるだけでプログラミングできたりする？

**デフォルトの名無しさん** · 2017/04/23(日) 22:24:04.51

そりゃもう感応入力で思考の速度でプログラミングできてるだろう
言語はなくなってるかもしれん

**デフォルトの名無しさん** · 2017/04/23(日) 23:40:41.71

C++を今の地位から引きずり下ろすためにもRustには頑張って欲しいものだ

**デフォルトの名無しさん** · 2017/04/24(月) 00:14:14.60

言語がなくなる
科学がなくなる
数学がなくなる
こういう無数の可能性から一個選んで的中させるのはほぼ不可能だよな

**デフォルトの名無しさん** · 2017/04/24(月) 00:21:20.12

ID:bkkcl6Xnの発言は一番気が狂っていた頃のエンジニアガイジと似てるな

**デフォルトの名無しさん** · 2017/04/24(月) 00:26:31.35

>>36
早くネットワーク系のライブラリを標準で入れてくれぃ

**デフォルトの名無しさん** · 2017/04/24(月) 00:33:57.43

ID:UJAzDyB2「C++は実用的な言語である。多次元配列がなくても実用的なプログラムでは困らない」
ID:bkkcl6Xn「私はID:UJAzDyB2である。C++は実用ライブラリを書くための言語だ」

なにこれ

**デフォルトの名無しさん** · 2017/04/24(月) 00:40:56.94

>>50
多次元配列でチューニングすべきところなんかあるか？せいぜい格納方向が2通りあるくらいだろ。チューニング出来るものは一切搭載してないFortranにすらデフォルトで搭載されてる機能だぜ？
それにそれ言っちゃあSTLなんてどうなるんだよ？まさかSTLは使うけど多次元配列は自分で作るなんて言わないよなあ？

**デフォルトの名無しさん** · 2017/04/24(月) 00:56:56.87

>>60
ガチ用途でSTL使わねえだろバカも休み休み言えよ……
STL使うC++なんてちょっと速いPythonやらRubyじゃねえか。

**デフォルトの名無しさん** · 2017/04/24(月) 00:58:00.30

>>61
ほーんSTLより速いの書いてあげてみ？
絶対無理だろ

**デフォルトの名無しさん** · 2017/04/24(月) 01:04:22.49

>>62
そりゃ自分の書くものに一番合うように書くから、あらゆるベンチを通すように丸く作られたSTLに全分野で勝てるわけないだろ。

**デフォルトの名無しさん** · 2017/04/24(月) 01:10:06.24

>>63
この用途ならこれが一番速くて信頼性が高くて拡張性も優れていて、自分で書いてSTLを使わないコストという面でも釣り合いが取れるっていうのがあるってことだよな？
用途から自分で設定していいから書いてみろよ。

**デフォルトの名無しさん** · 2017/04/24(月) 01:16:51.68

いや、そもそも多次元配列の話してたんだし、numpyを超えるスピード、信頼性の多次元配列を書いてもらうべきだな

**デフォルトの名無しさん** · 2017/04/24(月) 01:19:28.66

疎行列

**デフォルトの名無しさん** · 2017/04/24(月) 01:22:28.66

ああ、そもそもSTLで出来ないことを書いて「勝った」っていうのはなしだぞ。それこそ疎行列とかな

**デフォルトの名無しさん** · 2017/04/24(月) 01:30:31.10

ハッシュマップ

**デフォルトの名無しさん** · 2017/04/24(月) 01:36:23.44

ってか割と真面目にC++上で動く多次元配列欲しいんだけど
1～5次元くらいまで同じインターフェースで動く奴作ろうとして、思いの外面倒だったから辞めてFortranに乗り換えたことあるんだよな

**デフォルトの名無しさん** · 2017/04/24(月) 06:51:30.21

>>42
亀だけど、C#って、C++++という意味を込めてるんだよ。

**デフォルトの名無しさん** · 2017/04/24(月) 20:17:17.36

>>65
だよねぇ、多次元配列の操作で Python に勝るのは Fortran くらいしか思いつかないや
純粋手続き型言語の始祖である Fortran と、同じく純粋手続き型スクリプト言語である
Python、誰にも否定できない当然の結果だよね

もう、このスレでは次世代 Fortran は Python で決まり！！ってこと結論が出たね

**デフォルトの名無しさん** · 2017/04/24(月) 21:50:54.50

その結論は何を表すの？

**デフォルトの名無しさん** · 2017/04/24(月) 23:19:46.46

>>71
多次元配列操作で次世代言語を選ぶならJuliaだろう。

Python使いをJuliaに引き込むサンプル集
http://www.mwsoft.jp/programming/julia/python_to_julia.html
RユーザのためのJulia入門（行列編）
http://rishida.hatenablog.com/entry/2013/11/30/194733

**デフォルトの名無しさん** · 2017/04/24(月) 23:52:45.18

Juliaのステマ貼るならせめて最新版の解説貼れよ
ないけどさ

**デフォルトの名無しさん** · 2017/04/25(火) 00:38:05.23

>>74
Qiitaで検索するかAdvent Calendarｓを読め。
普及が始まっている次世代言語は
たいていAdvent Calendarｓ 2016がある。

**デフォルトの名無しさん** · 2017/04/25(火) 02:23:12.66

言語オタクが重視する言語間の細かいシンタックスの差なんてどうでも良くて、
次世代言語に必要だったのは高速で便利な多次元配列だったってオチか

**デフォルトの名無しさん** · 2017/04/25(火) 08:40:21.09

>>75
Julia0.3の化石みたいな記事貼るなって意味だよ

**デフォルトの名無しさん** · 2017/04/25(火) 10:54:45.65

Juliaって化石なの？

**デフォルトの名無しさん** · 2017/04/25(火) 10:55:45.34

0.3はね
そろそろ0.6

**デフォルトの名無しさん** · 2017/04/25(火) 11:10:54.53

>>76
多次元配列が必要な人間は一部だけど文法が全員に影響があるから、多数決で文法優先
オタクではなく多数決です

**デフォルトの名無しさん** · 2017/04/25(火) 11:51:27.86

RubyとPythonとか観てると文法より多次元配列やライブラリのが重要だと実感するが。
C#やJavaScriptにしても、簡潔に書けるとかじゃなくて何を作れる(サポートするプラットフォームの多さ)で選ばれてるし。

**デフォルトの名無しさん** · 2017/04/25(火) 12:35:16.20

利用者が多い・ライブラリが豊富って現在流行っているものの話でしょ

**デフォルトの名無しさん** · 2017/04/25(火) 12:35:23.60

多次元配列が重要って感覚がわからないんだけど、
どういう分野の人が使うの？

あ · 2017/04/25(火) 12:49:25.85

多次元配列ってジャグじゃないものの事だよな？
マクロ書いちゃえばいいんでないの？
アクセス演算子と大仰な言い方するが、要は単に掛け算なんだし。アライメントも揃えられるしさ。

適当な並べ方してるとメモリアクセスで悲しい思いをする気がする。特にどーんとクラスタに投げるときとか。
Fortranでもメモリマップ的には後ろの列からの順番になるから思い付きで並べると重いよ。

あ · 2017/04/25(火) 12:51:38.43

>>83
テンソルに係数を掛けたり、テンソルとベクトルを掛けたりすると、欲しくなるのは確か。
unionって思ってたより随分便利だなーって思うやつ。

**デフォルトの名無しさん** · 2017/04/25(火) 12:56:48.67

>>82
Rubyが流行りそうになった時、RoRの登場で一躍有名になった。
Pythonにはそれに相当するものが無かった。
後に同じようなの出来たけど、Rubyを引き離すほどじゃ無かった。
Ruby1.9の時、互換性切り捨てでRuby自滅が決定打だった。
結果としてディープラーニング向けライブラリの登場で揺るぎない地位を得た。

文法はRuby1.9以降のが好きだし理に適ってる。
でも、世界的には終わった言語。