次世代言語11[Rust Swift TypeScript Dart]

**デフォルトの名無しさん** · 2018/06/03(日) 23:53:27.92

スレタイ以外の言語もok

前スレ
次世代言語10[Rust Swift TypeScript Dart]
https://mevius.5ch.net/test/read.cgi/tech/1524607347/

**デフォルトの名無しさん** · 2018/06/26(火) 20:23:51.43

Scalaも構文ダメだけど、Dottyでかなり改善されてるみたいだね

http://dotty.epfl.ch/

**デフォルトの名無しさん** · 2018/06/26(火) 20:32:08.64

>>768
>>769
冗長な構文にするなってこと。

```Rust
match number {
1 => "one",
2 => "two",
_ => "else",
}
```
```swift
switch number {
case 1: return "one"
case 2: return "two"
default: return "else"
}
```

**デフォルトの名無しさん** · 2018/06/26(火) 20:36:27.71

msが嫌いならflow使っとけばいいよ。
俺はTypeScriptで行く

**デフォルトの名無しさん** · 2018/06/26(火) 20:37:59.55

>>771
rustをそんなに押すなら、
毎日ちょっとずつ使い方教えていけよ。
面白い内容ならそのまま覚えるから

**デフォルトの名無しさん** · 2018/06/26(火) 20:40:42.88

>>767
case varがあるからでは

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

>>770
dottyは流石に見苦しいわ
今更互換性ブチ壊して誰がわざわざScalaなんか使い続けるんだよ
Lightbendは一度プラットフォーム主導者の味を覚えてしまってもう後に引けなくなってるんだろうな

**デフォルトの名無しさん** · 2018/06/26(火) 21:08:47.59

元が冗長だと、機能追加したときの新構文(大抵元と区別のために冗長になる)が
あまり違和感なくなるというメリット？もある
C++とか酷いだろ。rustも多分20年ぐらいしたら酷くなる

**デフォルトの名無しさん** · 2018/06/26(火) 21:18:39.20

>>774
Rust: https://play.rust-lang.org/?gist=374b461ab0c7a5de9f5e0dc6db6c630b&;version=undefined&mode=undefined
Swift: https://ideone.com/4yPERL

この場合Rustのようにlet書く必要ないと思うんだけど？

**デフォルトの名無しさん** · 2018/06/26(火) 21:33:59.71

>>776
Rustが20年も残ってるとか信者かよ

**デフォルトの名無しさん** · 2018/06/26(火) 21:38:20.73

>>763
いつMSが邪悪じゃなくなったんだよ

エディタについてはVimとEmacs以上のものがいまだにないだけ

**デフォルトの名無しさん** · 2018/06/26(火) 21:42:01.06

>>779
老害おつ

**デフォルトの名無しさん** · 2018/06/26(火) 21:43:00.71

>>778
ObjectPascalは30年経ってるが、元が冗長と言われまくってたPascalだったおかげで
魔改造されまくった今でもあんまり浮いた構文は無いぞ
初期Macで採用されてたのは別格としても、その後は大したプロダクトもないDelphiぐらいでしか残ってないのに
一応生き残ってるんだから、FirefoxのあるRustも同じぐらいは残るだろ多分

**デフォルトの名無しさん** · 2018/06/26(火) 21:46:10.71

>>780
どっちかっていうと、若者がMSの暴虐の歴史を学んでないから
今現在進んでる暴虐が暴虐と分からないだけだぞ

**デフォルトの名無しさん** · 2018/06/26(火) 21:49:11.80

>>781
火狐に使われてるから残るとか
火狐の世界シェア見てから言おうぜ……

Rustごと自殺して消えるって自白したようなもん

**デフォルトの名無しさん** · 2018/06/26(火) 21:49:29.84

完全に半島人

**デフォルトの名無しさん** · 2018/06/26(火) 21:49:47.34

>>777
だからletとvarがあるんだって
let: https://ideone.com/eB3UWN
var: https://ideone.com/ae3qzC

**デフォルトの名無しさん** · 2018/06/26(火) 21:50:20.36

>>782
具体的に

**デフォルトの名無しさん** · 2018/06/26(火) 21:50:49.04

Delphiで残れたのなら火狐で残れるだろ

**デフォルトの名無しさん** · 2018/06/26(火) 21:54:24.01

この爺さんはこのスレに何しにきとるんだ
特養じゃないっつの

**デフォルトの名無しさん** · 2018/06/26(火) 21:56:05.20

>>787が書いてくれたが
俺も、どっちも細々としたもんだがFirefoxのほうがDelphi(製アプリ)よりはまだマシだろう、というつもりだった
その上で20年後の変更されまくったrustはDelphiやswiftより汚くなってそう、という予想

**デフォルトの名無しさん** · 2018/06/26(火) 22:07:57.87

すでに汚いしな。

**デフォルトの名無しさん** · 2018/06/26(火) 22:12:37.76

>>785

varがあるのはわかるけど、そこでvarを使う場面てあるのかね？

https://ideone.com/vMGLEg
```swift
case let .B(n):
let t = n+1
return String(t)
```

だって変わらんし

**デフォルトの名無しさん** · 2018/06/26(火) 22:24:29.16

>>785
それにvarのときだけつければ良くないかね,Rustだと「mut」つけるだけだけど

https://play.rust-lang.org/?gist=f7bb032027fcdbc6db2f033c4874c27c&;version=stable&mode=debug
```rust
AB::B(mut n) => {
n+=1;
n.to_string().into()
}
```

**デフォルトの名無しさん** · 2018/06/26(火) 22:33:54.59

>>791
変数束縛にletとvarがある言語において、switchのときだけ変数束縛を特別扱いしてletやvarを省略できるのは一貫性が無いという考え方もある

**デフォルトの名無しさん** · 2018/06/26(火) 22:39:59.15

それに短ければ良いなら、rustのlet mulよりswiftのvarの方が短い
パターンマッチより変数宣言方が良く出て来るしね

**デフォルトの名無しさん** · 2018/06/26(火) 22:47:02.38

20年後に汚くなるってのはみんなわりと納得するんじゃね？
C++もJavaも、時間経過とともにきっちり汚くなった
言語仕様こねくり回すのが仕事の人が存在するからしゃーないっちゃあしゃーない

**デフォルトの名無しさん** · 2018/06/26(火) 22:48:50.88

難しい・易しいではなく汚い・美しいという見方をするのはなんでだろう
数学を諦めた感が漂ってる

**デフォルトの名無しさん** · 2018/06/26(火) 22:49:48.96

>>793
そういう見方もあるけどね

でも
```
case let .B(x): return String(n)
```
と
```
case .B(let x): return String(n)
```
の違いってなんなのかね、違いがないなら「let」省略できたほうがいいように思うが

**デフォルトの名無しさん** · 2018/06/26(火) 22:51:21.79

>>797
訂正： xじゃなくてn

**デフォルトの名無しさん** · 2018/06/26(火) 22:57:45.92

>>794
短いことがいいんじゃないよ、理由なく冗長な構文がだめなだけ。

Rustはわざと「var」とかじゃなく「let mut」にしている理由は、通常イミュータブルを使うようにするため。
ミュータブルの構文が長いことでプログラマがイミュータブルをより一般的に使うよう促す効果がある。

**デフォルトの名無しさん** · 2018/06/26(火) 23:00:40.71

可読性の高い綺麗なPerlコードを書けるものだけが石を投げなさい

**デフォルトの名無しさん** · 2018/06/26(火) 23:12:38.14

>>799みたいなのは設計当初は綺麗なんだけど
後から、例えばD言語のconst/immutableみたいな選択肢を追加してしまうと罠に化けそうじゃない？(妄想だけど)
その点元が冗長ならある程度耐性がある、という話。後から省略可能にする方はできるしな

**デフォルトの名無しさん** · 2018/06/26(火) 23:29:44.42

>>801
Dは全然知らないけど、調べたらデフォルトがミュータブルで、immutableをつけるとイミュータブルになるのか。

```
int x = 3; // ミュータブル
immutable int x = 3; // イミュータブル
auto s = "hello"; // イミュータブル
```

これはひどいな

**デフォルトの名無しさん** · 2018/06/26(火) 23:32:04.35

>>802
そこはまあしょうがないとして、イミュータブルにも種類があるという点に注目してくれ

**デフォルトの名無しさん** · 2018/06/26(火) 23:40:45.19

コンパイル時に値がわかるのが定数
実行時に初期化するがその後は変更しないのがimmutableかな

**デフォルトの名無しさん** · 2018/06/26(火) 23:56:28.51

加えて、現在のスコープからは変更不可能だが実体はミュータブルかもしれないのがconst
更にそれぞれに推移のON/OFFがある

何も書かないのがイミュータブルだとその内の1つを適当に使ってるということで
選択肢が増えたときにどれか1つが不自然に短く書けてたことになるし
現状を突き詰め直したときにコンテキスト毎に別のだったなんてことになると目も当てられない

**デフォルトの名無しさん** · 2018/06/27(水) 00:01:32.20

やっぱり言語仕様は頻繁に変えるべきということだな！w

**デフォルトの名無しさん** · 2018/06/27(水) 00:50:40.19

>>802
ゲェジかな
ワイの方がよっぽどいい設計できるわ
この作者はワイのケツ穴でも舐めてた方が幾分有益な人生になったんじゃないかｗ

**デフォルトの名無しさん** · 2018/06/27(水) 00:59:47.78

>>805
GCが必須ではない言語の場合、ミュータブルならばメモリ解放もできる

現在のスコープからは変更不可能だが実体はメモリ解放するかも
というのは非常にまずい
現在のスコープから変更不可能ならば実体も変更不可能にしたい

**デフォルトの名無しさん** · 2018/06/27(水) 01:19:45.86

>>808
それだとイミュータブルなオブジェクトを貰って何かする関数に
ミュータブルなオブジェクトを渡せなくならない？

そうすると print とか toString とか hash とか compare とかありとあらゆるものが
immutable / mutable 2種類必要になる
引数に2つオブジェクトがあると4種
3つなら8種

**デフォルトの名無しさん** · 2018/06/27(水) 20:24:28.42

ただの再代入不可な変数をイミュータブルって言い始めたのって何の言語からなの

**デフォルトの名無しさん** · 2018/06/27(水) 21:06:16.07

>>810
たぶん英語だと思う

**デフォルトの名無しさん** · 2018/06/28(木) 08:21:12.64

>>795
pythonなんかも細かいところはど汚いわけだがあんまりそういう汚いところ
触らんでも仕事になるって違いはある。
てかシンタックスなんててきとうにチェックでもそんな問題にならんよ。
self書かされることなんて文法で規制されてるわけでもないが問題になることなんてない。

**デフォルトの名無しさん** · 2018/06/29(金) 09:12:05.44

>>810
変更可、不可という概念は別に変数に限った話じゃない

**デフォルトの名無しさん** · 2018/06/29(金) 09:23:47.61

Pythonの型アノテーション試してるけど正直苦痛
TypeScriptを使ってるときには全く感じなかった無駄なもの書かされてる感がすごい
というかTypeScriptの統合が完璧すぎるんだな
型書くことはノイズになるどころかコードをむしろ美しくするとすら思えるもんな

**デフォルトの名無しさん** · 2018/06/29(金) 10:57:44.57

少しでも欲を出せばそうなる
完璧な無欲か完璧な満足かの1bitしかない
HaskellやRustのようになるまで止まらないぞ

**デフォルトの名無しさん** · 2018/06/29(金) 11:15:41.22

>>814
Python 3.6の変数アノテーションはTypeScriptと大して変わらないのでは？
以前のコメント形式は糞だったけど

**デフォルトの名無しさん** · 2018/06/29(金) 13:13:42.11

>>814
全部の変数にアノテーション付けようとしてる？
基本、関数・メソッドの入出力だけでいいぞ
残りは大体推測してくれる

**デフォルトの名無しさん** · 2018/06/29(金) 13:43:06.77

>>817
ライブラリなどの既存メソッドの戻り値はほとんど型なしだから結局オレオレ型宣言を左辺の変数に付けて回ることになる

**デフォルトの名無しさん** · 2018/06/29(金) 15:55:24.38

>>818
あー、過渡期だからそれはあるかもね
対策としては、他モジュールを呼び出すところはなるべく集める、いきなり完璧を目指さないぐらいか

**デフォルトの名無しさん** · 2018/06/29(金) 20:05:29.68

そんなに型に気を使って消耗する位ならもう生js使おう
適当にラッパーかけとけラッパー

**デフォルトの名無しさん** · 2018/06/29(金) 21:06:52.59

>>820

TypeScriptユーザーがシコシコ型定義ファイル作ってるおかげで、vscodeでjsでも補完きくんやで。感謝せーや

**デフォルトの名無しさん** · 2018/06/29(金) 21:09:19.97

せめて同梱の標準ライブラリくらいは網羅しておいてほしいよね。

**デフォルトの名無しさん** · 2018/06/29(金) 21:11:52.89

>>814
typeScriptみたく型定義ファイルの共有する仕組み無いの？
いちいち書くのはしんどいな。

**デフォルトの名無しさん** · 2018/06/29(金) 21:39:48.60

>>823
しんどいのか
その作業がないということはライブラリの作者は楽をしている
だからライブラリが増やすのも楽
そういう仕組みなんだろう

**デフォルトの名無しさん** · 2018/06/29(金) 22:21:57.95

>>824
TypeScriptの場合は型定義を提供することでTypeScriptユーザーに使ってもらいやすくなり、
ユーザーの増加がライブラリ製作者にとって一手間かけるモチベーションになる
Pythonの場合は型アノテーションを付けたらPython3.5以上でしか使えなくなるのでユーザーは確実に減る
結果、誰も対応しない
根本的に破綻してるんだよ

**デフォルトの名無しさん** · 2018/06/29(金) 22:35:49.90

>>825
破綻してるのはお前のマウンティングだよ
マウントが酷いのはHaskellで、TypeScriptは無関係みたいなイメージが根本的に壊れた

**デフォルトの名無しさん** · 2018/06/29(金) 22:39:04.05

そんなんでイメージ変わるのかよ…

**デフォルトの名無しさん** · 2018/06/29(金) 23:18:51.02

おれ的にはこのまま型定義ファイルがすべてのライブラリに標準装備されて緩やかにjsがts化していくことを希望したい。
最初から型定義がライブラリに入っていること多くなってきたよな、

**デフォルトの名無しさん** · 2018/06/29(金) 23:54:19.04

>>828
それには同意

**デフォルトの名無しさん** · 2018/06/30(土) 02:42:20.84

このスレに来て初めてマウンティングって言葉を知ったわ。

**デフォルトの名無しさん** · 2018/06/30(土) 03:36:46.79

>>823
あるよ。
typeshedてのがそれ

>>825
関数の引数、返値なら3.0から書けるし、コメント使うか別ファイルに書くやり方なら2.7にも対応可能ですが

**デフォルトの名無しさん** · 2018/06/30(土) 08:02:10.37

Haxe では型定義ファイルがあるから、型推論も入力補完もできる

**デフォルトの名無しさん** · 2018/06/30(土) 09:44:21.50

通常ならライブラリ本体丸ごと読んで型を調べるべきだ
本体に型がないなら別ファイルに書く

**デフォルトの名無しさん** · 2018/06/30(土) 12:26:26.59

>>831
なんだあるんだ。なら型付言語として使われるのも時間の問題だな。
rubyにもあるみたいだし、
ライブラリのインターフェースだけでも型付き当たり前の世界が来そうだね

**デフォルトの名無しさん** · 2018/06/30(土) 14:15:03.20

まーたruby信者のそ、そんなのる、るびぃでもできるし！か。呆れ
なんでもかんでも深く考えず流行りをそうやって後付けで増築してって奇形極まってるよね。二度と使わないよ。

**デフォルトの名無しさん** · 2018/06/30(土) 15:58:28.61

rubyの違法建築感は否定しない
が、なんかまとめ臭い書き方だなおい
5chエアプか？

**デフォルトの名無しさん** · 2018/06/30(土) 16:41:24.65

るびぃ信者、Proc.new、ラムダ、ブロックにおけるreturn、break、nextの挙動の違いをまとめようとした模様
https://qiita.com/jnchito/items/83410c0cda446efea582

結果、ややこしすぎるためコーディングを工夫してreturnやbreakの使用を避けましょうというなんじゃそりゃな結論ｗｗｗ

何か理由があってわざわざ挙動を変えたんだろうが(まさか行き当たりばったりってことはないよね笑)ややこしすぎで使用自体を避けられてちゃ本末転倒だよなｗｗｗ

**デフォルトの名無しさん** · 2018/06/30(土) 17:39:57.19

>>836
その人はrustがコンパイルできないおじさんだからほっときなさい

**デフォルトの名無しさん** · 2018/06/30(土) 18:00:17.99

rust
ruby
似てないこともないな

**デフォルトの名無しさん** · 2018/06/30(土) 18:59:53.28

>>834,836
とはいえ、ruby にまともに使える型チェックの実装があるのかには興味あるな。
まえ調べた感じだと、教祖の型チェック周りの発言はフワッフワだし、実装してみたい個人が互換性のない「オレオレ型チェック」を作っては破棄してる感じで、万人が使えるものは何一つないようなんだが。

**デフォルトの名無しさん** · 2018/06/30(土) 19:02:48.17

どうせ
if type(...) != my_class:
とかのシュガーだろ。そんなもんに目くじら立てても意味あるのかね。

**デフォルトの名無しさん** · 2018/06/30(土) 19:33:21.11

Rubyはオモチャだから型付けなんて要りません
それより散らかったオモチャを片付けなさい

**デフォルトの名無しさん** · 2018/06/30(土) 20:38:08.56

自分のために違法建築したとは考えにくい
ユーザーを忖度して違法建築なら利己的ではないからOKという風潮があったんじゃないか

会ったこともないユーザーをモチベーションにするのはやめてほしい

**デフォルトの名無しさん** · 2018/06/30(土) 23:16:50.81

>>837
Ruby のProc, block はクロージャだから、クロージャを囲む関数から戻る。
一方ラムダは、単にクロージャを抜けるだけ。
Groovy なども参照

def f
(0..5).each do |i|
puts i
return if i == 3
end
end

f() #=> 0, 1, 2, 3

**デフォルトの名無しさん** · 2018/06/30(土) 23:39:42.18

＞Ruby のProc, block はクロージャだから、クロージャを囲む関数から戻る。

クロージャ「だから」、クロージャを囲む関数から戻る？？

まるでクロージャだったら当然の挙動と言わんばかりの書き方だけど、クロージャってそんなんだっけ？

**デフォルトの名無しさん** · 2018/07/01(日) 00:39:17.02

そんなものちゃんと読んでる>>845に感心したw
ネットにはゴミが多いね

**デフォルトの名無しさん** · 2018/07/01(日) 01:54:08.61

>>845
ヒント：Smalltalk

**844** · 2018/07/01(日) 02:00:27.83

クロージャは、クロージャの外側の環境をつかんでいる。
つまり、クロージャを囲む関数内の変数をつかんでいる

だから、クロージャ内でreturn すれば、外側の関数も抜けて、
関数内の変数なども、解放した方が良いと考えた

Groovy の挙動とは違うかも

**デフォルトの名無しさん** · 2018/07/01(日) 02:11:27.56

>>848
return だけだったら納得できるんだが、next や break の扱いがぐちゃぐちゃなのはどう説明するの?

**デフォルトの名無しさん** · 2018/07/01(日) 02:52:24.35

>>847
関数型でもないウンコ言語がクロージャの話に入ってくんな
何の参考にもならんわ

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

>>837
> まさか行き当たりばったりってことはないよね笑

その、まさかだぞ。
楽しくプログラミング（）した結果が仕様だ文句あるか！ｗ

**844** · 2018/07/01(日) 08:32:31.95

クロージャ(block)内のbreak は、クロージャを抜けるだけで、外側の関数は抜けない。
関数の最後まで実行される

クロージャ内のnext は、次の繰り返しに進むだけで、クロージャも抜けない。
クロージャの最後まで実行される

def f
num = 0
(0..5).each do |i|
num = i
break if i == 3
end
puts num
end

f() #=> 3

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

すみませんがゴミの話は当該スレでお願いします

**デフォルトの名無しさん** · 2018/07/01(日) 09:01:20.31

これ他の言語にも影響あるだろ
continueはバグの原因になるとか、gotoの方がマシとか言われる

**デフォルトの名無しさん** · 2018/07/01(日) 09:18:30.80

>>850
えー？closureが関数型特有な概念だと思ってるわけー？
面白いね、それ。本当は純粋関数型ではclosureはさほど重要ではないのだけど。
どうしてclosureが関数型固有な概念だと思ったのか、説明してごらん？

**デフォルトの名無しさん** · 2018/07/01(日) 09:22:52.78

>>855
おまえが自分で説明しないで人に説明させようとするからだよ
もし関数型の人が説明したら関数型の概念になるに決まってるだろ

**デフォルトの名無しさん** · 2018/07/01(日) 09:23:49.76

>>852
あなたが closure だからと主張する、block は 952の挙動だが Proc では break は例外吐くらしいけど何で?

# 言っちゃ悪いが、closure は定義した時点での環境を基準に動作が普通だと思うんで、
# ループ外で定義されているならば next/break は一律例外吐くで無いと一貫性がないようにしか見えん。

**デフォルトの名無しさん** · 2018/07/01(日) 09:24:49.31

>>857
すまん、「block は >>852の挙動」だな。

**デフォルトの名無しさん** · 2018/07/01(日) 09:25:25.69

このbreakとnextは並列コレクションで困る気はする

**デフォルトの名無しさん** · 2018/07/01(日) 10:22:00.59

>>856
へー、技術のベースになる概念が、関数型の人が説明したら別物になるのかー
おもしろいねークスクス

**デフォルトの名無しさん** · 2018/07/01(日) 10:23:24.47

>>856
で、関数型の人って誰？ばか？

**デフォルトの名無しさん** · 2018/07/01(日) 10:45:16.40

Smalltalkの人たちはScalaやRustのtraitsに対して、オリジナルのSmalltalkと違うからダメだ！あれは別物！って批判するくせに
他の言語より後に実装したclosureについては独自仕様でも問題ない、技術ベースで語れっておかしくね？
ダブスタも甚だしいだろ

**デフォルトの名無しさん** · 2018/07/01(日) 10:48:49.50

忖度とか伝言ゲームとかいう問題を織り込むまでがITです

**デフォルトの名無しさん** · 2018/07/01(日) 10:59:11.30

>>844はクロージャなら当然あるべき姿としてRubyのProcを語ってるからなぁ

それに対して>>847がヒント：Smalltalkって言ってるのは
要するにSmalltalkがクロージャのあるべき姿を体現してるって言ってるワケで、そりゃ傲慢すぎる

ただの一例としてSmalltalkのような仕様もあるって言うなら批判されないのに

**デフォルトの名無しさん** · 2018/07/01(日) 11:00:03.93

クロージャの方が自身の関数スコープを持ってる印象だな
メジャーな中では Java, C#, C++, JavaScript, Obj-C, Swift などがそうだし
Rubyのラムダも上記と概ね同じに見える

ブロックは文字通りコードの塊と考えるとreturnやbreakについて妥当な動きに見える

Proc.newは挙動がキモい

↓によるとdo…endも挙動が違うらしいから >>837 のリンク先は4種で比較した方がいいかもな
https://qiita.com/riocampos/items/43e4431ddff93e01a18d

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

中身読んだら結合度の差だったので >>865 の最後2行は撤回する

**デフォルトの名無しさん** · 2018/07/01(日) 11:16:48.58

>>864
妄想が激しいね。
ヒント：Smalltalkっていうのは、Rubyのそのヘンテコな仕様はSmalltalk由来だということなんだけど。
お大事にね

**デフォルトの名無しさん** · 2018/07/01(日) 11:19:42.69

>>862
きみ、結局はSmalltalkでのクロージャからのreturnの仕様を調べることすらしないで
思い込みだけで騒いでるでしょ？
そういうのを「バカ」って言うんだよ

**857** · 2018/07/01(日) 11:25:18.69

>>867
smalltalkには break や continue (next) はないだろう？
ruby のは、closure に break や next を持ち込んでおかしくなっているように見えるよ。