次世代言語9[Haskell Rust Kotlin TypeScript Dart]

**デフォルトの名無しさん** · 2018/03/06(火) 10:09:15.60

スレタイ以外の言語もok

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

**デフォルトの名無しさん** · 2018/04/03(火) 12:54:09.54

いい加減スレタイからRustはずそうぜ

**デフォルトの名無しさん** · 2018/04/03(火) 14:02:58.92

つか、スレタイから次世代言語をはずした方がいいんじゃね。
旧世代の言語の話しか出てこないし。

**デフォルトの名無しさん** · 2018/04/03(火) 14:19:06.58

>>730
次世代を語るためには旧世代を知っておかねばならんのだ（ｷﾘｯ

**デフォルトの名無しさん** · 2018/04/03(火) 14:58:56.73

おんこちしんと
うんこちんちん
似てる

**デフォルトの名無しさん** · 2018/04/03(火) 16:29:09.56

>>729
C++のポジションを狙う言語には「なんなんだよこの仕様＝うっとうしい」もついてくるからｗ

**デフォルトの名無しさん** · 2018/04/03(火) 17:41:10.26

>>733
C++のポジションを狙うRustには「なんなんだよこのアンチ=うっとうしい」もついてくるからw

**デフォルトの名無しさん** · 2018/04/03(火) 18:01:19.06

ネタにしてるが、マジで旧世代言語知らずに次世代なんて語れんだろう。

**デフォルトの名無しさん** · 2018/04/03(火) 19:42:11.24

そもそも次世代言語ってまだない言語を夢想して話せってこと？無茶いうな

**デフォルトの名無しさん** · 2018/04/03(火) 19:48:53.79

あのアンチはRustに職を奪われたからね、しょうがないね
Rustスレで気持ちよく大暴れしてるときに自分で漏らしてたよ

**デフォルトの名無しさん** · 2018/04/03(火) 20:16:15.66

なんでこんなrust普及の妨げにしかならんこと言いだすんだろう。

**デフォルトの名無しさん** · 2018/04/03(火) 20:27:21.10

UE4やHoudini使ってると次世代言語はビジュアルプログラミングでいい気がしてきた

**デフォルトの名無しさん** · 2018/04/03(火) 20:33:03.03

Rustは次世代言語だがC++知ってた人と今から勉強始める人の格差はリセットされないな
世代交代とは寿命が尽きることであって格差がなくなることではない

**デフォルトの名無しさん** · 2018/04/03(火) 20:44:15.49

>>739
MSは何故GUIエディタを放棄してXAMLなんぞ作ったんだろうか……

**デフォルトの名無しさん** · 2018/04/03(火) 21:06:26.14

XAMLはまだBlendで書けるだろ。

**デフォルトの名無しさん** · 2018/04/03(火) 21:10:07.12

XAMLを手書きしてる人なんているか？

**デフォルトの名無しさん** · 2018/04/03(火) 21:27:57.24

Xamarinの人たちかな。

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

補完ありのテキストエディタならいくらでもいそうな気がするが。

**デフォルトの名無しさん** · 2018/04/03(火) 23:12:30.59

Delphi「やっと時代が追い付いたか」

**デフォルトの名無しさん** · 2018/04/04(水) 00:44:22.36

>>739
じゃあdiff取ってみろ。
テキストを超える記述方法は無いよね。

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

Kylix「誰も知らない知られちゃいけない」

**デフォルトの名無しさん** · 2018/04/04(水) 17:04:36.07

deっvi---l

**デフォルトの名無しさん** · 2018/04/04(水) 17:31:20.15

まあVBの方が古いんだけどな

**デフォルトの名無しさん** · 2018/04/07(土) 09:53:55.09

>>739
同意
テキストよりビジュアルの方が人間の頭脳に優しい

**デフォルトの名無しさん** · 2018/04/07(土) 12:37:16.42

Goの案件って結構あるのね

**デフォルトの名無しさん** · 2018/04/07(土) 12:55:34.16

Goみたいな不安定なものよく使うな

**デフォルトの名無しさん** · 2018/04/07(土) 13:26:35.73

Cはグローバル変数の使い方やOOPのやり方みたいなローカルルールないと無理っぽい
Cがいくら安定してもローカルルールは安定しない

**デフォルトの名無しさん** · 2018/04/07(土) 13:43:27.23

流石にひどいw

**デフォルトの名無しさん** · 2018/04/07(土) 16:18:41.57

>>752
まじでー。普通のcrudなweb案件とかもあるならやってみたい

**デフォルトの名無しさん** · 2018/04/07(土) 17:28:50.26

どこが不安定なんだろ？

**デフォルトの名無しさん** · 2018/04/07(土) 18:15:56.12

小学校でプログラミングを教えろ、ただし中学レベルの数学を教えるな
Goがやりたいことは大体これと同じだろ

**デフォルトの名無しさん** · 2018/04/07(土) 18:27:40.19

何か問題でも？

**デフォルトの名無しさん** · 2018/04/07(土) 19:04:22.55

どこかの評論家に否定される前に、自分で考えて肯定すればいいのに
自分で考えるのをやめたら、否定してくださいと言ってるようなものじゃないか

**デフォルトの名無しさん** · 2018/04/07(土) 19:20:07.17

>>759は自分で考えてなんの問題もないと肯定したレスだろう

**デフォルトの名無しさん** · 2018/04/07(土) 19:59:52.92

>>758
まあGoogleの中の人は例外すら理解できなくてGoに盛り込まなかったくらいだからな
Googleのプログラマは小学生レベル

**デフォルトの名無しさん** · 2018/04/07(土) 20:02:15.13

いやいやいや

**デフォルトの名無しさん** · 2018/04/07(土) 20:42:13.27

>>762
例外なんて機能を欲しがるとか正気か？
タプルかタグ付きユニオンのある言語には例外なんて必要ない
むしろ、無いほうがよほど筋が良い。よりによって例外かよ…

Go言語の問題はもっと他にあるよね
ジェネリクスとかNil安全とかラムダ式とかイミュータビリティとか

**デフォルトの名無しさん** · 2018/04/07(土) 20:45:00.99

AirPlayさんなんだろ

**デフォルトの名無しさん** · 2018/04/08(日) 00:14:21.96

>>764
100得ナイフを欲しがっても無理だぜ。
お前さんは、刺身包丁では肉を斬りにくいと文句いう人なの？

**デフォルトの名無しさん** · 2018/04/08(日) 00:16:58.41

ガイガイ

**デフォルトの名無しさん** · 2018/04/08(日) 00:44:53.47

ここでのクソみたいな議論に時間を使うことが一番コスト高ってことを
goを使ってる人はわかってる。

**デフォルトの名無しさん** · 2018/04/08(日) 00:59:11.92

>>764
例外ってか戻値無視してたらコンパイルエラーにする構文がほしい。(すでにgoにあったらスマヌ)
ライブラリやミドルウェア作るとき、ここでエラーならそれ以上処理進めんなってことあるので、アプリ側のエラーハンドリングを強制させたい。
それができないからやむを得ず例外で終了させてる。

**デフォルトの名無しさん** · 2018/04/08(日) 01:06:05.49

>>769
例外とコンパイルエラーを同じものと考える神経がわからん。
実行時にまずい処理が来たらgoのプログラムを強制終了させたいならpanicがあるが。

**デフォルトの名無しさん** · 2018/04/08(日) 01:11:44.09

つーかgoが気に入らない理由に例外を上げるけど、例外ってそんなに良いもんかね？

例えばこの関数は例外を上げる可能性があるからtryブロック内に書かないとコンパイルエラーになる言語ってある？
それくらいやってくんないと例外を使う意味って、エラーハンドリング問題の先送りでしかないから。

**デフォルトの名無しさん** · 2018/04/08(日) 01:12:25.64

>>766
問題って書いたのが誤解を招いてしまったかな…
別に上記の全てが無いとダメって言ってるわけじゃないよ。あったら嬉しいなくらいにしか思ってない
けど、例外なんて邪魔にしかならん機能を欲しがるくらいなら他に欲しいものがいくらでもあるだろと思って…

あと、揚げ足取って悪いけど、100徳ナイフを欲しがってるなら例外も欲しがってるはずだろ…
例外と継承を捨てたのはGoの英断

**デフォルトの名無しさん** · 2018/04/08(日) 01:16:07.05

>>772
いやお前は悪くない。相手が意味ワカラン奴なだけだ

**デフォルトの名無しさん** · 2018/04/08(日) 01:46:25.89

java
但しランタイム例外は除く

**デフォルトの名無しさん** · 2018/04/08(日) 02:00:48.53

>>771
>例えばこの関数は例外を上げる可能性があるからtryブロック内に書かないとコンパイルエラーになる言語ってある？
Javaの検査例外とSwiftの例外はtry必須だよ。
けど、try必須だと書くのが面倒なんだよね。実際、Javaでは非検査例外のほうが主に使われてるし…
検査例外と非検査例外を場合によって書き分けるのがJavaの理想なんだろうけど、現実はそうじゃない…
Swiftの例外はtryの書き方が何種類かあるからJavaより使い易くはなってるんだけど
Rustと同じでタグ付きユニオン(enum型)あるから別に必要なくない？ってなる
Rustはエラー処理にenumのResult型を使うけど、Swiftでは例外を使うのがマナーなのかな？

**デフォルトの名無しさん** · 2018/04/08(日) 02:16:09.65

>>775
swiftはそうだったな。
たしか例外周りはswift2で追加実装されてウゲーってなった覚えがあるような。
swiftの言語仕様の変更は凄まじいものがあるよな。もうswift4だっけか？
正直swift信奉者≒apple信者じゃないと説明がつかない。
言語仕様をミニマムに抑えて熟考するgoを見習ってほしいわ。

**デフォルトの名無しさん** · 2018/04/08(日) 02:26:12.80

>>775
つまり結局goのエラーハンドリングの面倒くささと一緒になるってことだよな？

goのエラーはただの値だから
構造体のメンバ変数に格納先を用意してやれば、
後で纏めてチェックしたり、
一回でもエラーが発生したら処理を中断する
みたいな書き方は全然できる。

そのへんはgo blogに記事があった。

**デフォルトの名無しさん** · 2018/04/08(日) 03:04:32.63

>>771
goの例外不在についてはerrorの握りつぶしが書きやすい上に気づきにくいのが不満
握りつぶしに比べたら先送りのほうがまだ良い
>>769が戻値無視してたらコンパイルエラーって言ってるのはそこが理由でしょ

**デフォルトの名無しさん** · 2018/04/08(日) 03:14:34.94

>>778
あー。なるほどと思ったけど例外処理は先送りしたあげく、結局とこでも処理せず終わるパターンあるよね。
握りつぶしが簡単にできるのはどっちも一緒では？

**デフォルトの名無しさん** · 2018/04/08(日) 03:17:34.48

>>779
ハンドルされない例外は処理の中断になるけど、
握りつぶしは処理の続行になる
中断のほうが良い、と思う

**デフォルトの名無しさん** · 2018/04/08(日) 03:49:10.38

>>780
例外の一番の問題は予想外の場所で例外が不必要にキャッチされて、その上で
握りつぶされてしまった場合、握りつぶされた場所を特定するのがかなり面倒臭いこと。
そんなコード書くヤツが悪いと言いたいが実際にいるんだからしょうがない…
どこで握りつぶされるか分からんリスクを背負うくらいならその場で握りつぶされた方がまだいい

因みに、エラーハンドリングに関してはRustのResult型が最も筋が良いと思ってる
Result型なら故意に握りつぶそうとでもしない限りは簡単には握りつぶせない

**デフォルトの名無しさん** · 2018/04/08(日) 04:07:01.05

>>781
goのほうが握りつぶしが書きやすいからこそ、どこで握りつぶされるか分からんリスクはgoのほうが大きい、と思うんだよなあ

**デフォルトの名無しさん** · 2018/04/08(日) 08:46:33.77

>>781
トラブルシューティングの為に、キャッチした時点でロギングしないの？

**デフォルトの名無しさん** · 2018/04/08(日) 09:00:51.10

Cのprintfの戻り値を毎回欠かさずチェックしてる人だけが例外に石を投げなさい

**デフォルトの名無しさん** · 2018/04/08(日) 10:19:07.88

戻り値の握り潰しは局所的・静的に判断できるけど例外はそうじゃないからなぁ。
それこそ例外を起こしてみないと見つけるのが困難だったりして。

**デフォルトの名無しさん** · 2018/04/08(日) 10:23:53.74

例外は継続的な改良に対応しやすいのがメリットなんだよな
取りあえず最初は例外安全だけ意識して例外は上の方でまとめて処理しておいて、
あとでより丁寧な取扱いが必要になったときは問題なく対応できる
もちろん、検査例外とかいうビチグソは無い前提だが

**デフォルトの名無しさん** · 2018/04/08(日) 11:36:37.63

最初はexit
exitの握り潰しが必要になったら例外で

**デフォルトの名無しさん** · 2018/04/08(日) 11:42:04.86

>>758
1から10までの整数を足すのに
ループで順番に足す方法を教える様なのが
今の日本のプログラミング学習(教育)だからな
そんなんじゃだめ

**デフォルトの名無しさん** · 2018/04/08(日) 13:08:16.40

このスレも例外が理解できない幼稚園児ばっかかよ
Goみたいな言語が流行るわけだ

**デフォルトの名無しさん** · 2018/04/08(日) 13:22:55.27

自分で選んだ言語がそれだったらそれでもいいよ
より良い言語を後で見つけたら自分が馬鹿だっただけで済む
しかしそれを選んだのが会社や国家だったら馬鹿にしても炎上するし擁護しても炎上する

**デフォルトの名無しさん** · 2018/04/08(日) 13:39:52.93

このスレの議論はほんとレベルが低いな
間違った使い方をしたときどちらがマシかでしか優劣をつけられないのか

**デフォルトの名無しさん** · 2018/04/08(日) 13:50:33.26

>>782
なんか会話が噛み合わないなと思ってたがやっと理由が分かった気がする。
>>782の言う"どこ"はGoのエラー(戻り値)は握りつぶしがしやすいから
誰が"どこ"でエラーを握りつぶすコードを書くか分からないって意味の"どこ"だよね。
俺の言う"どこ"は例外がスローされた場所に対して
キャッチされる場所が"どこ"か分からないって意味の"どこ"なんだよ。
キャッチされる場所が分からないとデバッグ時に探すのが面倒なんだよ。
Goみたいに戻り値としてエラーが返されるとエラーの発生場所と
握り潰した場所は必ず一致するからデバッグしやすい。
結局、従来の例外はgoto文と同じでフローが飛ぶから気持ち悪いってのが俺の意見。

**デフォルトの名無しさん** · 2018/04/08(日) 14:09:14.32

従来の言語にはexitがあるから例外がない
SmalltalkやJavaScriptにはexitがないから例外があるんだろう

**デフォルトの名無しさん** · 2018/04/08(日) 14:12:58.97

>>791
でも、次世代言語って間違った使い方(プログラマによるミス)をさせないように
制限をかける意味合いが強くない？Null安全とかその典型だと思うんだけど。
オレは絶対に使い方を間違えないって言うんならC++, C#とかを使ってろよってなるし…

**デフォルトの名無しさん** · 2018/04/08(日) 14:13:54.54

>>792
戻り値のエラーを握りつぶされると、不適切な状態で動き続けるから、デバッグが困難になると思うんだが。
例外の握りつぶしでも同じ事だけど、構文としては、例外の握りつぶしの方が見つけやすいと思うけどね。catchブロックでしか細工できないから。
goだと正常な返り値の隣に,_つけるだけで握りつぶせちゃうから、見つけづらいんじゃないかな。

**デフォルトの名無しさん** · 2018/04/08(日) 14:15:23.81

間違えを考慮しないシステムの恐ろしさを全くわかってない奴はそもそも話にならん。
プログラミングを語る資格がない。

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

>>795
すまん。よく考えると確かにデバッグはどっちも面倒なことに変わりないわ。
ただ、個人的にはtry-catchも,_もどっちも見つけづらさは大して変わらないと思ってる。
デバッグ時じゃなくて、普通にコードを読むときに戻り値でやったほうがフローを把握しやすいってことが言いたかった。

**デフォルトの名無しさん** · 2018/04/08(日) 14:26:14.02

返り値でエラーを判別するコードだと、本来やりたいことの次にほぼ必ず、エラー判定処理が入るから、可読性が低いんだよね。
昔、C使ってた頃は、そういうところが嫌でたまんなかったし、ひどいのになると主要な処理が全部、条件部分で行われてて、if文の連なりしかないコードとかみたし。
正常系をリーダブルに書くには、例外の方が気持ちいいなと思うよ。

**デフォルトの名無しさん** · 2018/04/08(日) 14:32:30.43

そのあたりはEitherが良いと思うんだな

**デフォルトの名無しさん** · 2018/04/08(日) 14:35:54.54

後、最近のIDE使ってると、todoをコメントに入れとけば、あとでそれを、まとめて見直せるから、取り敢えず、try-catchして、catchのところはtodoにしといて、まず正常系を一通り買いてから、あとで異常系に対処するっていうワークフローにできるのが、例外の利点かなと思う。

**デフォルトの名無しさん** · 2018/04/08(日) 14:37:10.66

>>792
デバッグ時に、どこかでエラーが握りつぶされてるかもしれない、というパターンを考えないといけない、という意味で「どこ」
しかもそういう状況は>>795の言うように不適切な状況で動き続けるから
握りつぶした箇所と不具合の発生箇所がかけ離れることも多い
だから、goに限ったことではないが、エラーや例外の握りつぶしはデバッグしづらい
例外がどこでcatchされてるか探すのは、握りつぶし探しに比べたらまだ簡単

**デフォルトの名無しさん** · 2018/04/08(日) 14:37:23.36

>>799
タグ付きユニオンがある言語ならそれが一番だと思う。
前にも言ったけど、エラーハンドリングに関してはRustのResult型が一番筋がいいと思ってる
でも、Goにはタグ付きユニオンがないからなあ…

**デフォルトの名無しさん** · 2018/04/08(日) 14:51:49.81

goは本格的には使ったことないけど、無視はできないんで、いろんなコードを見てるんだけど、今のところの感想としては、goって、書き手の思考を遮らないというところに重きを置いてる印象。
deferなんか、なんか開いたらあとで閉めるけど、忘れない内にその処理を予約しとこうみたいな発想かな。
自分は書くことより読むことを重視するタイプなんで、あまりgoには向いてないなあと思ってる。

**デフォルトの名無しさん** · 2018/04/08(日) 14:51:50.04

副作用禁止ならexitも例外も禁止だからEitherがある

**デフォルトの名無しさん** · 2018/04/08(日) 15:22:23.64

stack traceもしらんのか

**デフォルトの名無しさん** · 2018/04/08(日) 15:29:06.45

握りつぶしてるところでスタックトレース出力するんだよ！

('､3_ヽ)＿？？

**デフォルトの名無しさん** · 2018/04/08(日) 15:51:49.24

maybe, eitherがある言語やった後に無い言語はしんどい

**デフォルトの名無しさん** · 2018/04/08(日) 17:20:17.22

Maybe, Eitherは強い。ほぼ必須な体になってしまった

**デフォルトの名無しさん** · 2018/04/08(日) 17:47:41.66

Eitherは初見だとそれがエラー処理用によく使うっていうことが
名前から全然伝わってこないところだけが嫌い

**デフォルトの名無しさん** · 2018/04/08(日) 17:58:42.79

>>803
書きやすさと読みやすさは同一だと思ったが。特にdeferとか大体close処理では？
open直後はdeferにclose処理書いてあったほうが読みやすくないかな？

**デフォルトの名無しさん** · 2018/04/08(日) 17:58:46.39

たし蟹

**デフォルトの名無しさん** · 2018/04/08(日) 18:04:30.90

リューナイト

**デフォルトの名無しさん** · 2018/04/08(日) 18:14:07.95

defer はスコープの終わりで暗黙的に動くクラスのデストラクタより
コード部分で明示した方がわかりやすくね？って発想じゃないかね。
こういうのは好みだったり書いてるアプリの種類で分かれそうな気はする。

**デフォルトの名無しさん** · 2018/04/08(日) 18:50:09.38

c++17の [discard]はどうかね？

**デフォルトの名無しさん** · 2018/04/08(日) 18:52:29.42

間違えた nodiscard

**769,815** · 2018/04/08(日) 23:39:43.80

>>792
> Goみたいに戻り値としてエラーが返されるとエラーの発生場所と
> 握り潰した場所は必ず一致するからデバッグしやすい。

俺もそれには同意で、更に一歩すすんでc++17の nodiscard属性みたいな指定ができるてほしいんだよ。デフォルトはコンパイルエラーで。

**デフォルトの名無しさん** · 2018/04/09(月) 00:41:14.72

Fortran のIO関係のエラー処理は優れてると思うわ。
Open文にoptionalのerr引数を渡して置けば、エラーが出てもerrに値を入れて続行。err引数を渡してなかったらエラーが出たら異常終了

**デフォルトの名無しさん** · 2018/04/09(月) 00:59:36.33

goのdeferは、その中で起こったエラーを外に通知する(簡単な)方法がないってんで
槍玉に上げられてなかったっけ？うろ覚えだけど

**デフォルトの名無しさん** · 2018/04/09(月) 01:32:15.01

>>818
一番簡単な方法は名前つきreturn変数を使うことだから簡単ちゃ簡単
だが正直名前つきreturn変数がそもそもクソ構文

**デフォルトの名無しさん** · 2018/04/09(月) 06:40:40.00

>>817
異常終了してはならないUIもある
UIが言語に影響を与える

**デフォルトの名無しさん** · 2018/04/09(月) 07:57:09.29

>>819
はー、名前付きreturn変数なんてあったんだ
しかし本来の流れによるerrがある場合は握りつぶさないようにしないといけないし、真面目にやると分岐が入り組みそうだな

**デフォルトの名無しさん** · 2018/04/09(月) 07:59:50.20

>>820
いやそのためにerr引数があるのよ……

**デフォルトの名無しさん** · 2018/04/09(月) 08:27:01.39

>>816
MSはかなり昔からそういうの力を入れていて独自仕様で実現してるな。(SAL注釈)
SDKのヘッダなんかで見かける _Check_return_ とかとかいうやつ。VSの「コード分析」でチェックしてくれる。

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

理想はエラーハンドリングを書いてなかったらコンパイルエラー。
(エラーハンドリングでエラー握り潰すやつは流石にそこまで面倒見きれない)
次点は強制終了。その際にエラーがどこで何故起きたのかって情報を出せること。
一番悪いのはそのまま処理進んでサイレントクラッシュ。

こんな感じ。

**デフォルトの名無しさん** · 2018/04/09(月) 08:51:45.67

コンパイルエラーは、そこまで強烈にエラー対応必須にしたらスクリプトみたいな「まずはとりあえず動くコードを書いて様子を見る」っていう使い方は出来なくなるな

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

となるとrustやな

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

そういやClojureってどうなったん？

**デフォルトの名無しさん** · 2018/04/09(月) 10:18:17.46

Goの名前付きreturn使うとアセンブリまで落としたとき、コードが少しきれいになるぞ。
俺は好き。