次世代言語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/

◆QZaw55cn4c · 2018/06/18(月) 01:07:58.13

>>555
今から rails に取り組もうと思っていたのですが…（?然）

**デフォルトの名無しさん** · 2018/06/18(月) 01:49:33.50

気にすんな。世の中には自分の能力が足りなくて理解できないものをクソだということにして
自分の心を安定させようとするやつが居るってだけのことだから。そういうやつは何千年も
前から居る。ほとんど人間という動物の習性だと思っていい。誰でもそういう状態にハマる
可能性がある。ハマってる最中はそいつは他をクソ呼ばわりするだけで新たな事は何も
学習しなくなるので馬鹿な状態が維持されて発展しない。

**デフォルトの名無しさん** · 2018/06/18(月) 07:01:11.25

>>563
いい加減に板を荒らすのやめろよ

特にここ最近はRubyスレを荒らしまくって何考えてんだ？

**デフォルトの名無しさん** · 2018/06/18(月) 07:13:46.91

>>564
歴史に何も学ばないやつに発展はない。
https://anond.hatelabo.jp/20171129214218
565はこの種のバカなことを引き起こしといてトンズラするタイプだな。
だいたいこのタイプは仕様が満たされるものだと過信してるタイプで
機能の堅牢性なんてまともにチェックしてない。

**デフォルトの名無しさん** · 2018/06/18(月) 07:25:45.84

歴史を学習した人間より科学を学習した自動運転の方が安全というのが
シンギュラリティの思想だよな

**デフォルトの名無しさん** · 2018/06/18(月) 08:03:14.74

>>564
それを「固定された思考態度」という。

**デフォルトの名無しさん** · 2018/06/18(月) 08:19:55.49

どっちも危険な盲信になりえる
>>564 みたいに一方的なのは危険

**デフォルトの名無しさん** · 2018/06/18(月) 10:03:33.26

「新しいものをバカみたいに導入しようとする奴は危険」ってのはまあその通りなんだが
上の「5年後にJava8を導入おじさん」も同じくらい危険人物な訳で

結局突き詰めてメリデメリをジャッジできる思考力ないだけのバカは開発を地獄にするってのは変わらんよね

**デフォルトの名無しさん** · 2018/06/18(月) 11:21:38.28

プロコンという語を覚えると便利だよ>メリデメリ
英語のプレゼンでprosとかconsとか見たことあるでしょ？まあ英語というかラテン語なんだけど。

**デフォルトの名無しさん** · 2018/06/18(月) 11:40:21.90

デメリット、コスト、人月の見積もり
見積もりを妄信するのも危険と言われる

**デフォルトの名無しさん** · 2018/06/18(月) 13:11:53.12

>>449
＞>>448
＞なんと！
＞日本語審査会で審議しないといけないな。

言い忘れたがこの混同は英語でもある
というか放射能漏れは leakage of radioactivity の直訳

**デフォルトの名無しさん** · 2018/06/18(月) 14:05:58.53

そもそも次世代言語が次世代なうちは個人の趣味プロぐらいにしか使わんだろ

**デフォルトの名無しさん** · 2018/06/18(月) 14:33:09.83

HaskellやElixirを実業務で使ってるところも
実在するわけだよな恐ろしい

**デフォルトの名無しさん** · 2018/06/18(月) 14:45:17.24

そのへんはむしろ枯れてるし実際ある

**デフォルトの名無しさん** · 2018/06/18(月) 14:48:34.03

まあHakellに関してはもう次世代というよりLispと似たようなポジションだということで

**デフォルトの名無しさん** · 2018/06/18(月) 15:30:15.87

ところで、またATS2に話を戻すんだけど、
日本語訳もあったしチュートリアルやってみてるんだけど
↓の再帰関数の停止性検査とやらで躓いている
ttp://jats-ug.metasepi.org/doc/ATS2/INT2PROGINATS/x2485.html

特に
fun isevn{n: nat} .<2*n>. (n: int n): bool = if n = 0 then true else isodd (n-1)
and isodd{n: nat} .<2*n+1>. (n: int n): bool = not(isevn(n))
が何故.<2 * n>.と.<2 * n + 1>になるか理解できん…
.<n>.と.<n + 1>.で大丈夫だと思ったんだが…
たぶんまだ、停止性メトリクスとやらが正しく理解できていないんだろうな…
誰か詳しく解説してくれないか？

**デフォルトの名無しさん** · 2018/06/18(月) 15:31:22.53

>>575
ドワンゴ（失笑）とかか？wwww

**デフォルトの名無しさん** · 2018/06/18(月) 15:37:03.09

ドワンゴが使ってると公言した言語を使ってる会社はドワンゴレベル

気を付けろwwwww

**デフォルトの名無しさん** · 2018/06/18(月) 16:10:43.68

ドワンゴってScala以外にもSwift, Kotlin(スマホアプリ)やReact(Typescript)やRustとかも使ってるからな…
開発事例は聞いたことないけどGoの勉強会とかもやってるし…
その基準だと、このスレでよく話題に挙がる言語はほとんど全てドワンゴレベルだな
ドワンゴレベルじゃない次世代言語はDartくらいか？www

**デフォルトの名無しさん** · 2018/06/18(月) 16:24:24.97

ドワンゴには、C++ の標準化委員の江添亮もいるし、Rust, Elixir, HDL もやってる。
クックパッドには、RubyVM を作った、笹田耕一もいる

基本は、Ruby。
Gradle で使うGroovy も、Ruby そっくり。
Elixir もそう。
jQuery のメソッドチェーンも、Ruby っぽい

無料のRails チュートリアルをやれば、すべてのフレームワークがわかる

**デフォルトの名無しさん** · 2018/06/18(月) 16:24:43.92

言語と品質には何の関係もないのを
日々実証し続けているドワンゴさん

**デフォルトの名無しさん** · 2018/06/18(月) 16:29:30.09

まだRubyのチュートリアルの話してんの？
Rubyっぽい、って、第一言語がRubyだからそう見えるだけだろ。

**デフォルトの名無しさん** · 2018/06/18(月) 16:40:07.48

フリーソフトがあるから品質と価格が無関係

**デフォルトの名無しさん** · 2018/06/18(月) 17:22:50.97

ドワンゴってエンジニアだけ見ると技術力高そうなのに
なんで成果が全部ゴミなんだろうな

**デフォルトの名無しさん** · 2018/06/18(月) 17:37:58.73

YouTube, AbemaTV は、広告
ニコ生は、有料
Showroom は、寄付

ビジネスモデルが異なるから、
1つのチャネルの視聴者数が1万を超えると、追い出す

乃木坂みたいに、数万人も見ると、追い出す。
広告が無いから、1万人以上が無料で見ると、電気代が払えず、赤字になる

**デフォルトの名無しさん** · 2018/06/18(月) 18:02:04.30

>>578
isevn.<n>.とisodd.<n+1>.だと
isevn 3 のメトリックは.<n>. = .<3>.
そこから呼ばれるisodd 2 のメトリックも.<n + 1> = .<3>.
減ってねえ！エラー！ってことじゃね
想像だけで試してないので違ってたらすまん

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

>>578
とある関数呼び出しの定義内に表れる再帰的呼び出しの
停止性マトリクスが、大元の関数呼び出しの停止性マトリクスから辞書順で下降していくことから停止性を担保しようというのが停止性マトリクスの意味。

そして停止性マトリクスの記述に表れる n は issven や isodd の引数そのものだということに注意

iseven、isodd の停止性マトリクスがそれぞれ n、n+1 だと、

iseven n の停止性マトリクス→n
iseven n の定義に出てくる isodd (n-1) の停止性マトリクス→n-1+1=n
減っていないから停止性が担保されない(NG)。

説明にあるように <n, 0> と <n,1> ならば、
iseven n の停止性マトリクス→<n,0>
iseven n の定義に出てくる isodd (n-1) の停止性マトリクス→<n-1,1> (下降している！OK)
isodd も同様に
isodd n の停止性マトリクス→<n,1>
isodd n の定義に出てくる iseven (n) の停止性マトリクス→<n,1> (下降している！OK)

そして<n,0>, <n,1> の代わりに n*2, n*2+1 を使っている(この代用が可能なことはわかるよね)。

**デフォルトの名無しさん** · 2018/06/18(月) 18:08:28.85

>>589
＞停止性マトリクスが、大元の関数呼び出しの停止性マトリクスから辞書順で下降していくことから停止性を担保しようというのが停止性マトリクスの意味。

この説明「下降していく」だと本当に再起をどんどん
実行していくみたいで間違ってるか。

とある関数呼び出しの停止性マトリクスよりも、
その関数の定義に表れる全ての再帰的呼び出しの停止性マトリクスのほうが辞書順で小さい、
というべきか。

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

>>589
＞isodd も同様に
＞isodd n の停止性マトリクス→<n,1>
＞isodd n の定義に出てくる iseven (n) の停止性マトリクス→<n,1> (下降している！OK)

最後の行は
isodd n の定義に出てくる iseven (n) の停止性マトリクス→<n,0> (下降している！OK)

の間違いでした

**デフォルトの名無しさん** · 2018/06/18(月) 18:32:21.74

偶数は、2*n

奇数は、2*n+1

**デフォルトの名無しさん** · 2018/06/18(月) 18:34:45.57

>>592
理解してないだろw

**デフォルトの名無しさん** · 2018/06/18(月) 18:51:32.37

安全装置のたぐいは損失を防ぐばかりで利益は全然ない
利益がないから理解できない人が続出

**デフォルトの名無しさん** · 2018/06/18(月) 18:58:41.11

>>589
ありがとう
冷静に計算していったら、確かにnとn+1じゃ減ってないからダメで
2*nと2*n+1だときちんと減ってるからOKってところまでは理解できた
でも、一体何を考えて<n,0>と<n,1>のタプル？のメトリクスが出てきたか全然分からない…

> そして<n,0>, <n,1> の代わりに n*2, n*2+1 を使っている(この代用が可能なことはわかるよね)。
すまない。俺はバカなんだ。分からないんで教えて下さい。

自分でも自分がどこまで分かっているのかさえよく分かっていないんだが、
たぶん、停止性メトリクスがきちんと減っているかどうかを計算する方法までは理解できたが、
きちんと減っている停止性メトリクスを導き出す方法が分かってないんだと思う

**デフォルトの名無しさん** · 2018/06/18(月) 19:23:14.64

>>595
＞すまない。俺はバカなんだ。分からないんで教えて下さい。

辞書順を保ったまま <n, 0>, <n,1> をそれぞれ 2*n, 2*n+1 で置き換えられる
3*nとか4nでもいいけど2つしかないから2nで十分

例

fun f
{n:nat} .<3*n>.
(n: int n) : bool =
if n = 0 then true else g (n-1)
and g
{n:nat} .<3*n+2>.
(n: int n) : bool = not (h (n))
and h
{n:nat} .<3*n+1>.
(n: int n) : bool = not (f (n))

**デフォルトの名無しさん** · 2018/06/18(月) 19:24:20.04

>>595
引数のnと、isoddとisevnの2つの関数の区別(+0, +1)を位取り(*2)して足してるだけじゃないかな……

**デフォルトの名無しさん** · 2018/06/18(月) 19:33:04.83

>>581
全部そうだよ

やっぱりJavaやC、Pythonが最終的に一番良いってことだな
新しいものに飛び付いてるとドワンゴになるぞ

**デフォルトの名無しさん** · 2018/06/18(月) 19:52:57.33

ドワンゴはc++みたいなもんだな。
とりあえず新言語(新機能)の実験台になってもらえるっていう。

**デフォルトの名無しさん** · 2018/06/18(月) 20:40:04.20

>>599
つまりドワンゴがスレタイ言語は
ほぼ使えないと証明してくれてるってことだな

**デフォルトの名無しさん** · 2018/06/18(月) 20:46:12.17

ドワンゴは本当のC++プログラマーも募集してるしな

**デフォルトの名無しさん** · 2018/06/18(月) 21:40:32.50

やきそば焼かせてるようなクズ会社にいくのか？

**デフォルトの名無しさん** · 2018/06/18(月) 21:49:26.33

bio100%の戀塚もいるんだよな
いかんせん上がアホだから

**デフォルトの名無しさん** · 2018/06/18(月) 21:55:35.52

>>596
辞書順を保ったまま置き換えられるってのが何をしてるのかイマイチよく分からんが
とりあえず、2つの関数で相互再帰なら2n、3つなら3nといった感じ……なのか？
うーん…まだ勉強し始めたばかりだし、やってればそのうち分かるようになるかぁ…
あざっす。

**デフォルトの名無しさん** · 2018/06/18(月) 22:18:33.96

>>604
いやここで堪えて理解しておくべき。
引数から算出できて、再帰で減るものを何か考えてそれを停止性マトリクスとする。

値そのものじゃなく大小関係だけが大事だから、
m が 0 と 1 のどちらかしかなければ
<n, m> の代わりに n*2+m で ok ってこと

例
<5,0> は <4,1> より大 ⇔ 5*2+0 は 4*2+1 より大

**デフォルトの名無しさん** · 2018/06/18(月) 22:30:23.80

ちなみに辞書順というのは停止性メトリクスのタプルについて、

先頭の要素同士を比較、等しければ次の要素同士を比較、また等しければそのまた次の以下略…
という風に比較したときの順序関係

**デフォルトの名無しさん** · 2018/06/18(月) 22:47:52.93

上で散々マトリクスと誤記しているメトリクスはこの場合「(停まるまでの)距離」という意味

**デフォルトの名無しさん** · 2018/06/18(月) 23:09:05.63

>>605
なるほど。(n, 0)と(n, 1)が2nと2n+1に変換できることまでは分かった。ありがたい。
でも、そもそもの話として(n, 0)と(n, 1)っていうのが
一体何を考えて導き出されたのかが分からないんだよ…
チュートリアルに「isevn と isodd に (n, 0) と (n, 1) のメトリクスを与えれば、
これら2つの関数の停止性もまた検査できることは明白です。」って
書いてあるんだけど、俺にとっては全然明白じゃない…
何をどう考えたら(n, 0)と(n, 1)のメトリクスを与えようと思うんだ…？

現状、分かっているのは2nと2n+1ならメトリクスが減っているからOKってところと
(n, 0)と(n, 1)のメトリクスが2nと2n+1に変換できるってところまで…
一番肝心な部分が理解できていない気がする…

**デフォルトの名無しさん** · 2018/06/18(月) 23:17:38.17

なんの話か分からないけどこういう奴らが使ってる技術は使いたくない

**デフォルトの名無しさん** · 2018/06/19(火) 00:28:07.36

ATSは依存型言語の中でも奇抜な方だと思うよ
Coqとソフトウェアの基礎の方が易しいと思う

**デフォルトの名無しさん** · 2018/06/19(火) 01:44:59.48

CoqとAgdaは敬遠してるんだよね…
あの二つはプログラミング言語じゃなくて証明支援器だって聞いてるから…
オレは別にPCに証明問題を解くのを手伝ってもらいたいんじゃなくて、
従来の型システムを発展させた依存型とかを使ったより安全な
プログラミングを行うの方法が知りたいんだよって思って…
けど、学ぶ順番としてはCoqが先のほうが良かったのかな？
でも、Coqだとどうにもモチベーションが…

あと、ついでに線形型も学びたかった……
Rustの所有権・借用・ライフタイムはほぼ理解できてるんでそれほど難しくはないだろうと…
まず、依存型で躓いてるんで線形型までたどり着いていない…
んー……一度に色々やろうとし過ぎか…(´・ω・｀)

**デフォルトの名無しさん** · 2018/06/19(火) 02:53:39.62

Idris とかはどうなのよ

**デフォルトの名無しさん** · 2018/06/19(火) 04:24:16.98

>>608
この場合呼び出しのたびに変化するものが、引数のnと「どちらの関数を呼ぶか」という
2つしかないんだから、呼び出しのたびに減る式を作ろうとしたらこれを組み合わせるしかない
後はパズルだろ

**デフォルトの名無しさん** · 2018/06/19(火) 07:30:15.96

全てのｎについて(n, 1)＞(n, 0)と2n+1＞２ｎは同値だから当たり前だろ。

**デフォルトの名無しさん** · 2018/06/19(火) 08:33:24.05

わかりにくい記法は自分で自由にわかりやすい記法に変換すればわかる
Cのポインタの記法と同じ
自由に考える方が早い
偉い人にいちいち許可を求めたり質問したりすると時間がかかる

**デフォルトの名無しさん** · 2018/06/19(火) 08:33:59.97

>>613
んー…１日置いたらやっと分かったような気がする…
気がしてるだけかもだけどあとは自力でどうにか理解できそう…
まあ、新しい概念を覚えるときはどうしても時間が掛かるものだし、
あとは腑に落ちるまでサンプルコードひたすら写経したりするか…
皆ありがとう

>>610
ATSの依存型は奇抜なの？
他の依存型がある言語も似たようなことやるんじゃないの？

**デフォルトの名無しさん** · 2018/06/19(火) 08:51:24.21

コンパイル時のメタプログラミングはみんな奇抜

**デフォルトの名無しさん** · 2018/06/19(火) 19:52:01.92

型を静的に解析しつつマクロみたいに評価順序を入れ替えようってのが
そもそも無理があるんだよ。

**デフォルトの名無しさん** · 2018/06/19(火) 20:25:55.46

そもそも型に期待しすぎるのがキモい
型の役目なんてOCamlくらいでちょうどいいのに

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

型安全のためにDRY原則すら無視してるのあるからな

**デフォルトの名無しさん** · 2018/06/20(水) 01:28:01.72

型安全を崩す水準のDRYはかなり悪い印象があるな
共通化すべきでないものまで共通化してるのではと

**デフォルトの名無しさん** · 2018/06/20(水) 11:07:04.58

一生型書いてろ
俺はプロダクト書くからよ

**デフォルトの名無しさん** · 2018/06/20(水) 11:47:35.83

人は型かプロダクトかどっちかしか書けないからなｗ

**デフォルトの名無しさん** · 2018/06/20(水) 13:04:18.23

>>620
ジェネリクスやインターフェース正しく使ってれば
DRY原則無視しなきゃ型安全守れないこととかほぼ無いだろ
どんなコード書いてるんだよ？

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

型って建物に例えると水準器だろ
柱がまっすぐ立ってるか見るための補助具

補助具ばっか作って家が建つのか？

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

一生水準器使ってろ
俺は家建てるからよ

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

そうか、じゃあ動的言語で作ったプログラムって例えるなら水準器なしで建てられた家なのか…
それは欠陥住宅というもので工期が遅れてる建物よりもっと害悪だと思うんだがそれは…

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

いや単なる犬小屋欲しいだけなのに設計書に一年くらい時間かけるようなもんだ。

**デフォルトの名無しさん** · 2018/06/20(水) 22:31:25.72

>>628
犬小屋ってどれくらいの規模のものを指してるの？
リソース３つくらいのweb apiサーバとか？

**デフォルトの名無しさん** · 2018/06/20(水) 22:35:54.20

>>625
それだけじゃないよ。メンテナンスという観点でも必要。
いわば動的言語なら釘で家を建てるけど、
型付きなら、簡単に取り替えられるようにボルトで止まってる。
ちゃんとネジに印がついていて交換ミスも起こりにくい

**デフォルトの名無しさん** · 2018/06/20(水) 22:37:33.02

例え話をするエンジニアは無能の法則

**デフォルトの名無しさん** · 2018/06/20(水) 22:45:13.44

>>629
犬小屋なんだから日曜大工、つまり個人の趣味レベルのものでしょ

**デフォルトの名無しさん** · 2018/06/20(水) 23:03:24.49

型は水準器というより物差しに近い

**デフォルトの名無しさん** · 2018/06/21(木) 00:46:09.92

オプションでも型制約無い言語なんてもうJSとRubyくらいじやね？

**デフォルトの名無しさん** · 2018/06/21(木) 01:00:00.42

Lua忘れるとか

**デフォルトの名無しさん** · 2018/06/21(木) 01:15:00.23

c++のstd::chornoみたいな設計は行き過ぎた型安全だと思う

**デフォルトの名無しさん** · 2018/06/21(木) 01:16:19.88

C++は存在そのものが行き過ぎている

**デフォルトの名無しさん** · 2018/06/21(木) 02:30:14.21

永遠の次世代言語

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

C++はやべーよ
でも誰も逃げ出せない

**デフォルトの名無しさん** · 2018/06/21(木) 07:30:10.88

まさに魔王

**デフォルトの名無しさん** · 2018/06/21(木) 12:02:43.31

逃げ出したいけど環境がっつりだから無理だわ

**デフォルトの名無しさん** · 2018/06/21(木) 12:22:25.31

rubyは絶対に型を書きたくないから
コメントか外部ファイルに型を書くようにするらしいぞ

**デフォルトの名無しさん** · 2018/06/21(木) 12:26:56.39

0から何か作ろうって時にC++だけは選びたくない

**デフォルトの名無しさん** · 2018/06/21(木) 13:31:50.47

俺はアプリ屋だからコアの部分は Windows、
Android、iOS、MacOS のどれでも使える c++
UI 側を書く各言語から呼び出して使う

**デフォルトの名無しさん** · 2018/06/21(木) 13:35:39.24

あいかわらずRubyの人たちは何がしたいのかよくわからんな

**デフォルトの名無しさん** · 2018/06/21(木) 13:52:08.71

C/C++の型はアドレスやサイズの計算に使う
低級言語だから型が役に立つ
高級言語がC++の真似をする必要はないんだよ
型を書かない高級言語はたくさんある

**デフォルトの名無しさん** · 2018/06/21(木) 13:55:42.09

コードに型を書かないと後で分からなくなるから結局コメントで型を書くことになるゴミ

**デフォルトの名無しさん** · 2018/06/21(木) 13:58:07.14

メソッド名とか使われ方とかコメントとかプログラマのクセとかからAIが型推論してくれるんだろう

**デフォルトの名無しさん** · 2018/06/21(木) 14:00:01.02

AIは確率過程だからコードみたいな根幹部分には使いたくないな

**デフォルトの名無しさん** · 2018/06/21(木) 14:11:21.05

AIを使ったエラー検出は今後のトレンドになるだろうね
技術進歩に伴って緩やかに型は不要になっていくだろう
IntelliCodeの発展形としてMSがやりそう

**デフォルトの名無しさん** · 2018/06/21(木) 14:33:42.30

そのAIをC++で作らされたりしてな

**デフォルトの名無しさん** · 2018/06/21(木) 14:34:54.31

AIの得意分野はどっちかが必ず勝つ対戦ゲームというブルーオーシャン
レッドオーシャンに飛び込んでも勝てると思うのは確率的に間違ってる

**デフォルトの名無しさん** · 2018/06/21(木) 14:46:28.87

>>646
とあるオブジェクトを扱うアルゴリズムが要求するのは型じゃなく
整数っぽいものを返すsize() メソッドは実装していること、
とかそういう制約だよな

**デフォルトの名無しさん** · 2018/06/21(木) 20:54:11.38

>>642
python2の型ヒントみたいなやり方するってことかな。まあ実行時には必要ない情報だから
それもリーズナブルな解だと思うけどね。使えるものを早く出してくれさえすれば。

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

型推論とかAIで検出とかバカほど無駄なことに計算資源使おうとするのな。
そんなカスみたいな機能に資源使うくらいならコンパイル速度上げた方がよっぽどマシ。

**デフォルトの名無しさん** · 2018/06/21(木) 23:52:49.86

>>655
えぇ…
AIは知らんが型推論のほうはコンパイル速度重視のGoでさえ使ってる技術だぞ

**デフォルトの名無しさん** · 2018/06/22(金) 00:03:19.61

単純な右から左の型推論は余計な型名解決が減る分むしろコンパイル速くなるだろ

**デフォルトの名無しさん** · 2018/06/22(金) 00:15:01.47

おじいちゃんは自分がよく知らないものは全部無駄に見える生き物だから…

**デフォルトの名無しさん** · 2018/06/22(金) 00:18:04.51

>>657
単純な場合はむしろ速くなるの？それは知らんかった
ただ、どっちにしろ型推論ってそんなに計算リソースを消費するイメージないんだけど…

**デフォルトの名無しさん** · 2018/06/22(金) 00:42:37.48

速くなる訳ねーだろ。。
https://cocopon.me/blog/2015/03/swift-compilation-time/
なんでこいつらこんな簡単に騙されるの？

**デフォルトの名無しさん** · 2018/06/22(金) 00:43:40.93

型推論の計算コストは有効範囲と言語の持ってる型システムの表現力でけっこう変わるよ
関数内でのみ有効なのと関数宣言でも使えるのだと随分違う
既存の、コーディング中に型を書くのが苦にならないような言語だと後から型推論追加しても旨味が少ないと思う

Rustはコンパイル速度を気にしてかライフタイム関係の推論が面倒だったのか知らんけど、関数内でしか型推論有効にしなかったのは個人的にマイナス

**デフォルトの名無しさん** · 2018/06/22(金) 00:58:36.71

>>660
せめてgoでの比較持ってこいよ

**デフォルトの名無しさん** · 2018/06/22(金) 01:02:01.33

>>660
結局コンパイラがどうやって推論してるかはソース見てみない限り分からないからな
遅くなる場合もあれば、ほとんど変わらない場合もあるだろうし、何とも言えないな…

>>661
俺は逆に関数宣言の型の情報まで推論されるのは好きじゃないな
推論するのはローカル変数だけにしてほしい
まぁ、そこら辺は好みの問題だな