次世代言語14 Elixir Crystal Julia Rust Swift

**デフォルトの名無しさん** · 2018/09/11(火) 21:28:24.70

前スレ
次世代言語13 Go Rust Swift Kotlin TypeScript
https://mevius.5ch.net/test/read.cgi/tech/1534769753/

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

言語を「叩く」っていうのが噴飯物なのよ
何を根拠にまぁえらそうに
知識も経験も無いからこそなんだろうけど
オカンのただ飯食わせてもらいながら飯批判するが如し

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

たしかに

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

俺はちゃんと人を叩いてるぞ
型も理解できないモンキーどもは、森に帰るか死んで欲しい
迷惑だ

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

ちがうそうじゃない

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

コードも憎んで人も憎む
どいつもこいつもバカどもは
憎しみだけで人が殺せたらどんなにいいかと毎日考えてるわ

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

自演で荒らすな
ﾜｯﾁｮｲスレへ帰れ

**デフォルトの名無しさん** · 2018/09/14(金) 23:01:19.24

>>78
まずはお前が自殺しようなｗ

**デフォルトの名無しさん** · 2018/09/14(金) 23:02:56.56

黙れ奇形のベトコンめ

**デフォルトの名無しさん** · 2018/09/14(金) 23:03:48.94

型理解してないゴミのコードってマジでゴミでしかないよな

**デフォルトの名無しさん** · 2018/09/14(金) 23:20:49.66

どれだけワッチョイスレへ誘導したいんだ荒らしは？
一人で寂しいからって俺らには関係ねえだろ

**デフォルトの名無しさん** · 2018/09/14(金) 23:33:34.32

◆QZaw55cn4cか

**デフォルトの名無しさん** · 2018/09/14(金) 23:42:55.08

叩くのはエンターキーだけにしろ \ドッワハハハ/

**デフォルトの名無しさん** · 2018/09/14(金) 23:49:36.15

あー全員●したい

**デフォルトの名無しさん** · 2018/09/15(土) 00:51:34.66

芋ほりか

**デフォルトの名無しさん** · 2018/09/15(土) 00:52:16.14

rustのclippyゴイスー
よくこんなめんどくさそうなの作ろうと思ったもんだ
近代的なlintはみんな同じくらいめんどくさそうなことことしてくれるの？

**デフォルトの名無しさん** · 2018/09/15(土) 01:48:02.06

>>68
次のパラダイムは人工知能に関連した何かだと思う

**デフォルトの名無しさん** · 2018/09/15(土) 02:48:23.69

>>89
Lisp復権の時か！

**デフォルトの名無しさん** · 2018/09/15(土) 08:06:42.27

>>89
まず、言葉の定義からして
そんな適用範囲の狭すぎるものはパラダイムとは呼ばないと思うのだが

**デフォルトの名無しさん** · 2018/09/15(土) 10:27:53.40

オブジェクトのコピー、参照の明示化
const的な不変性の明示化
副作用の取り扱い

この辺じゃないのかね。
とはいえrustはなんか違うとは思うが。

**デフォルトの名無しさん** · 2018/09/15(土) 10:58:28.10

LabVIEWある程度やったことある人なら分かるんだけど
ほとんどの言語が変数でやることを配線でやるってなると
（もちろん、ローカル変数グローバル変数ともに実はあるんだけど）
その配線を引くのが手間で仕方ないし
配線がまさにスパゲッティの様相を呈してくる

その反面、そこが苦痛であるがゆえに促される事前の設計というものがある
配線をスッキリさせたいと常に思うような力になってる
こういうのこそ実はパラダイム

**デフォルトの名無しさん** · 2018/09/15(土) 11:31:06.97

>>92
完全にrustじゃん

**デフォルトの名無しさん** · 2018/09/15(土) 11:38:12.15

>>93
LabVIEW懐かしいな
アレでコーディングするコツは変数を構造体化？して一本化してからループに繋いで
Swich-caseみたいなページで処理を分けて書けば随分シンプルで見やすい配線図にできたはず

**デフォルトの名無しさん** · 2018/09/15(土) 13:07:49.43

javaがval導入してればもう少しシェア維持できたろうにな
final varとか書くんだろ？バカちゃう？バカちゃう？
ワイがrfc書いた方がずっとマシですわｗ

**デフォルトの名無しさん** · 2018/09/15(土) 13:13:21.48

どうでもいいだろ
Javaを使ってる会社がJava10以降へ移行する際にまずやることは、
ラムダのときと同じくコーディング規約に「varは使用しないこと」の一行を追加することだよ

**デフォルトの名無しさん** · 2018/09/15(土) 13:16:57.41

>>94
オブジェクトのコピー、参照の明示化
副作用の取り扱い
について,rustは問題あるだろ。
= をコンテクストで意味判断するってのがそもそも問題あるんじゃねーかと思ってる。
副作用あるなしももう少しやりようある気がするけどね。

**デフォルトの名無しさん** · 2018/09/15(土) 14:49:13.19

来なかった次世代のD言語をインストールしてみた

**デフォルトの名無しさん** · 2018/09/15(土) 15:31:59.52

>>99
D使うならDUBはチェックしとき
https://qiita.com/yasei_no_otoko/items/2724eebab10f5cd0a02f
https://code.dlang.org/

**デフォルトの名無しさん** · 2018/09/15(土) 17:23:17.28

PHPにプロパティ型指定だったな
良いことだと思うが
根本的に言語が腐ってるから二度と近寄りたくないし、手遅れ

**デフォルトの名無しさん** · 2018/09/15(土) 21:09:05.46

本気で思うんだがオブジェクト指向で作られたプロジェクトを手続きや関数型で作ってたら本当に困ることになるんかしら？

**デフォルトの名無しさん** · 2018/09/15(土) 21:13:47.35

>>98
具体的にどんな問題が？

**デフォルトの名無しさん** · 2018/09/15(土) 22:26:29.72

メモリもリソースの一種だとみると、副作用って簡単に判じることは難しいんじゃないか
それともメモリをどう荒らしても純粋関数って呼ぶことにする？副作用の有無の価値が大分減るように思えるが

**デフォルトの名無しさん** · 2018/09/15(土) 22:33:31.76

純粋/副作用有りの2択にせずに、noexceptみたいにnoheap, nostack, noio...って小分けすればいいだろ
凄い面倒そうだけど

**デフォルトの名無しさん** · 2018/09/15(土) 23:17:27.00

>>104
これ考えたらやっぱりFortranのpure subroutineが良い

**デフォルトの名無しさん** · 2018/09/15(土) 23:18:18.51

純粋関数型で有名なHaskellだが遅延評価で最適化を行っている時点でメモリとしては極めて状態的なんだよな
ただそのメモリ上表現が純粋関数で得られたものであるという保証があるから成り立っているし、そうでないものはモナドで順序性を保証してるから問題が出ない

**デフォルトの名無しさん** · 2018/09/15(土) 23:24:47.82

モナドで順序性の保証って別に言語実装が保証してるわけじゃないがな。
あくまでモナド実装者が保証するべきものであって。

**デフォルトの名無しさん** · 2018/09/15(土) 23:26:31.34

Rustの副作用の取り扱いの問題って何だ？

所有権移動に関する話で、
いわゆる関数型の副作用とは別の話をしているようにも見える

**デフォルトの名無しさん** · 2018/09/16(日) 00:44:17.96

単純に見た目だけじゃmoveかcopyかわからないって話じゃない？
何かのコンテナ型を自分で実装する時、とりあえず中身にi32を入れて書いて後でジェネリクスにしよう、とかやってると
ボローチェッカにしこたま怒られることがある。見直すと9割が設計ミス

**デフォルトの名無しさん** · 2018/09/16(日) 00:59:06.26

有名な純粋関数型言語といえど遅延評価による最適化は状態的という話なので言い回しの緩さは許してくれ

noioやnoheapなんかはそれこそHaskellではIOモナドやSTモナドで包んで明示してる訳だよな

**デフォルトの名無しさん** · 2018/09/16(日) 08:48:36.18

copyと参照の違いはwriteすれば分かるが、副作用がなかったら違いを知る必要がない
copyとmoveの違いはreadすれば分かるので副作用がなくても違いが分かる

**デフォルトの名無しさん** · 2018/09/16(日) 09:42:39.79

Rustのmoveは確かにイマイチ

ローカル変数は = でmove出来るが
構造体フィールドは = では不可なためmem::replaceを使う
ライフタイムの違いによるものとはいえ記述の一貫性に欠ける

この点はC++のstd::moveの方が一貫性がある

**デフォルトの名無しさん** · 2018/09/16(日) 10:35:29.39

具体例が無いのも何なので一応

RustとC++コード例 >>113での要点はfooの中身
https://ideone.com/jo5Ymj
https://ideone.com/JIAr9h

**デフォルトの名無しさん** · 2018/09/16(日) 17:04:17.35

>>113, >>114
構造体のフィールドはmove出来ちゃまずいから
この場合はむしろC++のコンパイルが通ってることが問題だよ

記述の一貫性のためだけに未定義動作の危険性を許しちゃダメでしょ

**デフォルトの名無しさん** · 2018/09/16(日) 18:21:37.55

Rustの構造体 T のフィールドはmoveできる
&mut T は全体のmoveもフィールドのmoveもできないがreplaceならできる

**デフォルトの名無しさん** · 2018/09/16(日) 18:24:03.24

>>115
このコードに問題も未定義動作も無いぞ
unique_ptrのムーブコンストラクタにより適切に所有権が移動される

**デフォルトの名無しさん** · 2018/09/16(日) 20:39:05.75

>>116
すまん言葉足らずだった
Rustに関してはその通りだよ
でもC++はRustみたいに強力なボローチェッカーがないからmoveはまずい

>>117
そのコードは確かに未定義動作は起こさない
でも未定義動作を起こす危険性を含む
C++の方のfooメソッドの最後の一行をコメントアウトしても
コンパイルが通ってしまうって言えば何が危険か分かるよね
それを防ぐためにはC++の方もreplaceでなきゃダメ

**デフォルトの名無しさん** · 2018/09/16(日) 21:15:13.47

>C++の方のfooメソッドの最後の一行をコメントアウトしても
>コンパイルが通ってしまうって言えば何が危険か分かるよね

俺よくわからないんで解説plz

**デフォルトの名無しさん** · 2018/09/16(日) 21:18:37.65

>>118
fooの最後の一行をコメントアウトしても何も危険は無いんだが
C++のムーブセマンティクスの動作や仕様を理解出来てないんじゃないか？

**デフォルトの名無しさん** · 2018/09/16(日) 21:32:49.26

もしかしてmoveされた側が不定値にでもなると勘違いしてるのかね

**デフォルトの名無しさん** · 2018/09/16(日) 22:03:54.40

rustのmoveが分かりにくいという主旨だと思っていたけど違うのかな？

moveかcopyか分からんてのは確かにだけどプリミティブ型はcopyされると覚えるだけでよくない
しかしなぜプリミティブはcopyのコストを受け入れてよいことになっているの？

**デフォルトの名無しさん** · 2018/09/16(日) 22:31:43.85

>>121
すまん。俺の間違いだった。
move後はnullptrになる事が保証されてることを今知った
今までずっと未定義だと思ってた
(てか会社の先輩にそう教わったんだあの野郎デタラメ教えやがって)
俺の勘違いでした m(__)m

**デフォルトの名無しさん** · 2018/09/16(日) 22:36:54.71

>>123
マニュアルくらい読めよ
https://doc.rust-jp.rs/book/second-edition/

**デフォルトの名無しさん** · 2018/09/16(日) 22:43:00.14

てか軽くググってみても「move後は未定義」って書いてあるサイトが
チラホラ存在するんだが…めっちゃ紛らわしい

>>124
Rustの公式マニュアルは読んどるわ
問題はC++の方だよ
公式のマニュアルは無いわ
ネットの情報は(偽情報含めて)多すぎるわで
まんまと踊らされたわ

**デフォルトの名無しさん** · 2018/09/16(日) 23:28:36.73

後にデストラクタが動くということを考えたら未定義になるわけないし
そこがC++のmoveのイマイチなとこでもある

**デフォルトの名無しさん** · 2018/09/16(日) 23:34:24.03

ここ読んでるとrustはめんどくさそう

**デフォルトの名無しさん** · 2018/09/16(日) 23:37:09.77

めんどくさいのはrustというよりrust信者だけどな。

**デフォルトの名無しさん** · 2018/09/16(日) 23:50:37.70

C++はコンストラクタが複雑過ぎる
Rustにはコンストラクタがない代わりに初期化前やmove後の変な状態がある

**デフォルトの名無しさん** · 2018/09/17(月) 02:01:59.79

実際のところrust使いは満足してるの？

**デフォルトの名無しさん** · 2018/09/17(月) 04:53:12.24

結局の所、その言語によるコードの書き方にメリットを感じる人間がどれ位いるのか、
が重要なわけか

**デフォルトの名無しさん** · 2018/09/17(月) 09:34:55.97

お前ら次スレは
次世代言語15 Rust Rust Rust Rust Rust
にしなさいね

**デフォルトの名無しさん** · 2018/09/17(月) 09:42:03.98

>>129
右辺値参照やconst修飾などの、型の仕様/関数全般の仕様まで一緒くたにしてないか
コンストラクタ自体には大して複雑な仕様は無いと思うけどな
RAIIの理解が要るくらいで

**デフォルトの名無しさん** · 2018/09/17(月) 10:11:10.46

結局の所、メリットを感じる人間ではなく
複雑さのコストを感じない人間が最強なわけよ
ライオンは科学的な練習とかしなくても強い

**デフォルトの名無しさん** · 2018/09/17(月) 10:31:45.23

そういった思想からメンテ不可なゴミコードが生成されるんだと思うよ。

**デフォルトの名無しさん** · 2018/09/17(月) 10:47:39.16

では具体的にはC++処理系とD言語処理系はどっちがメンテ不可のゴミコードになるのかね

**デフォルトの名無しさん** · 2018/09/17(月) 10:49:13.60

バカが書けばどっちもゴミコード

**デフォルトの名無しさん** · 2018/09/17(月) 11:01:37.27

>>136
言語の問題でなくて
>複雑さのコストを感じない人間が最強なわけよ
こういうカス思想の問題だと言ってるんだが。

**デフォルトの名無しさん** · 2018/09/17(月) 11:15:08.74

コストとリスクと不確実性を区別したら面白そう
コストには敏感なくせに不確実性は想定外とかいうカス思想

**デフォルトの名無しさん** · 2018/09/17(月) 11:17:12.97

メンテだけに関して言えばC++の方が闇深コードは生まれやすそう

**デフォルトの名無しさん** · 2018/09/17(月) 11:17:23.87

いまだにpython2使ってそう

**デフォルトの名無しさん** · 2018/09/17(月) 11:26:05.14

C++は闇の作りやすさが問題なんだよな

**デフォルトの名無しさん** · 2018/09/17(月) 11:31:21.72

C++は俺すげぇ感を刺激することに関しては最高

**デフォルトの名無しさん** · 2018/09/17(月) 11:31:24.02

C++は本人以外理解できないコードが容易にできてしまうからなぁ。

Type a = b;

たったこれだけのコードがどんな動作するのか、Typeやbの定義を
隅から隅まで調べないと特定できない。

**デフォルトの名無しさん** · 2018/09/17(月) 11:41:36.65

C++も "Trust the programmer" の思想だしな

**デフォルトの名無しさん** · 2018/09/17(月) 11:51:14.52

>>134
俺はすでにライオンに生まれてないんですけどどうしたらいいのかと

冗談はさておきjavaはscalaで置き換えらえると言ってた人達は死んだんだろうな

**デフォルトの名無しさん** · 2018/09/17(月) 11:54:34.26

innullable対応jreが出れば満足です

**デフォルトの名無しさん** · 2018/09/17(月) 11:54:59.33

次の問題はJavaはKotolinで置き換えられるか？だな
どう思うよ？

**デフォルトの名無しさん** · 2018/09/17(月) 11:57:07.56

>>148
Kotolin -> Kotlin

**デフォルトの名無しさん** · 2018/09/17(月) 11:57:10.80

>>148
javaはgolangで置き換えられると真面目に思ってる

**デフォルトの名無しさん** · 2018/09/17(月) 12:15:52.87

>>148
今はJavaにも型推論やラムダ入っていること
Java(API)訴訟、モバイルのクロスプラットフォーム台頭
OracleJDKからの移行などの影響で鈍化したと思う

**デフォルトの名無しさん** · 2018/09/17(月) 12:23:44.22

>>150
Goに糞コードが増えるのも困るなぁ

**デフォルトの名無しさん** · 2018/09/17(月) 12:33:15.47

プログラマーを少しは信じろよ

**デフォルトの名無しさん** · 2018/09/17(月) 12:42:27.85

Javaの後継となるとねえ

**デフォルトの名無しさん** · 2018/09/17(月) 12:45:36.97

Pythonはもうダメかも知れんね

【IT】奴隷制を連想させるとして、Pythonで「master」「slave」といった単語が削除される
https://egg.5ch.net/test/read.cgi/bizplus/1536925223/

**デフォルトの名無しさん** · 2018/09/17(月) 12:53:00.77

他の言語にも触れてみる

Swift
型推論周りのビルド速度どうにかしろ
所有権と並行入れる予定でABI安定化とかマジで出来るんですかね

Kotlin
JVM界隈はアレな状況だからKotlin/Nativeをはよ完成させて

Dart2
大企業パワーによるエコシステムでの持ち上げ半端ない

C#
堅実な改良重ねるのは評価出来るけど
Windows Phone死んで草
Monoプロジェクトのおかげでプラットフォーム戦続けられて良かったな

JVM/.NET/DartVMとかでライブラリの相互利用出来なさすぎ
Haxeのクロスプラットフォーム思想(だけ)見習って欲しい

**デフォルトの名無しさん** · 2018/09/17(月) 12:54:01.58

jvmの更新で動作がどうなるか不安なjavaはもうダメだろ。
goに取って代わるかは知らんが環境べったりなシステムはもう流行らん。

**デフォルトの名無しさん** · 2018/09/17(月) 15:26:52.07

ここでATS2やってる人軒並み難しいって言ってるし俺も実際そう思うんだけど、ただでさえ難しい言語機能に加えてATS2のシンタックスが難しさを加速してるイメージあるの俺だけ？

**デフォルトの名無しさん** · 2018/09/17(月) 16:47:49.21

ABI安定化は永遠にこないだろう
名前恰好つけてるけどようするにVMだかなんだかの後方互換性を将来にわたって約束しますってことだろ

そんなん今後守れますって宣言できるわけないじゃん
思い付きでぶち上げて宙ぶらりんになってるだけでは

**デフォルトの名無しさん** · 2018/09/17(月) 17:46:42.97

>>155
Kotlin Nativeが完成さえすれば…！
C#なぞ軽く超えるんじゃないかとボケ夢を見てるが

**デフォルトの名無しさん** · 2018/09/17(月) 17:54:29.17

でもgcあるんでしょ

**デフォルトの名無しさん** · 2018/09/17(月) 23:01:26.71

>>134
おまえはやっぱりおかしい

**デフォルトの名無しさん** · 2018/09/18(火) 01:49:10.44

>>155
PerlはおかしいからってPythonに置き換え始めた時からずっと同じことをやってるだけだ

**デフォルトの名無しさん** · 2018/09/18(火) 03:24:29.62

Javaというよりオブジェクト指向が死んで欲しい

**デフォルトの名無しさん** · 2018/09/18(火) 04:19:43.79

そもそもオブジェクト指向ってコードを当時バリバリに書いてた人らが、
リファクタリングテクニックやイズムを行使する傍らで自然発生的にでてきたものだろ
その後色々と他の物がくっついただけで

**デフォルトの名無しさん** · 2018/09/18(火) 07:10:49.01

あればあったで使ったら便利な時に使うし
使うこと自体が目的になるようなら避ければいいだけ
例えばデザインパターンを無理やり当てはめない

**デフォルトの名無しさん** · 2018/09/18(火) 11:51:33.93

>>165
思い込みで歴史捏造するやつw

**デフォルトの名無しさん** · 2018/09/18(火) 12:01:34.65

そもそもオブジェクト指向の定義が曖昧すぎるんだよ
オブジェクト指向が何かを正確に言語化できる人なんているの？
いたら俺にオブジェクト指向の正確な定義を教えてほしい

**デフォルトの名無しさん** · 2018/09/18(火) 12:15:12.24

>>168
オブジェクトの定義が曖昧なんであってオブジェクト指向は複雑なだけじゃない？
具体的にこれがオブジェクト指向だって言ってもシングルトンとかのデザインパターンは複数も複合もあるから
じゃあこれはオブジェクト指向じゃないのか？と全て一概には言えん

ただオブジェクト指向はクソだ

**デフォルトの名無しさん** · 2018/09/18(火) 12:28:36.59

オブジェクト指向いいじゃん
クソなのはORMとカプセル化だよ

**デフォルトの名無しさん** · 2018/09/18(火) 12:29:37.73

GUIはOOPじゃないと辛くね？

**デフォルトの名無しさん** · 2018/09/18(火) 12:31:12.61

>>170
ORMの何がクソなのさ

**デフォルトの名無しさん** · 2018/09/18(火) 13:11:34.36

>>168
やっぱりおまえはおかしいし

**デフォルトの名無しさん** · 2018/09/18(火) 13:25:46.61

>>171
そのGUIでブラウザを作る言語はJavaとRustどっちがマシなのか