次世代言語15 Go Rust Swift Kotlin TypeScript

**デフォルトの名無しさん** · 2018/11/04(日) 20:30:10.42

スレタイ以外の言語もok

前スレ
次世代言語14 Elixir Crystal Julia Rust Swift
https://itest.5ch.net/mevius/test/read.cgi/tech/1536668904

**デフォルトの名無しさん** · 2019/03/09(土) 14:07:25.26

仕様と実装言語が独立しているレベルになったら言語の布教に不都合だから
実装は仕様に依存するぐらいがみんな好きでしょ

**デフォルトの名無しさん** · 2019/03/09(土) 19:48:43.49

>>497
> 動的型を圧倒したというのは皮肉な話

そもそも言語機能としてのinterfaceは動的型（具体的にはSmalktalk）のダックタイピング（当時はそうは言わなかったが）を
静的型のメリットを殺さずにやるアイデアから考案されたんだから順当だろう
http://www.cs.utexas.edu/~wcook/papers/OOPSLA89/interfaces.pdf

**デフォルトの名無しさん** · 2019/03/10(日) 13:14:29.15

C++はvirtualを使わない技術、Haskellはラムダを使わない技術を磨いている
Rustも同様
virtualが動的型を圧倒したとか言ってるのは時代錯誤

**デフォルトの名無しさん** · 2019/03/10(日) 20:02:03.91

ラムダを使わない技術ってなんなん？

**デフォルトの名無しさん** · 2019/03/10(日) 20:02:56.59

なんだろね
ポイントフリースタイルの話かな

**デフォルトの名無しさん** · 2019/03/10(日) 20:22:04.07

ラムダを使わずコンビネータを使う、とか言ったりして。

**デフォルトの名無しさん** · 2019/03/10(日) 20:48:07.67

quickSort :: Ord a => [a] -> [a]
でも昇順とか降順とかを変えるのが大変だな

**デフォルトの名無しさん** · 2019/03/10(日) 22:35:21.02

sortByしたくなったらどうするんよ？
ラムダなしHaskellとかコード量が2倍で済まなさそう。

**デフォルトの名無しさん** · 2019/03/10(日) 23:20:22.27

sortByなんて実用的なタスクでしか使わないだろ
つまりHaskellには不要

**デフォルトの名無しさん** · 2019/03/10(日) 23:54:02.27

そもそも動的型をdisることに実用性があるのかどうか考えたか？
それとも何も考えてなかったのにHaskellと聞いたら急に頭が良くなったのか？

**デフォルトの名無しさん** · 2019/03/10(日) 23:56:13.89

ラムダを使わない技術って何なの
説明しろよ

**デフォルトの名無しさん** · 2019/03/11(月) 01:18:43.16

会話が成り立ってなくて怖いんだけど

**デフォルトの名無しさん** · 2019/03/11(月) 02:21:22.63

いや型無し糞言語ガイジは死ねよ、時代遅れの爺

**デフォルトの名無しさん** · 2019/03/11(月) 09:24:00.27

そもそも実行時に命令を作り出すというのは、動的型付けじゃないとできないのでは？ eval

**デフォルトの名無しさん** · 2019/03/11(月) 09:38:26.34

動的もコンパイルするし、静的もRepl あるし

**デフォルトの名無しさん** · 2019/03/11(月) 11:48:34.91

>>517
s='a+a'
a=1
print(eval(s)) #2

a=2.0
print(eval(s)) #4.0

**デフォルトの名無しさん** · 2019/03/11(月) 11:57:22.45

REPL と動的実行のeval は違う。

a=input()　#abcと入力
print(eval(s))　#abcabc と出力

s=input()　# 3**2 と入力
print(eval(s))　#9 と出力

**デフォルトの名無しさん** · 2019/03/11(月) 12:30:19.49

動的実行には、複数の式を実行する　exec がある。

exec("""
total = 0
for i in range(5):
　print(i)
　total += i

print(total)
""")

これを利用すれば、プログラムを変更しないで外からの入力で動作を変えたりできる。

**デフォルトの名無しさん** · 2019/03/11(月) 12:44:28.78

何か変なのに粘着されてるじゃん

**デフォルトの名無しさん** · 2019/03/11(月) 12:49:45.69

>>520
そうだね重大なセキュリティホールだね
お願いだから消えてくれ

**デフォルトの名無しさん** · 2019/03/11(月) 16:46:34.67

>>518
そんなの単にevalに渡すコンテキストの違いじゃん
実行時に命令生成することの本質じゃない

**デフォルトの名無しさん** · 2019/03/11(月) 20:14:35.05

文字列使えば任意のコードが実行できる！文字列最強！みたいなバカ理論。

**デフォルトの名無しさん** · 2019/03/11(月) 20:16:58.60

それ社内のエースが言っててワロタ

**デフォルトの名無しさん** · 2019/03/11(月) 20:49:09.16

構文木いじれるLispの方が便利じゃね？

**デフォルトの名無しさん** · 2019/03/12(火) 12:12:04.79

構文木オブジェクトなら左括弧と右括弧の対応をいじる脆弱性はない
文字列を使わないことがオブジェクト指向の定義と言えないこともない
オブジェクト指向の定義多すぎ

**デフォルトの名無しさん** · 2019/03/12(火) 12:34:20.82

> 文字列を使わないことがオブジェクト指向の定義

ハハハ

**デフォルトの名無しさん** · 2019/03/12(火) 13:10:26.07

笑うことも定義か
staticおじさんを笑うように

**デフォルトの名無しさん** · 2019/03/12(火) 13:24:41.15

定義を教えられないから目で盗み空気を読み忖度した結果として定義が増える

**デフォルトの名無しさん** · 2019/03/12(火) 13:33:15.64

ﾊﾊｯ

**デフォルトの名無しさん** · 2019/03/13(水) 21:17:11.81

まあテクニカルタームにしがみつく奴はバカしかいないよ。

**デフォルトの名無しさん** · 2019/03/13(水) 21:26:00.10

ハッ

**デフォルトの名無しさん** · 2019/03/13(水) 22:20:22.61

ﾊﾊｯ

**デフォルトの名無しさん** · 2019/03/14(木) 10:58:18.04

差別発言が日常茶飯事なのと専門用語のマナーを守ることとのギャップがものすごい

**デフォルトの名無しさん** · 2019/03/14(木) 23:49:16.54

>>535
そういうバランスが壊れてるところプログラマーっていう人種の典型

**デフォルトの名無しさん** · 2019/03/15(金) 17:46:48.87

プログラムはおいといてデバッグに必要なのは典型的でないケースを1個見つけること
1個だからといって無視しないこと

**デフォルトの名無しさん** · 2019/03/17(日) 11:52:05.42

型無し糞ガイジの老害が死滅すれば済む話
頭のアホ毛＄から腐臭が漂ってくるんだよ、早く死ね

**デフォルトの名無しさん** · 2019/03/17(日) 14:54:23.26

エディタを終了してからテストを実行するのはターン制だから古臭いんだな
リアルタイムこそが現実であり次世代であるはずなのに一体なぜターン制が滅びないのか

**デフォルトの名無しさん** · 2019/03/17(日) 17:44:29.53

>>538
おだいじに。ちゃんとお薬のむんだよ。

**デフォルトの名無しさん** · 2019/03/17(日) 18:24:15.45

>>540
薬を飲むべきはおまえさんやで、型無し糞ガイジｗ

**デフォルトの名無しさん** · 2019/03/23(土) 08:00:57.82

次世代言語として必須機能はなんですか？

**デフォルトの名無しさん** · 2019/03/23(土) 09:10:22.60

高速で軽量、堅牢な非同期処理のサポート
デフォルト実装を定義できるインターフェイス（and/or 型クラス）
高度な型推論（もとより静的型）
高速なコンパイルとコンパクトな実行ファイル（非AltoJS、JVM言語）
関連して、セルフホスティングやブートストラップは完了済み

**デフォルトの名無しさん** · 2019/03/23(土) 09:23:43.23

>>54
様々なポリシーの元に設計されて良いだろうから必須なんて機能は無いんじゃないか

**デフォルトの名無しさん** · 2019/03/23(土) 09:24:21.62

>>544
>>542宛だった

**デフォルトの名無しさん** · 2019/03/23(土) 11:11:33.27

何を作りたいかによるよね。作りたいものが作りやすければ良いわけだから。

**デフォルトの名無しさん** · 2019/03/23(土) 22:35:21.72

皆さん的にvlangどうなの？

**デフォルトの名無しさん** · 2019/03/23(土) 23:03:36.39

実物待ちじゃないの

**デフォルトの名無しさん** · 2019/03/24(日) 13:56:01.89

ぶっちゃけTypeScriptが強最やろ

**デフォルトの名無しさん** · 2019/03/24(日) 14:23:51.27

強いかはともかく、最も美しいプログラミング言語の一つではある

**デフォルトの名無しさん** · 2019/03/24(日) 16:01:57.35

tsいいんだがjavascriptの呪縛から解き放ってやりたい感

**デフォルトの名無しさん** · 2019/03/24(日) 16:09:10.35

今のesならそんなに捨てたもんでもないと思うが。
まぁでも、tsにclassは要らなかったな。

**デフォルトの名無しさん** · 2019/03/24(日) 16:18:49.96

しょせんパフォーマンスでない言語

**デフォルトの名無しさん** · 2019/03/24(日) 16:34:58.29

esにもクラスはなくても良かったけどデコレータは早く来てほしいね
デコレータ風に組めなくもないけど面倒だしな

**デフォルトの名無しさん** · 2019/03/24(日) 18:01:12.81

tsはjsの呪縛でガンガンに縛られてるから全然いい言語に見えない

共有型からの流れのせいでコードに無駄な型判定が入ってて全然スマートじゃない

**デフォルトの名無しさん** · 2019/03/24(日) 19:00:10.91

>共有型からの流れのせいでコードに無駄な型判定が入ってて全然スマートじゃない

ちょっとピンとこないけど具体的にはどういう記述？

**デフォルトの名無しさん** · 2019/03/24(日) 19:23:03.00

http://js.studio-kingdom.com/typescript/handbook/advanced_types

型判定のiｆなどが邪魔すぎる
こういうのを見てスマートだと感じるなら毒されている

**デフォルトの名無しさん** · 2019/03/24(日) 19:32:49.50

それは無駄な判定とは思わないが、どう記述出来たらスマートだと言うんだろう。
パターンマッチとか？

**デフォルトの名無しさん** · 2019/03/24(日) 19:37:55.56

無駄っつーかanyって言ってるのに実際は2つの型しか認めないのは無責任やな

**デフォルトの名無しさん** · 2019/03/24(日) 19:44:07.97

>>557
直和型をパターンマッチで処理切り分けるのは、関数型言語からの流れで最近の流行りだと思うんだけどね
if 文で書くのはダサいな

>>559
any がダメだから string | number と書くというのが共用体型じゃないの？おれもtsはよく知らないんだけど

パターンマッチで切り分けて、すべての可能性を記述してない場合にはエラーにしてほしいね

**デフォルトの名無しさん** · 2019/03/24(日) 20:34:17.47

まぁパターンマッチ構文で多少記述がシンプルになるならそれもいいけど、逆に専用の構文に頼らずに
ifやswitchを使っても同等のことができているというのがいいところだと思うがなぁ。
シンタックスシュガーとして入れるなら後からでもできるんじゃね？

>パターンマッチで切り分けて、すべての可能性を記述してない場合にはエラーにしてほしいね

それをエラーにするような記述は今でもできる。パターンマッチなんてなくても。

**デフォルトの名無しさん** · 2019/03/24(日) 21:15:12.88

>>561
そんなのなくない？
String | Date | Number
だったとして、StringとNumberの処理しか書いてなくってそれがエラーにはならんやろ

やっぱScala最強やね
コンパイル速度ゴミで死んでしまったが

**デフォルトの名無しさん** · 2019/03/24(日) 21:22:23.00

>>562
TypeScriptは Discriminated Union 使えるよ
メンバのリテラル値によって型をマッチさせるという中々面白い仕様

**デフォルトの名無しさん** · 2019/03/24(日) 21:32:02.61

sbt言うほど遅いか？
Scala2.13でまたちょっと速くなるみたいだし
それにScala3まであと一年と考えるとScala最強説が蘇る可能性もあるで

**デフォルトの名無しさん** · 2019/03/24(日) 21:42:20.21

scala死んだ理由どう考えてもバージョン上がる度にコンパイル通らなくなる互換性のなさだろ
3なんかにしたら爆死以外見えない

**デフォルトの名無しさん** · 2019/03/24(日) 22:02:19.88

>>563
ここら辺見て ts 勉強させてもらったよ https://qiita.com/kobanyan/items/ca56df27de50ec267995
Discriminated Union はすべての可能性を記述してない場合にエラーとするための仕組みになってないだろ
その下に書いてある Exhaustiveness checking っていうのが求めてるものだ

でも、
--strictNullChecks つけて戻り値の型のでチェックするのはswitchの下にreturn 文書いちゃったらスリ抜けちゃわない？
default: return assertNever(s) を記述することでチェックするのは、その記述が無くてもエラーにしてほしいんだけど？

**デフォルトの名無しさん** · 2019/03/24(日) 22:17:38.55

>default: return assertNever(s) を記述することでチェックするのは、その記述が無くてもエラーにしてほしいんだけど？

どのパターンにもマッチしない場合に何もしないという場合はあるわけだから、エラーにするのか
しないのかを示さなきゃならないのは仕方ないだろう。
strictNullChecks付けるのを忘れるからデフォルトでonにしてほしいとか言ってるようなもん。

**デフォルトの名無しさん** · 2019/03/24(日) 22:46:49.41

>>567
case 文で全パターンを網羅できない場合には default 必須にして欲しい
どのパターンにもマッチしない場合に何もしないときは、その default の処理を空っぽにする
これを強制したい

**デフォルトの名無しさん** · 2019/03/24(日) 22:52:15.99

それはlintでやればいい。

**デフォルトの名無しさん** · 2019/03/24(日) 23:24:23.33

みんなが Lint かけてくれるわけじゃないので、コンパイル時チェックが望ましい
特に新しい言語作るのならばそうすべき

**デフォルトの名無しさん** · 2019/03/24(日) 23:25:57.15

あと、>>563は、言語の機能と、コーディングパターンの区別がついてないよね？

**デフォルトの名無しさん** · 2019/03/24(日) 23:29:21.26

>>571
言語の機能として公式ドキュメントに記載されてるんだよ
https://www.typescriptlang.org/docs/handbook/advanced-types.html

**デフォルトの名無しさん** · 2019/03/24(日) 23:54:07.40

>>572
Discriminated Union とか Exhaustiveness checking は、言語機能じゃなくて
いくつかの言語機能を組み合わせて実現可能なコーディングパターンの解説をしているように見えるよ？
そのドキュメントが Specification じゃなくて Hand book だし

**デフォルトの名無しさん** · 2019/03/25(月) 00:04:21.99

>>570
そういう腐った現場で強制してもコンパイル通すためだけのくそハックが横行するだけ。
事態をもっとややこしくする。

**デフォルトの名無しさん** · 2019/03/25(月) 00:28:45.64

>>574
コンパイル通すためのハックしてることがコード見ただけで分かるのが重要

**デフォルトの名無しさん** · 2019/03/25(月) 07:59:56.31

>>570

lintすら不要と思っている人が>>560のようなチェックをしたいと思うシチュエーションが考えにくいが。
PLがメンバーに強制するならlintごと使わせればいいわけだしな。

**デフォルトの名無しさん** · 2019/03/25(月) 09:18:04.90

次世代言語を名乗るなら網羅性がチェックされたパターンマッチ構文は必須でしょ
TypeScriptのswitch文がJSからのしがらみで前時代的なのは仕方ない

**デフォルトの名無しさん** · 2019/03/25(月) 13:08:18.82

マイクロソフトの「TypeScript」など上昇--RedMonkプログラミング言語ランキング
Liam Tung （Special to ZDNet.com）翻訳校正：編集部 2019年03月25日 12時26分
https://japan.zdnet.com/article/35134639/

　Microsoftのプログラミング言語「TypeScipt」の人気が上昇しており、Appleの
「Swift」に続く順位についた。(中略)

　TypeScriptは2018年8月に発表された前回の調査から4つ順位を上げた。JavaScriptは
首位となっている。TypeScriptの最新の順位は、RedMonkが「これまでで最も成長の速い
プログラミング言語」とするSwiftの1つ下だ。

　RedMonkのStephen O'Grady氏は、「TypeScriptは確かにJavaScriptと近いことや、オプ
ションの静的型チェックなどの安全性を実現する機能からメリットを得ている。だが、機能
だけではこのペースで大きく前進できない。成長中の幅広いプロジェクトに活用されて
いるはずであり、これら全てが、TypeScriptの成長が目覚ましく、持続性のあるものと
なっている理由を示している」と説明している。(中略)

　TypeScriptよりも急速に成長している言語は「Kotlin」だ。Kotlinは前回から8ランク
アップし、今回の調査では20位となった。O'Grady氏によると、Kotlinの成長速度はSwiftに
次ぐレベルだという。

　KotlinはGitHubの「2018 Octoverse」レポートでも、GitHubで最もコントリビューター
人口が増えている言語となった。KotlinはGoogleが公式にサポートしているAndroidアプリ
開発言語であることからAndroidのアプリ開発者に人気で、Googleによると「Google
Play」で提供されているAndroidアプリのトップ1000のうち、27％でKotlinが使用されて
いるという。(後略)

**デフォルトの名無しさん** · 2019/03/25(月) 13:08:57.00

purescript全然流行ってないぞｗ
やっぱts人気なのはjs互換だから。良くも悪くも。

**デフォルトの名無しさん** · 2019/03/25(月) 13:17:36.44

npmがあってこそ

**デフォルトの名無しさん** · 2019/03/25(月) 13:40:39.94

tsといいkotlinといい、言語を流行らせるならまずは開発環境が大事というのがよくわかる結果だな

**デフォルトの名無しさん** · 2019/03/25(月) 13:43:55.66

Kotlin 万歳

**デフォルトの名無しさん** · 2019/03/25(月) 13:45:37.65

JSは言語というより環境
つまりSmalltalkがやりたかったことをやってるのが大事なポイントだ
それとJavaがやりたかったこと (JNI禁止) もまあやってる

**デフォルトの名無しさん** · 2019/03/25(月) 13:46:17.07

>>581
開発環境と作ったプログラム動かす環境、更にそれで確実に金儲けが出来そうだと思わせる状況があるとよい。

**デフォルトの名無しさん** · 2019/03/25(月) 14:07:09.12

まぁRailsもそうだったけど「これ作るならこれ！」みたいな洗脳が上手くできるかどうかだよね

**デフォルトの名無しさん** · 2019/03/25(月) 14:19:36.61

でも洗脳を解いてやったらC/C++をすらすら書けるようになるわけじゃないし
宗教があるのは難易度を下げるのがメインで洗脳は副産物

**デフォルトの名無しさん** · 2019/03/25(月) 15:04:53.80

Javaも部分的かつ牛歩だけど、モダン機能に追従していってる
https://qiita.com/nowokay/items/0e860819b6ffb1aca90a#switch%E5%BC%8F

言語でなく環境の方でもGraalVMを進めてるし一応止まってはいない感じ

**デフォルトの名無しさん** · 2019/03/25(月) 15:17:23.11

Javaは本質的な不便さから目を背けてミーハーな目立つ機能をつまみ食いしてる印象
いいかげん例外透過やクッソ使いづらい非同期APIをなんとかしろ

**デフォルトの名無しさん** · 2019/03/25(月) 15:51:46.88

javaは中間コンパイルしたあとのソースを見るとやる気なくなる

**デフォルトの名無しさん** · 2019/03/25(月) 16:00:12.57

Java「じゃあ互換性切り捨てて小鳥に寄せます」
ってならね？

**デフォルトの名無しさん** · 2019/03/25(月) 17:45:18.30

>>578
金で操作できるランキングに価値ねえよ
上位言語が企業のステマ言語って時点で疑問持てよ

**デフォルトの名無しさん** · 2019/03/25(月) 18:34:27.56

そもそもnumberとstringをいれれる型が邪魔すぎる

**デフォルトの名無しさん** · 2019/03/25(月) 18:51:00.60

javascriptの制限のせいでtypescriptには従来の言語のような関数オーバーロードがない
あるのは関数シグネチャーのエイリアスのようなもので中ではifなどで型の判定をして使い分けてる
非常に泥臭い

**デフォルトの名無しさん** · 2019/03/25(月) 18:55:41.13

パターンマッチはクソださいので必要ない

**デフォルトの名無しさん** · 2019/03/25(月) 19:03:37.93

javascript離れて独自拡張したら行く末はelmやpurescriptコースだからな。
そうなったtypescriptは誰も使わないし、
js互換の第二のtypescriptが登場してそっちに流れるだけ。
そうでないと言うのならelmやpurescriptが閑古鳥な理由を説明してほしい。

**デフォルトの名無しさん** · 2019/03/25(月) 19:05:06.35

ダサいとかいう非論理的な言葉で要不要を語るんじゃあない

**デフォルトの名無しさん** · 2019/03/25(月) 19:06:59.78

＞じゃあない

ださい

**デフォルトの名無しさん** · 2019/03/25(月) 19:11:19.73

>>593
tsのunionは、関数の引数だけじゃなくて、戻り値とかオブジェクトのプロパティにも使える
関数オーバーロードの変わりに使うものだと考えるのは、少しズレてる

**デフォルトの名無しさん** · 2019/03/25(月) 19:31:47.11

numとstringを入れられるプロパティの存在意義は？

**デフォルトの名無しさん** · 2019/03/25(月) 20:32:23.93

>>599
これは number と string とかだけじゃなくて、同じ interface を継承しないオブジェクトをひとつのプロパティに格納できたりする機能なんだよ
利点は intetface を用意して継承するよりも記述が減ることかな
普通の静的型付け言語だと any みたいな型を使う事になるけど、それよりもチェックを少し厳しくできるのが利点だね

**デフォルトの名無しさん** · 2019/03/25(月) 20:42:39.81

>>597
https://i.imgur.com/rQXUs9z.jpg

**デフォルトの名無しさん** · 2019/03/25(月) 20:47:57.44

正直オーバーロードは無くていいと思ってる
ジェネリクス等で処理出来ないなら名前変えた方がいい

多言語の境界でよく面倒事の原因になる

**デフォルトの名無しさん** · 2019/03/25(月) 20:48:32.11

>>600
でもそれを参照する場所で型チェックなどが発生するだろ
A型とB型を格納していたプロパティにC型を格納するようになったら
それぞれの場所でまた変更が必要になる
無駄じゃないかなって思う