次世代言語18 V Julia 他

**デフォルトの名無しさん** · 2019/09/30(月) 23:11:51.54

スレタイ以外の言語もok

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

**デフォルトの名無しさん** · 2019/10/17(木) 12:46:04.07

「SIerの現場で使われてないから実際のものづくりに役に立ってない」という主張の非論理性

**デフォルトの名無しさん** · 2019/10/17(木) 13:05:26.93

>>681
Kotlinはそうでもないだろ
C#系を真似し終えてからは思いつきで機能追加しまくってて評判も悪くて完全にScalaコースだよ

**デフォルトの名無しさん** · 2019/10/17(木) 13:15:39.16

SIerはAWSより役に立ってるから……（震え声）

**デフォルトの名無しさん** · 2019/10/17(木) 14:19:06.42

次世代言語スレなのだから、いま流行ってるかとか役に立ってるかとかではなく、今後そうなるか(なれるか)を話した方が建設的でないか？

**デフォルトの名無しさん** · 2019/10/17(木) 14:34:17.46

知見のある奴はこんな掃き溜めに来ないから無理だよ
建設的な事よりマウント取ることに全力を尽くしたい

**デフォルトの名無しさん** · 2019/10/17(木) 14:43:02.48

そもそもここ次世代言語アンチスレだから

**デフォルトの名無しさん** · 2019/10/17(木) 14:55:51.58

Kotlinそんなに評判悪いん？

**デフォルトの名無しさん** · 2019/10/17(木) 15:20:37.28

Kotlin は Coroutine 以外は地味で渋めな機能拡張しかしてなくね？
C#系を真似したというのも意味がよくわからんが

**デフォルトの名無しさん** · 2019/10/17(木) 15:52:25.80

遊び人のから排除したプログラミング言語ってビャーネストロヴストルップの功績馬鹿にしてるだろ

**デフォルトの名無しさん** · 2019/10/17(木) 16:07:38.90

ここは言語スレだけど、Kotlinは標準のクラスライブラリをもっとリッチにしてくれないと。マルチプラットホーム目指すなら特に。

俺のなかじゃ評価するとき、言語+標準のクラスライブラリのセットで考える

**デフォルトの名無しさん** · 2019/10/17(木) 16:11:39.54

null safetyだって、kotlinでjava apiとか呼ぶ機会多すぎてせっかくのnull safetyが...
kotlin nativeとかあるがクラスライブリが貧弱なのは寄生言語の限界か？

**デフォルトの名無しさん** · 2019/10/17(木) 17:05:52.83

初期KotlinがJava標準ライブラリの存在を前提に作られていて
マルチプラットフォーム仕様が後付けなのでライブラリが貧弱

**デフォルトの名無しさん** · 2019/10/17(木) 17:17:41.34

Java 側にアノテーションついていれば、Kotlin の null safety に反映される
Android SDK はアノテーションつきまくりだから、役に立ってる

**デフォルトの名無しさん** · 2019/10/17(木) 18:07:16.91

>>686
遊びたくなる要素満載だろ。てかドヤりたくなる要素満載。
ただそれだけ。

**デフォルトの名無しさん** · 2019/10/17(木) 18:11:11.03

従来からのセオリーに反して新しい言語に手を出す時点で遊びでありドヤである

**デフォルトの名無しさん** · 2019/10/17(木) 18:16:27.34

>>700
おま中

**デフォルトの名無しさん** · 2019/10/17(木) 18:36:29.14

言語設計者本人の著書とか読むと意図や道理が分かるけど
やる奴はそういうの関係無しに何でも遊び道具にする

**デフォルトの名無しさん** · 2019/10/17(木) 19:03:11.49

KotlinさえできればJavaなんか覚えなくてもいい
↓
↑
Java覚えないとKotlinできることにならない

**デフォルトの名無しさん** · 2019/10/17(木) 19:24:50.33

Rustに遊ぶ余地がないとは言わんが、C++の遊ぶ余地と比べたら屁でもないよ

**デフォルトの名無しさん** · 2019/10/17(木) 19:25:38.94

>>700
満載とまで言うのなら教えて欲しい
Rustでドヤれる要素なんてあるかなぁ？
質素で面白みのない言語だと思うけど
パターンマッチも貧相だしねえ

**デフォルトの名無しさん** · 2019/10/17(木) 19:43:37.53

>>706
「トーシロにはコンパイル通せないだろうなあ、俺には通せるけどね（どや顔）」な奴は見たことある
普通に無能だったが

**デフォルトの名無しさん** · 2019/10/17(木) 19:47:25.67

と無能。

**デフォルトの名無しさん** · 2019/10/17(木) 19:47:37.90

AWSでRustサポート開始
https://news.mynavi.jp/article/20191016-910489/

**デフォルトの名無しさん** · 2019/10/17(木) 19:50:07.02

>>709
違う
ソース読めばわかるが、「AWSでRustがサポートされる」のではなく、「AWSがRustを支援することにした」だ

**デフォルトの名無しさん** · 2019/10/17(木) 19:54:13.82

この世のC言語/C++のライブラリが全てRustで書き直されてLinuxもRustで書き直されたら天下取れるのになあ
夢物語だけど

**デフォルトの名無しさん** · 2019/10/17(木) 20:05:14.96

さすがに本気出したＣ＋＋には速度で負ける模様

**デフォルトの名無しさん** · 2019/10/17(木) 20:11:27.12

LinuxはCだが？C++の本気とかちゃんちゃらおかしい。

**デフォルトの名無しさん** · 2019/10/17(木) 20:36:42.15

ほんとお前らみたいな馬鹿ってC++が嫌いだよなｗ

**デフォルトの名無しさん** · 2019/10/17(木) 20:39:51.36

今更、Rustに書き直すとか馬鹿だろ

**デフォルトの名無しさん** · 2019/10/17(木) 22:34:30.43

こないだ出たsudoのしょーもないバグも｢整数値-1を無効値として扱う｣みたいなんじゃなくちゃんと｢無効を表す値｣が存在する最近の言語ならそもそも回避できたのにな
今普通に動いてる既存の物ってのはそれだけで強いよなぁ

**デフォルトの名無しさん** · 2019/10/17(木) 23:40:54.35

>>716
バカはおまえだ。
内部的には何らかのビット列をわりあてることになるんだよ。
その選び方は性能にはっきり影響する。

**デフォルトの名無しさん** · 2019/10/17(木) 23:52:32.65

型さえあれば救われたのに

**デフォルトの名無しさん** · 2019/10/18(金) 00:01:46.17

老害イラッイラで草

**デフォルトの名無しさん** · 2019/10/18(金) 00:15:16.52

型ゆえに人は苦しまねばならぬ
型ゆえに人は悲しまねばならぬ

こんなに苦しいのなら
こんなに悲しいのなら
型などいらぬ！！！

**デフォルトの名無しさん** · 2019/10/18(金) 00:24:55.92

>>720
はいランタイムエラー

**デフォルトの名無しさん** · 2019/10/18(金) 00:47:51.11

人はそれを脆弱性と呼ぶ

**デフォルトの名無しさん** · 2019/10/18(金) 00:56:05.28

やはりＲｕｓｔの時代か

**デフォルトの名無しさん** · 2019/10/18(金) 04:11:17.15

>>711
全て書き換えるのは夢物語だが、
Linuxを書き換えるくらいならおまい個人でもできるだろ
頑張れ！

**デフォルトの名無しさん** · 2019/10/18(金) 04:18:44.11

大学か大学院に入り直したい
同じことの繰り返しに飽きた

**デフォルトの名無しさん** · 2019/10/18(金) 04:38:32.95

起業すれば

**デフォルトの名無しさん** · 2019/10/18(金) 10:25:44.63

>>710
なるほど
チャイナマネーぶちこんで、Rustでビルドしたプログラムには
自動的にバックドアが仕込まれるか
勝手に情報を中国政府所有のサーバに送りつけるかするってことか

**デフォルトの名無しさん** · 2019/10/18(金) 11:06:47.57

糖質も見てます

**デフォルトの名無しさん** · 2019/10/18(金) 15:36:43.09

モナドの使い方がお前らには見えていないのを見たぞ
これ半分アルミホイルだろ

**デフォルトの名無しさん** · 2019/10/18(金) 20:30:58.03

雑なの承知で書くけど
null safeやリストへのmap/flatMapの便利さが何となく分かったなら
モナド大体分かったということでOK

**デフォルトの名無しさん** · 2019/10/18(金) 21:16:13.30

IOモナドはどう理解すればいいの？

**デフォルトの名無しさん** · 2019/10/18(金) 21:55:39.27

>>73
mapはわかるがflatmapはわからんな

**デフォルトの名無しさん** · 2019/10/18(金) 21:58:53.77

mapの良さは分かるけどモナドが理解できた勢に加わりたくない

**デフォルトの名無しさん** · 2019/10/18(金) 22:06:39.93

あれLispのとどうちがうんだ

**デフォルトの名無しさん** · 2019/10/18(金) 23:00:00.81

JSのflatMapはmapと違って配列自身を返せるから
次のメソッドチェーンの処理をより柔軟にできるぐらいしか使い所がない気がする

**デフォルトの名無しさん** · 2019/10/18(金) 23:00:56.75

バカはどんな言語実装になろうと決して他人のコード読まんのだよ。
だから言語を変えれば解決するとか馬鹿の妄想なのだ。

**デフォルトの名無しさん** · 2019/10/18(金) 23:04:17.96

>>731,732
どっちも型合わせ以上の意味はない。

**デフォルトの名無しさん** · 2019/10/18(金) 23:45:28.18

関数のcomposability(合成可能性)を高めるために
モノイド、ファンクタ、モナドなんかの型クラスがある

モノイド = appendable
ファンクタ = mappable
モナド = flatmappable

↓この説明が過去見た中では一番わかりやすい
http://adit.io/posts/2013-04-17-functors,_applicatives,_and_monads_in_pictures.html

**デフォルトの名無しさん** · 2019/10/18(金) 23:47:21.40

>>731
理解しなくてOK
純粋関数型を好きになる日がもし来たらそのとき大体の先を考えよう

**デフォルトの名無しさん** · 2019/10/18(金) 23:56:52.67

物事には順序があって、順序の基には段階や必要性があるわけで
つまり初手ラスボス配置はよくない

**デフォルトの名無しさん** · 2019/10/19(土) 00:23:04.53

>>738
そういう説明はだいたい理解した最後に頭の整理するために読むものなんだよ
わかってない人に無意味

**デフォルトの名無しさん** · 2019/10/19(土) 00:30:41.62

>>731
worldを隠したいという動機があってそれをうまく実現する体系がモナド
こういうふうに問題解決のストーリーで理解していくとわかる
合成可能性とかはその結果なので最初は忘れていい

**デフォルトの名無しさん** · 2019/10/19(土) 01:08:13.73

>>651
Android開発というキラーアプリがあるし
InteliJのインテリセンスがﾏｼﾞ優秀やし

**デフォルトの名無しさん** · 2019/10/19(土) 01:34:27.34

>>738
サンキュー
Haskell には Maybe というものがあるぐらいしか知らんので、
もやもやーってしか理解してなかったけど大体分かった
（使ってみろと言われてもすぐにはできないだろうけど）

苦労してゆっくり英語とコード読んだ後、最後尾に日本語訳へのリンクあって草

**デフォルトの名無しさん** · 2019/10/19(土) 02:02:29.47

>>743
Java は Android なんか無い頃から SIer 御用達だったんや
開発環境はだいたい Eclips

**デフォルトの名無しさん** · 2019/10/19(土) 02:03:53.22

flatMap の初歩的な使い方といえばこれ
map が返すのは適用する関数が成功したも結果もエラーの結果も全部入った配列になるけど、flatMap なら適用する関数が成功した結果だけが入った配列を返すようにできる
その場合の flatMap で適用する関数は、成功時には結果が一個入った配列を、エラー時には要素0個の配列を返すようにする

**デフォルトの名無しさん** · 2019/10/19(土) 07:27:33.50

それってfilterでやればよくね？
つーかモナドモンスターは成仏してくれ

**デフォルトの名無しさん** · 2019/10/19(土) 07:39:01.77

他の方法挙げたら切りが無いと思うけど
for文で駄目なわけじゃないし

少し読みやすい（慣れによる）、少し短い、少し速いとか
道具の使い分けなんてそんなもん

**デフォルトの名無しさん** · 2019/10/19(土) 07:47:59.52

そんなもんて言うけどその少しが大事だろ

**デフォルトの名無しさん** · 2019/10/19(土) 08:01:53.19

いくつかの言語が備えている例外機構の真逆の仕組みがモナドよな

**デフォルトの名無しさん** · 2019/10/19(土) 08:34:08.79

>>749
「～でよくね」はその少しを気しない（使い分けない）方の表現では？

**デフォルトの名無しさん** · 2019/10/19(土) 08:58:11.03

flatmapがモナドとか言ってる奴何一つ型を分かってない
flatmapはモナドのbindを拡張した概念であって、bindそのものじゃない
要するにflatmapが使える時点でモナドじゃない、モナドのような何かだ
それをモナドと混同してる時点で論外
そいつの話を聞く必要はない

**デフォルトの名無しさん** · 2019/10/19(土) 09:36:17.45

＞要するにflatmapが使える時点でモナドじゃない、モナドのような何かだ
自分がなにもわかってないっていう自己紹介かな

「モナドとして振る舞える」ものはモナドだよ
モナドよりできることが多かったとしても

**デフォルトの名無しさん** · 2019/10/19(土) 10:16:08.33

モナド警察現るw
モナド = bindableでもいいけどbindって何？ってなるだろ
flatmapはmapの続きで理解できるからbindって言葉よりも理解しやすい

Optional<T>を例にすると
mapはOptional<T> -> ( T -> U ) -> Optional
Optional<T>とTをUに変換する関数を受け取ってOptionalを返す

flatmapはOptional<T> -> ( T -> Optional ) -> Optional
Optional<T>とTをOptionalに変換する関数を受け取ってOptionalを返す

mapの場合、受け取る関数が( T -> Optional )だと結果がOptional<Optional>になって二重に包まれる
flatmapはこういう二重に包まれた結果にならないようmapする機能とネストした型をflattenする機能が合体したもの

IOやStateには当てはまらないとかいう奴も居るけど
mapだとIO<IO<T>>になるところをflattenしてIO<T>にするのは同じ
flattenするルールが包みの種類によって違うだけ

**デフォルトの名無しさん** · 2019/10/19(土) 10:28:11.66

まあこうなるからモナドを再利用するより再発明した方が話が早い
過去の発明と「混同」すべきでないと警察に指摘されても何も問題ない
また俺なんか新発明しちゃいましたか？
それだけの話

**デフォルトの名無しさん** · 2019/10/19(土) 10:33:43.56

序盤中盤 >>730
ラストダンジョン >>752-754

**デフォルトの名無しさん** · 2019/10/19(土) 10:46:34.37

flatmapは何がうれしいのかというと

例えば
1. ファイルを開いて
2. 内容をテキストとして読んで
3. パースしてJSONに変換する
とした場合、

3つとも何らかの要因でエラーが発生しうるから
それぞれ結果がエラーが発生するかもしれないというコンテキスト(EitherとかResultと呼ばれるもの)で包まれる
open: FilePath -> Result<File, Error>
read: File -> Result<Text, Error>
parse: Text -> Result<Json, Error>

でそれらの処理をつなげた場合に3重に包まれた結果じゃなく
最終的なflattenされたResult<Json, Error>を返すようにするために使うのがflatmap

mapはコンテキストを引き継ぎながら中身に関数を適用する
flatmapはそれに加えてコンテキストがネストしないようflattenしてくれる
それによって合成できる関数のパターンが増えてシンプルに処理を書けるようになる

というのが俺の理解

**デフォルトの名無しさん** · 2019/10/19(土) 10:55:13.52

結局わからん
オプショナルと任意の関数と関数適用する方法とマップ関数があって
どれがどこまでモナドなん？

**デフォルトの名無しさん** · 2019/10/19(土) 11:31:51.65

モナドは、いつもお前達の心の中に

**デフォルトの名無しさん** · 2019/10/19(土) 11:51:16.95

キミはキミ自身のモナドを見つけなければならない

**デフォルトの名無しさん** · 2019/10/19(土) 11:53:37.69

C++嫌いな人はRustなんかよりGoへ逝けば良いのに

**デフォルトの名無しさん** · 2019/10/19(土) 12:20:09.69

goは言語マニアのプライドを満たさないので嫌なんだとさ。

**デフォルトの名無しさん** · 2019/10/19(土) 13:07:15.02

GCの存在が前提のGoはC++の代替にはならない

**デフォルトの名無しさん** · 2019/10/19(土) 13:07:39.41

マニアの心をすべて読むことはできない
できると思ってる奴はモンスターだし
できない要素を排除すれば消去法でできると思ってる奴もモンスターだ

**デフォルトの名無しさん** · 2019/10/19(土) 13:14:05.47

C++の代替ならDもありますよ

**デフォルトの名無しさん** · 2019/10/19(土) 13:26:35.49

スレタイのVはどうした

**デフォルトの名無しさん** · 2019/10/19(土) 13:30:03.22

>>758
OptionalやResultがモナド

**デフォルトの名無しさん** · 2019/10/19(土) 13:47:36.04

Vは詐欺だから。

**デフォルトの名無しさん** · 2019/10/19(土) 14:21:06.55

もし被害者がいたらね
いなかったらトロッコ問題をもっと簡単にしたような問題

**デフォルトの名無しさん** · 2019/10/19(土) 16:56:06.90

>>761
そもそもC/C++自体がすでに第一選択の言語じゃなくて、応答性やパフォーマンスの問題で消去法で選ばれる言語だし、
Goはそれで弾かれる側の言語なんで無理無理

Goが選択肢に入るような要件ならC++は選択肢に入らないし、逆もまた然り

**デフォルトの名無しさん** · 2019/10/19(土) 17:20:33.83

>>751
たしかに
filterがよくね？が正しかったわ
そもそもエラー無視すんなよと思うけど

**デフォルトの名無しさん** · 2019/10/19(土) 17:48:35.99

で、応答性やパフォーマンスの問題になるようなコードを書いてない輩が
ドヤるために馬鹿言いだしてるという現状。

**デフォルトの名無しさん** · 2019/10/19(土) 17:53:30.96

こいつにとっての世界は5chだけなんだろうな……

**デフォルトの名無しさん** · 2019/10/19(土) 18:21:42.30

>>772
Goなんて寝言言ってないで、実用性マックス型無し糞言語汚物PHPを保守する作業に戻るんだ

**デフォルトの名無しさん** · 2019/10/19(土) 18:28:50.17

ネイティブアプリなら今でもC++が第一の選択肢なんだよなあ

**デフォルトの名無しさん** · 2019/10/19(土) 18:51:26.98

GoはJavaの代替品のイメージだな、WEB系だと

**デフォルトの名無しさん** · 2019/10/19(土) 19:08:40.00

C++だってガベージコレクタを実装したり、light weight threadを実装して
Goと同じようなことができるもん！

**デフォルトの名無しさん** · 2019/10/19(土) 19:11:11.25

作ればあるもん！

**デフォルトの名無しさん** · 2019/10/19(土) 19:12:46.30

C++もがんばれば高階関数だって書けるもん！

**デフォルトの名無しさん** · 2019/10/19(土) 21:14:27.31

WEBプログラマーみたいな最下層のプログラマーが兎や角言ってもな

**デフォルトの名無しさん** · 2019/10/19(土) 21:21:26.37

ふむ・・・ではCでガーベジコーレクションを実装してみてはどうだろうか？

**デフォルトの名無しさん** · 2019/10/19(土) 21:23:34.19

SIerにいる人って実年齢より老けて見えるよな
無駄なストレス溜まってて可哀想

**デフォルトの名無しさん** · 2019/10/19(土) 21:32:32.75

お前らの社畜スキルの議論はどうでもいいけどさ、個人で作ったアプリはないの？w

**デフォルトの名無しさん** · 2019/10/19(土) 21:39:01.20

>>782
多分ここにいるのそういう人たちだと思う
SIerとか一生客にマウントとられる仕事だし
技術力はつかないし
まともな技術者は絶対やめる

**デフォルトの名無しさん** · 2019/10/19(土) 21:40:49.31

おまいらってSIerの話題とPHPの話題にだけは食いつきいいよな

　つ　ま　り

**デフォルトの名無しさん** · 2019/10/19(土) 21:43:26.62

みんなSIer！！