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

**デフォルトの名無しさん** · 2017/06/13(火) 08:54:07.99

いざ、語ろうぞ。

スレタイ超過のため、一部省略。
その他もウェルカム。

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

あ · 2017/08/08(火) 08:04:36.27

>>630
いわゆるMS BASICからQUICKBASIC→Visual Basic→VB.netと辿っていけばわかるけど、普通にMicrosoft系のBASICだと思うけど。
どの辺がBASICっぽくない？

**デフォルトの名無しさん** · 2017/08/08(火) 11:58:13.44

>>643
typescriptもjsに変換されるから無関係
V8エンジンが速いという条件ならatomも同じだぢ

**デフォルトの名無しさん** · 2017/08/08(火) 11:58:30.92

x だぢ
o だし

**デフォルトの名無しさん** · 2017/08/08(火) 14:24:25.13

>>646
それは言われなくても分かる。
素のES2015よりメンテナンス性や安定性が向上しないかな。
例えばnull安全なコードがかけるからnilチェック漏れとかを潰せるし。
プラグインもtypescriptでかくから少しましになる？

**デフォルトの名無しさん** · 2017/08/08(火) 16:22:17.89

>>648
それはそうだけど、>>635から始まったvscodeのパフォーマンスの話してるからtypescriptであるかは関係ない

**デフォルトの名無しさん** · 2017/08/08(火) 22:23:27.85

>>622
勘違いしてるぞ
EitherはMaybeの上位互換だ

**デフォルトの名無しさん** · 2017/08/08(火) 23:05:33.35

>>650
多値返却に関してはgoのことやね
Eitherに関しては取り敢えず無視してたわ

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

エラーをバケツリレーするより
エクセションで飛ばした方が簡単でしょ

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

簡単そうに見えても結局それぞれの場所でオブジェクト開放を
うまくやらなきゃならんことを考えれば大して楽になるわけでもない。

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

VSCodeでインテリセンス技術をオープンソースにしたのは地味に画期的なことだと思う
IDE分野でのMSの強さを支えるコア技術だよね

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

Goはパターンマッチないのに例外を戻り値で返すからあんな面倒な事になってるんだろ

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

その言い方だと例外投げられればいいのかパターンマッチが導入すればいいのか
わからんが。
どっちかもしくは両方あれば楽になったとでも？

プログラム書く上でまったく本質的な制約だと思わんな。

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

本質的な制約って何だよ？

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

>>656
どちらか欲しい
両方ないのはキツイ

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

あと複数の戻り値じゃなくてタプル+単一戻り値の方が扱いやすい

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

よくわからんが、タプル+単一は複数とは違うのか？

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

Pythonとかあれタプル＋単一じゃね？

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

+演算子をorの意味で使ってるのか?
それだとタプルを返した時は単一ということになるか
単一の意味も違うのかもしれない

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

形式的にだけど、返り値はタプル一つになっていて、それを分配束縛してることになってなかったっけ？
違ったかも

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

んで結局、>>659はどういうのが扱いやすいと言っていたわけなの

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

タプルとEitherはC言語のstructとunionに戻るようなものだからな
次世代の面子が潰れる

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

goの戻り値がタプルのほうが嬉しいという気持ちはわかる。
自作の型に自由にメソッド生やせるのに、メソッドチェーンしようとした場合に、多値を返されると無理。

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

>>666
golangは本当メソッドチェーンが出来ないよな

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

まぁそういう弱点ありつつもgoは嫌いじゃないんだけどね。
エコシステムの部分とか。

import文にgithubのurl?を書けたり。

標準ライブラリのコードが自然に見にいけるから書いている最中も勉強になるし、標準ライブラリが教科書的な役割をはたしてくれたり。

コードフォーマットが標準装備で言語仕様的に制約が強いから構文規約は一つしかないところとか。

と言いつつも他の言語を見て羨ましくもあり。もっと関数型チックになってほしいけど無理かな。

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

メソッドチェーンが遺物だと気づけw
Goは意図的にメソッドチェーン出来ないようにしてるんだ

**デフォルトの名無しさん** · 2017/08/10(木) 00:20:35.92

パイプライン演算子の便利さを考えるとメソッドチェーンもそこまで悪くない気もするが、使い方次第かねえ

**デフォルトの名無しさん** · 2017/08/10(木) 01:03:52.42

パイプカットでGo

**デフォルトの名無しさん** · 2017/08/10(木) 01:40:12.18

パイプラインの方が柔軟性高くていいよね
do_something foo |> lambda x => x + other_fun bar |> ...
みたいな前の戻り値のメソッドに限定しない書き方ができる

これをもっと楽にするような記法、例えばパイプラインの式中のアンダースコアは前の値とする、みたいなのがあると嬉しい
上のやつと等価だったらdo_something foo |> _ + other_fun bar |> ... みたいな

**デフォルトの名無しさん** · 2017/08/10(木) 01:51:16.15

Juliaでそのアンダースコア議論されてて、結局実装されなかったんだよなたしか

**デフォルトの名無しさん** · 2017/08/10(木) 01:52:27.10

それはおかしいでしょ
カリー化した方が自然

**デフォルトの名無しさん** · 2017/08/10(木) 01:55:26.39

2番目の引数を先に埋めてアンダースコアは一番目にしたいパターンがあるので、どちらかと言うとカリー化は好きじゃないなあ。設計が悪いと言われたらそれまでだけど

Juliaの場合は多重ディスパッチを採用している関係でカリー化は諦めたっていうのもあったな

**デフォルトの名無しさん** · 2017/08/10(木) 03:00:14.84

>>665
いやだからEitherモナドはMaybeみたいに正常系だけ書いていけるし単値だしで全然違うって
なんで皆使ったことも無いのにそんな事言うの…

**デフォルトの名無しさん** · 2017/08/10(木) 07:31:11.02

単純にノイズが増えるだろう
現実にはほとんどの関数がエラーを返す可能性を持ってるんだから、言語に織り込んでデフォルトを Error | Result とするのは悪いアイデアではない

**デフォルトの名無しさん** · 2017/08/10(木) 08:32:51.57

>>676
これ実際Haskell書いてないと分からない感覚かもな

**デフォルトの名無しさん** · 2017/08/10(木) 23:01:38.31

(Elixirは？動的型付け言語に人権はありますか)

**デフォルトの名無しさん** · 2017/08/11(金) 07:15:28.72

ほとんどの動的型言語ってそれが動的型であるメリットは特に無くて
単なる処理系実装者の怠慢でしかない
動的型言語を推すならまずはそれが動的型でなければならない理由を示すこと

**デフォルトの名無しさん** · 2017/08/11(金) 08:32:31.97

lisp とか仕様をシンプルにできることかな。
あほみたいに仕様が膨らんで意味の分からんキャストをがばがばおこなわなきゃならん
みたいな不自然なことで生じるバグは減る。

**デフォルトの名無しさん** · 2017/08/11(金) 08:51:11.85

>>680
怠慢に寛容になると嘘をつく人間が減るから
自分はなにもしないくせに他人の嘘をデバッグするのだけはうまい奴がいる
そういう奴がいても許されるから嘘が減る

怠慢を許さない環境では忙しくて嘘を見抜く暇もないから嘘が蔓延する

**デフォルトの名無しさん** · 2017/08/11(金) 08:56:57.66

そもそも型が必要な理由が分からん。
数学なら「整数型のxが・・・」なんて言わないしな。
「ここでxは整数とする」はあるけど、条件に過ぎないし。
リストやタプルも分ける必要ある？

**デフォルトの名無しさん** · 2017/08/11(金) 10:46:48.12

372仕様書無しさん2017/08/11(金) 10:31:43.41
フリーランスで検索すると引っかかる零細ITがやっているサイトだめだ。
高額に見せているけど実際は50万前後
JIET加入した方がいいよ。案件は毎日千件以上末端価格は60万円　平凡な稼働時間の80万円の案件もある。
ユー子が求人をだしてる。名刺も渡せる。ユー子に名刺を渡せるんだぞ。夢のようだ

それらの案件まさぐってHPで転売していたのが零細ITがやるフリーランスサイト

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

>>683
型はその条件をいろいろ細かく定義したものだろ。
値域や定義域だって型。

**デフォルトの名無しさん** · 2017/08/11(金) 11:17:57.35

動的型の問題って関数のインターフェースがガバガバなところでしょ？
elixirはパターンマッチで結構制約できるから動的だからって卑下する必要ないのよ

**デフォルトの名無しさん** · 2017/08/11(金) 11:44:41.66

>>680
動的型でなければならない理由？
それは、おまえがバカだからだろう。

**デフォルトの名無しさん** · 2017/08/11(金) 11:59:08.49

>>685
少なくともunsigned は要らなくない？
1bit ケチれるだけだし。
中途半端な単精度浮動小数点とかも。

**デフォルトの名無しさん** · 2017/08/11(金) 12:01:25.46

申し訳ないが未だに使っているGPUの多い単精度小数点DisはNG

**デフォルトの名無しさん** · 2017/08/11(金) 15:03:12.85

>>686
まだコードを書いてないのに問題でしょとか言われても
言う時期が早すぎるし言う内容に具体性がないよ
まるで数学も英語もまだ知らない小学生にプログラミングを教えているようだ

**デフォルトの名無しさん** · 2017/08/11(金) 15:39:55.52

TypeScript触ってるとjsに型がある方が幸せだってわかる。
jsonにスキーマ設定無しで
reduxでstate管理するのとか絶望する。
あと、学習面でも明らかに型があったほうが幸せ。書いてる端から指摘してくれるからすごく幸せ。
TypeScriptはvscodeとセットで幸せー

**デフォルトの名無しさん** · 2017/08/11(金) 15:58:37.67

>>688
今言ってる片野必要性は容量のためじゃないだろ
全ての引数をテストするとすると1bit減ることでテストの数が半数になる実装もその1bitに対して考える必要がなくなる
例えばルートを計算する関数を実装するのに引数が正の整数と限定されてれば簡単だが、負だったり小数した場合は複雑になる。文字列や画像だった場合は例外が発生したりアボートしたり誤作動するかも知れない。
型はビジネスロジックに集中するためのルール、制約だ
静的は言語レベルで強制、チェックしてて、動的ではユーザ、実行時に任せてる

**デフォルトの名無しさん** · 2017/08/11(金) 18:06:45.60

関数の引数なんかはやっぱ型があった方が読みやすいなと思う。
でも内部のテンポラリ変数なんかは別にいらんかもね。
というかテンポラリ変数の型情報がないと読めないようなコードは
そもそもコードが長すぎるとか、他の根本的な部分に問題がある気がする。

**デフォルトの名無しさん** · 2017/08/11(金) 19:32:48.58

>>682
>>690
内容がフワフワしてて何言ってるのか理解できない
もっと具体的かつ簡潔に言え
Twitterによくいるプログラミングできないのにプログラム語ってるクソ野郎みたいだぞ

**デフォルトの名無しさん** · 2017/08/11(金) 19:36:48.30

>>688
unsignedはオーバーフローしても下から戻るから楽
つか実装型まで否定するって、じゃあ任意精度にしろってか？
計算量制御できなくなるぞ？

**デフォルトの名無しさん** · 2017/08/11(金) 21:54:24.08

世界で最も使われている西京言語JavaScriptをディスってんのかメーン

**デフォルトの名無しさん** · 2017/08/11(金) 22:53:04.88

西京漬けいいよね

**デフォルトの名無しさん** · 2017/08/11(金) 23:18:20.12

最近はtypescriptが流行っていてな

**デフォルトの名無しさん** · 2017/08/12(土) 08:33:13.28

>>694
プログラミングできるできないではなくタイミングの問題
目の前のことを言えば具体的かつ簡潔になる
遠い将来のことを語るとフワフワする

**デフォルトの名無しさん** · 2017/08/12(土) 09:39:33.11

次世代言語を語りたければ、今流行ってる言語の分析をしないと
Java、C#、C/C++が人気だけど

**デフォルトの名無しさん** · 2017/08/12(土) 11:11:20.00

WindowsとLinuxのAPIが人気
Javaは大規模開発が云々で人気

**デフォルトの名無しさん** · 2017/08/12(土) 11:28:39.85

Java系は一貫した技術の枠内で一通り完結するのがメリット
アプリケーションロジックの開発に集中できる

**デフォルトの名無しさん** · 2017/08/12(土) 13:00:05.73

マクロはズルってのと同じで枠の外にあるものはズルなんだな

**デフォルトの名無しさん** · 2017/08/12(土) 13:36:29.79

しかし結局欲しいのはマクロでしょ？ってなることは結構ある。

**デフォルトの名無しさん** · 2017/08/12(土) 14:15:33.93

>>700
Java…型推論ない、論外
C/C++…メモリ安全じゃないので面倒
C#…まあ使える。ただT aだったりT b()だったりで書き方がちょっと古い

**デフォルトの名無しさん** · 2017/08/12(土) 14:17:29.71

C#は良い言語だと思うよ
パターンマッチが追加されたりifが式になったりで便利になってきてるし

**デフォルトの名無しさん** · 2017/08/12(土) 14:20:25.35

.NET依存が激しいのが好きじゃない

**デフォルトの名無しさん** · 2017/08/12(土) 14:22:40.68

>>707
なぜ？

**デフォルトの名無しさん** · 2017/08/12(土) 14:26:21.46

事実上Windowsでしか動かねーやん
話にならんわ

**デフォルトの名無しさん** · 2017/08/12(土) 14:29:29.00

>>709
いつの時代の話だよｗｗｗ

**デフォルトの名無しさん** · 2017/08/12(土) 14:31:48.99

.net coreはまだプロダクションで使うのは怖いだろ
仮にそこ乗り越えたとしても、C#だと結局開発はVS最強なんだから窓開発になる

**デフォルトの名無しさん** · 2017/08/12(土) 14:32:59.46

.NET CoreだけじゃなくてMonoもあるぞ

**デフォルトの名無しさん** · 2017/08/12(土) 14:38:41.45

>>711
もう1年以上経つし、そろそろ.NET Standard2.0も出るこの時期に何言ってんだか
素直に知りませんでしたでいいよ

**デフォルトの名無しさん** · 2017/08/12(土) 14:39:29.47

（新しいことを学ぶのが）怖いってことだな

**デフォルトの名無しさん** · 2017/08/12(土) 14:46:02.46

.NET Standardってなんや

**デフォルトの名無しさん** · 2017/08/12(土) 14:47:02.12

見事にオープンソースとクラウドの時代を代表するリーダーの一人として転身を果たしたMS
存在感を失い続けるIBMとオラクル
そう考えるとJavaは疫病神なのではないか

**デフォルトの名無しさん** · 2017/08/12(土) 14:51:47.74

>>715
Fullの.NET FrameworkやMono、.NET Coreがそれぞれ実装すべきAPIを定めたもの

**デフォルトの名無しさん** · 2017/08/12(土) 14:53:12.33

LinuxのMonoっていい感じなん？

**デフォルトの名無しさん** · 2017/08/12(土) 14:54:08.03

>>716
こないだのPaketの件といい、.NET CoreからFullの.NET Frameworkの一方的な切り捨てと言い、コミュニティをないがしろにしてちょいちょい炎上してるけどな

**デフォルトの名無しさん** · 2017/08/12(土) 18:22:00.10

こういう妄信タイプがいるから
環境依存言語は嫌なんだよ。

**デフォルトの名無しさん** · 2017/08/12(土) 19:44:58.81

今じゃもう.NETを忌避するほうが逆に宗教みたいになってるよな

**デフォルトの名無しさん** · 2017/08/12(土) 20:00:15.90

.NETはまだまだ環境の問題もあるからともかく、
MSだからという理由でMSのプロダクトが開発者に嫌われることは少なくなったね
マカーがMS製のエディタでMS製の言語でプログラミングしてそれをMSのクラウドプラットフォーム上でホストされてるLinuxへデプロイするとか　一昔前ならあり得ない未来だった

**デフォルトの名無しさん** · 2017/08/12(土) 20:03:25.03

Monoで動いているものは結構色々あるはず
例えば3DGameEngineのUnityはC#で開発できるけど裏でMonoが動いてる
マルチプラットフォームな開発環境であるXamarinもMonoを使ってる。
知らないうちに.Netは大半のプラットフォームで動くように。

**デフォルトの名無しさん** · 2017/08/12(土) 20:10:51.11

完全マカー依存のスーウィフトはどうなりましたか（小声）

**デフォルトの名無しさん** · 2017/08/12(土) 20:19:13.69

.NETはLLVMつかってネイティブ化する計画なかったのか

**デフォルトの名無しさん** · 2017/08/12(土) 20:24:30.75

実際のところ.Netを選ぶメリットって何かあるのかな？
マルチプラットフォームならtypescriptとelectron、もしくはreact nativeで良い気がするけど。

**デフォルトの名無しさん** · 2017/08/12(土) 20:25:59.19

現行、LLVMの使用はLinux、Macのみらしいが原理としてLLVMが動くすべてのOSでネイティブコンパイルできるのでは?
実際動かしてないし間違えてるかも。

性能を強化した「.NET Core 1.1」が公開　2016年11月21日
米Microsoftは11月16日、「.NET Core 1.1」を公開した。性能が強化されたほか、対応するLinuxディストリビューションも拡大した。
最新版では対応するディストリビューションを拡大し、Linux Mint 18、OpenSUSE 42.1、macOS 10.12、Windows Server 2016で利用できるようになった。
macOS 10.12とWindows Server 2016については、.NET Core 1.0も利用できる。
Linux向け、Mac向けでは、CoreCLRをClang/LLVMでコンパイルするため、次のリリースでClang版のPGOをサポートする予定としている。
https://mag.osdn.jp/16/11/21/154500

**デフォルトの名無しさん** · 2017/08/12(土) 20:33:46.06

まあ実際使ってみると右往左往することになるわけだが。
「互換性」あるってセールストークに馬鹿みたいに引っかかりすぎなんだよ。

**デフォルトの名無しさん** · 2017/08/12(土) 20:36:01.39

>>728
それは環境によるだろ…
すぐ一纏めに考えるのは愚かな事

**デフォルトの名無しさん** · 2017/08/12(土) 20:42:05.60

こういう流れらしい。

.NET Coreとは？　2017年6月6日

.NET Coreがリリースされて約1年経ち、ようやくビルドツールも正式版としてリリースされるに至った。
本連載記事では、「Linuxを中心にクロスプラットフォームで開発できる.NET Core」という視点で、開発の方法を説明していきたい。

.NET Coreの歴史
Windows上でのみ動作する.NET Frameworkは、2002年に最初に登場して以来、バージョンアップを重ねてきた。
それに対し、Windows・Linux・macOSで動作するクロスプラットフォームな.NET Coreが発表されたのが、2014年11月12日のことである。
このとき、今までWindowsのみをサポート対象としてきた.NETが、LinuxやmacOSもサポート対象としたことに加えて、最初からGitHubでオープンソースとして公開されたことにも驚きがあった。

クロスプラットフォームを動作環境とすることに関しては、Monoプロジェクトという先人がいた。
Monoプロジェクトは.NET Frameworkの互換環境をLinuxやmacOSを含めたスマートフォンOSにすることを目標としており、その中にはGUIフレームワークも含まれている。
Monoプロジェクトは現在、Xamarin社が開発・サポートをしており、スマートフォン向けのクロスプラットフォーム開発環境であるXamarinブランドの製品を提供している。
そのXamarin社が、2016年にMicrosoft社に買収されて今に至っている。

Monoが.NET Frameworkそのものと互換性のある環境を目指していることに対し、.NET Coreは.NET Frameworkのサブセットとなる機能をクロスプラットフォームで提供することを目標としたわけである。
そして、.NET Coreの発表から約1年後の2015年11月5日にRed Hat社がMicrosoft社と協力し、Red Hat Enterprise Linux上での.NETのサポートを発表した。

.NET Coreの特徴はいくつか挙げられるが、ここでは特に「クロスプラットフォーム」「オープンソース」「軽量」「フレキシブル」の4点について強調したい。
http://www.buildinsider.net/language/dotnetcore/01

**デフォルトの名無しさん** · 2017/08/12(土) 21:41:47.95

>>726
過去の膨大な資産（負の遺産とも言う）

**デフォルトの名無しさん** · 2017/08/12(土) 23:44:55.22

南シナ海に中国が基地作ってるよね。
だいたいそんな感想

**デフォルトの名無しさん** · 2017/08/13(日) 00:09:25.46

>>728
Javaも同じだけどね。
お陰で一度書けばどこでも動くって宣伝文句も、一度書けばどこでもテストが必要って揶揄されて久しい。
HTMLも然り。
実はHTML5+JavaScriptのが動的言語な分タチが悪いっていう。

>>726
TypeScriptもMS製ですよ。
VS Code出したし、.net Standerd出たしってなると、VC#のマルチプラットフォーム化が始まりそうな予感はするが。
(MonoでC#のマルチプラットフォーム化はしてるけど、C#の良さはやはりIDEであるVSあってこそ)

**デフォルトの名無しさん** · 2017/08/13(日) 00:14:48.70

>>733
VS for Macは？

**デフォルトの名無しさん** · 2017/08/13(日) 00:21:36.37

typescriptがMs製なのは知ってるよ。
そして素晴らしいのはtsserverを同梱してること。
言語自体にリファクタリングや定義箇所への参照機能等ideに必要な機能を同梱させたんだよね。

この仕様をlanguage server protocolとして標準化しようとしてるのも素晴しい。
ide側で言語仕様を把握する必要がなくなり、上記のプロトコルを解釈する機構を用意しておけばいい。

**デフォルトの名無しさん** · 2017/08/13(日) 00:25:12.33

ぜひともlanguage server protocolを言語側で用意するのを必須にしてほしい。
新興言語ほど補完機能が弱いことが多いから。goの補完が効くようになったのもここ二年くらいからだったし。

**デフォルトの名無しさん** · 2017/08/13(日) 00:28:03.98

マルチプラットフォームの夢も分かるけど、現実的じゃないんだよね。。。
一個のOSでさえバージョン違いで互換性崩れるのに、それを複数とか。
現実的にはテストの都合でプラットフォームもバージョンもグッと絞らないと死ねる。

**デフォルトの名無しさん** · 2017/08/13(日) 00:53:43.57

MSはLinuxの技術者が食いついてきたらLinuxがクソになってきたので独自拡張LinuxまたはWindowsのみのサポートにしますって言って利益をあげるんだろ
知ってるんだから

**デフォルトの名無しさん** · 2017/08/13(日) 00:57:05.96

>>730
これアレじゃね？
競合しそうな会社を買って手中におさめて
コントロールするか飼い殺しにするかっていう
いつものMSじゃね？
少なくとも
>Monoプロジェクトは.NET Frameworkの互換環境をLinuxやmacOSを含めたスマートフォンOSにすることを目標としており、
>その中にはGUIフレームワークも含まれている。
の部分はもはや怪しいというか
.NET Coreで行きたいんでしょ？MSは

**デフォルトの名無しさん** · 2017/08/13(日) 01:07:45.53

いやXamarinって普通に成功してるからね

**デフォルトの名無しさん** · 2017/08/13(日) 01:08:09.23

linuxでVS使わせてくれればマルチプラットフォームなんてどうでもいい

**デフォルトの名無しさん** · 2017/08/13(日) 01:22:18.67

次世代言語ってなんなんだ？

Cの次世代言語がC++だと言われれば納得できる
c++の次世代言語がjavaだと言われればちょっと首を傾げながら納得する

javaやc#などの次世代言語が　Go Rust Scala Haskellだと言われたら
全く納得できない

**デフォルトの名無しさん** · 2017/08/13(日) 01:49:44.40

そりゃそうだ
次世代というなら、シェアをひっくり返すかトントンぐらいまで行かないと
次世代とは言えない
というか、そういう状況にならないと
業界が何となく全体的に次世代に移った、とは言えない
なら次世代とは何なんだ、「世代」とは何なんだ
来もしないであろう架空の未来のことを
「次世代」と言っても仕方がないではないか
C++の次世代という触れ込みだったD言語は言語仕様的にはそうかもしれないが
全然普及しなかったからC++の次世代だ！っつってもふ～んって感じだし
そんな「世代」は来なかった、って感じ

**デフォルトの名無しさん** · 2017/08/13(日) 01:52:23.84

結局はJava、C#、C++などの現世代の王道言語が順当にバージョンアップして
移行が行われたら、その地点が「次世代」って事になる