次世代言語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(土) 09:29:17.49

>>481 ちょこちょこ変更できてなんでもできる事。
だから入門者用としても入りやすい。小学生から学者まで。

特にライブラリーが揃ってるから統計分析など科学技術計算には強い。特に機械学習やAI は、Python
また、Excel との相性も良い。

コンパクトなバイトコードになるから、IoTの様に小さな所でも動け、REPLが動くから実機で変更テストができ自由度が高い。だから、IoT用言語としての地位も確立している。

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

>>487
Pythonにはどっかの赤い宝石とは違ってドキュメントをきちんと書く文化がある
そして、本当に正しく書かれたドキュメントには「プロトコル」としてアヒルが満たすべき要件が定義されている
そこまでやってはじめて「ダックタイピング」と言える

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

Pythonのプロトコルというとイテレータとかああいうやつ？あれなら確かにダックタイピングと
言えるかもしれないけど、あらかじめ定義されているもの以外に「アヒル」プロトコルとか
追加できるんだっけ？

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

文章力があればプロトコルの数学的定義を覆せる文化
それがドキュメントを書く文化につながる

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

>>490 デスクリプタ汎用プロトコルがあるからユーザが定義できる。
https://qiita.com/knzm/items/a8a0fead6e1706663c22

デスクリプタ HowTo ガイド
https://docs.python.org/ja/3/howto/descriptor.html

Duck Typing は動的型付けな言語(Python, Ruby)等における型付けの作法である
ある処理に必要なオブジェクト A と同じ振る舞いができるのであれば、継承関係のある/なしにかかわらず、そのオブジェクトはAと同じとみなして良いというもの。

Python のダックタイピングの例
PythonのABC - 抽象クラスとダック・タイピング
https://qiita.com/kaneshin/items/269bc5f156d86f8a91c4

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

Ruby のStringIO は、Duck Typing

StringIO クラスは、IO クラスと継承関係はなく、
単に、read, write など、IO と同名の関数名を使っているだけ

これだけで、StringIO に対して、入出力操作を行うことで、
メモリファイルを扱うことができる

最近は、ガチガチの継承よりも、委譲やDuck Typing を使うことも多い。
宣言無しのinterface みたいなもの

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

>>493
>宣言無しのinterface みたいなもの

なるほど、そういう解釈ならしっくり来た。

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

Rubyは大クラス主義といって、移譲だのプロトコルだのまどろっこしいことするよりどんどん継承しようぜ！という考え方が主流
だから実際にはほとんどダックタイピングは使わない
静的型検査なしでドキュメントも書きたくないとなると、Pythonのような紳士協定ベースなやり方は確実に破綻するので、
実装継承を多用するというのは「実装が仕様」なルンペン文化には適したスタイルではある

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

interfaceがあってこそのduck typingだなとtypescriptやって思った

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

interfaceは元々は「堅い」言語で既存コードに極力手を入れずに建て増ししていくための仕組みだが、
今ではそれが高速な開発におけるデグレ防止に役立ち、生産性において動的型を圧倒したというのは皮肉な話だな

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

Javaのinterfaceを初めて見たとき、Goのようなものを期待したら違っててがっくりした思い出。

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

静的型は悪くないが静的型を正しく教えるノウハウをだれが持ってるんだろうか
目か？目で盗むのか？

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

Duck Typing だと、たまたま同名の関数名があった場合に、バグる危険性があるから、
自分が使うものだけを、interface 宣言させて、バグを避けているのだろう

最近は、その宣言がガチガチ過ぎて面倒なので、Duck Typing が流行ってきている

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

危険と安全の対立が今は主流になっているがCの型にはサイズを計算する意味もあった

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

流行り廃りは行き来するもんだからな。
動的も静的もいいバランス具合にそのうち落ち着いていくだろう。
本当に流行り廃りを超えてる技術というのはユニットテストやリファクタリングといったものなんだが、
そういうのみんな嫌いでしょ？

**デフォルトの名無しさん** · 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を進めてるし一応止まってはいない感じ