次世代言語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/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型を格納するようになったら
それぞれの場所でまた変更が必要になる
無駄じゃないかなって思う

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

関数のオーバロードは正直なくてもいいかなと思うけど（別の名前にすればいいだけ）
その言語はオブジェクトのコンストラクタのオーバロードも多分ないよね
それはどうするか、ちょっと困るな

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

オーバーロードと、実装を上書きするタイプのオーバーライドは絶滅すべき

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

>>604
Go Rustはオーバロードが無く、ただのstaticなファクトリメソッドでやってるよ

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

fabs()再び

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

オーバーロードがないとintのabsのほかにfloat用のfabsを用意しないといけない

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

>>602
リーナスも似たようなこと言ってたな
記事探すの面倒だから貼らないが
（誰か探して貼ってくれないかなﾁﾗｯ）

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

>>608
そっちはジェネリクスで対応するのでは

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

オーバーロードだったらマクロのが少しはマシ。

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

>>603
ts のunion は interface 無しでダックタイピング効くから、参照する時必ず型チェックが必要なわけじゃない
型自体の定義も type alias しておけば一箇所で済むし
静的型付け言語でany使うよりは、遥かに手間はかからないよ

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

>>612
だったら余計にinterface付けろよと思うわ

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

Go、Swift、Kotlinの3つは、文法ぐらい一緒にしてくれたら良かったのにな

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

なんかこだわりがあったんだろう

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

配列にしてもさあ、カッコの形とかにこだわりなんてあるんか？

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

どんな言語使おうが、糞バカ中世ジャップランドSIと、土人ベトコンオフショアが合体すれば
全部ゴミにできるんだけどなｗ

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

Kotlinはぱっと見Scalaかと思うくらい似てるよなー

**デフォルトの名無しさん** · 2019/03/26(火) 09:15:45.15

えっ？(笑)

**デフォルトの名無しさん** · 2019/03/26(火) 10:31:07.40

2019/03/06 15:42:58
2019年の愛され言語第1位、嫌われ言語第１位は?
https://news.mynavi.jp/article/20190306-784182/
「愛されプログラミング言語」
Python (51%)
Javascript (49%)
Java (37%)
HTML (34%)
C++ (23%)

嫌われプログラミング言語は以下
PHP (19%)
Objective-C (12%)
Java (11%)

対象となったプログラミング言語を愛している理由としては、その言語を学習するためのリソースや開発するためのリソースが充実していることが挙げられている。
逆に嫌っている理由としては、対象のプログラミング言語を使ったコーディングが楽しくないからという理由が多く挙げられている。

**デフォルトの名無しさん** · 2019/03/26(火) 11:13:59.02

忘れ去られた言語
ruupy

**デフォルトの名無しさん** · 2019/03/26(火) 14:00:36.03

>>621
俺は忘れてない。なぜならその名前を見たのは今が初めてだからだ。

**デフォルトの名無しさん** · 2019/03/26(火) 14:20:02.74

ごめんごめんpoopyだっけ？ｗ

**デフォルトの名無しさん** · 2019/03/26(火) 16:57:14.07

>>623
それについても俺は忘れてない。なぜなら以下同文

**デフォルトの名無しさん** · 2019/03/26(火) 17:32:40.93

rubooだったか？

**デフォルトの名無しさん** · 2019/03/26(火) 19:16:35.45

以下同文

**デフォルトの名無しさん** · 2019/03/26(火) 19:18:56.38

誰でも頭が良くなる、プログラムが書けるようになる方法が発見される 99934
https://you-can-program.hatenablog.jp

**デフォルトの名無しさん** · 2019/03/27(水) 17:04:40.79

>>602
先にジェネリクスがあったらオーバーロードは不採用だったと思う

**デフォルトの名無しさん** · 2019/03/27(水) 17:15:00.98

>>627
あと一回見かけたらはてブロに通報するわ

**デフォルトの名無しさん** · 2019/03/27(水) 17:15:08.52

ジェネリックで必ず同じ操作になるならいいけど
そうでもないときはジェネリックではどうにもできない

**デフォルトの名無しさん** · 2019/03/27(水) 17:18:22.78

オーバーロード否定派は動的型付け言語か形無し言語がメインの人なんだろうか？

**デフォルトの名無しさん** · 2019/03/27(水) 18:22:56.09

Cはユーザーが定義できない演算子だけオーバーロードする
ユーザーが定義してない型の情報だけコンパイル後に残る

このユーザー定義型の不当な制限をなくすというC++の理念のおかげで
オーバーロードや実行時型情報ができた
めでたしめでたし

**デフォルトの名無しさん** · 2019/03/27(水) 19:26:19.13

ほとんどの言語が強制キャストできるのが原因で型安全でなくなっているのが
何とかならない

**デフォルトの名無しさん** · 2019/03/27(水) 19:52:11.21

>>631
静的型付けメインにも普通に居るよ
RustやGoも関数オーバーロードを導入しなかったし

作為的な例にはなるけどむしろ型システムの阻害要因になることもある
https://ideone.com/uJ1lyb
https://ideone.com/P96nVa

**デフォルトの名無しさん** · 2019/03/27(水) 19:59:52.56

後者の例で言うと、ライブラリの関数に気を利かせてオーバーロードを追加したところ
別のプロジェクトの既存コードがコンパイル出来なくなったとかもあり得る

**デフォルトの名無しさん** · 2019/03/27(水) 20:08:46.35

やはりリーナスは正しかった！
c最高！
c++はうんこ！

**デフォルトの名無しさん** · 2019/03/27(水) 20:12:19.93

暗黙の型変換を含めた場合のオーバーロードの地獄感は半端ない。

**デフォルトの名無しさん** · 2019/03/27(水) 21:04:39.85

それにテンプレートとADLが絡んでカオス

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

クロスキャストはカスだから滅びろ
インターフェースの実装を鞍替えしたいんだったらFactoryとか使えや

**デフォルトの名無しさん** · 2019/03/30(土) 10:52:42.58

型名を隠蔽すればキャストできないので
無名クラスとラムダの世界ランクが右肩上がり

**デフォルトの名無しさん** · 2019/03/30(土) 13:35:24.87

本当に欲しいのは型ではなく制約

**デフォルトの名無しさん** · 2019/03/30(土) 19:28:46.42

ガイジみたいなコード書くガイジを殺していい法律を作ることだな
皆殺しにしてやるよ

**デフォルトの名無しさん** · 2019/03/31(日) 08:00:06.83

次世代かは知らんけど、Haskell奥が深い。
プログラマーのための圏論っていうのをネットから落として読んでるが、
圏論的には変数や値そのものも関数足り得るとか、読んでて面白い(理解してるかは怪しいが)

int n = 1とint n(){ return 1 }が同じと言うのは言い得て妙だなと。
Haskellで関数にカッコ使わないのはこれを体現する為なんだなと。

n = 1 ― Haskell的には変数でもあり、引数無しの関数。

関数も値でもあるんだから

sum = foldl (+) 0は、sum xs = foldl (+) 0 xsの部分適用で変数を(見かけ上)減らした関数であると同時に、
部分適用した関数に束縛した変数でもある。。。と。

と言うことはHaskellのmain関数も、関数であり変数なんだなーと。
関数を呼んでプログラムが走り出すとも言えるし、変数を評価しようとして、結果として束縛されたプログラムが走り出すとも言える。

main = putStrLn "hello" ― main関数を呼ばれたとも言えるし、変数mainを評価して値(IO ())を得る過程でプログラムが走り出すとも言える。

**デフォルトの名無しさん** · 2019/03/31(日) 10:38:58.10

概念は有用だし言語の進化に多大な影響を与えたけど
道具としてのHaskellは今の位置から上がってくることは無いだろうな

**デフォルトの名無しさん** · 2019/03/31(日) 10:43:21.70

>>644 確かにその通り。実用的な言語は、わかりやすくバグが出にくいことが重要。
他人のコードでも誰が見ても一目でわかるみたいな。

**デフォルトの名無しさん** · 2019/03/31(日) 11:07:42.57

実用なら副作用認めた方が絶対的に有利なわけでそういうのはOCamlなりF#が担えばいいよ
Haskellが勉強のための言語なのはこの先もかわらない

**デフォルトの名無しさん** · 2019/03/31(日) 13:08:06.82

xmonadとかあるし、実用的でないとは言い切れないが、いかんせん学習コストが高くてマンパワーに頼れんからな

**デフォルトの名無しさん** · 2019/03/31(日) 18:14:52.08

Haskellの再発明のようなアイデアを思いつくやつは必ず出てくるよ
これHaskellでやったやつだって教えてあげないと再発明を止められない
高い学習コストをもう一回課金される

**デフォルトの名無しさん** · 2019/03/31(日) 19:22:10.57

Haskellは数学的な背景があるから一部だけパクってもうまくいかんでしょ

**デフォルトの名無しさん** · 2019/03/31(日) 20:26:01.36

一部だけ学ぶのはダメってのは見覚えがある
Perlでやったやつだ
一部だけでいいと作者が言ってるのに全部やろうとして挫折するやつだ

**デフォルトの名無しさん** · 2019/03/31(日) 20:40:52.20

https://speakerdeck.com/uzulla/gui-tutekita-ping-cheng-zui-hou-falseoreorehuremuwakufalsezuo-rifang

なんでペチパーって自作FW作りたがるん？
もうしばらく関わってないけど、糞SIerいたとき糞案件が軒並み自社製PHP FW（糞）だったの思い出したわ

**デフォルトの名無しさん** · 2019/03/31(日) 21:26:26.85

量産型Webは技術が完全に硬直化してるから、ちょっと意識高い奴がマウント取りたくても差別化できるネタが少ないんだよ
で既存の開発プロセスのオーバーエンジニアリングに向かうわけだけど、
ペチパーレベルではインフラや言語を改善したりそもそも開発作業自体を減らすって方向には行きにくい
そこで手頃なのがFWというわけ

**デフォルトの名無しさん** · 2019/03/31(日) 21:52:14.80

もともとFWっていうのは汚いコードを寄せ集めてライブラリ化した上で
汚いコードの寄せ集めを使う処理を手順化して綺麗に見せるための仕組みだったんだけどな

**デフォルトの名無しさん** · 2019/03/31(日) 21:59:57.35

diコンテナは何のメリットがあるのか不明

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

>>654
は？

**デフォルトの名無しさん** · 2019/03/31(日) 22:37:11.66

依存性注入はクラスが増えてカオスになる
何故かjavaではよく使われるのが謎

**デフォルトの名無しさん** · 2019/03/31(日) 22:49:56.27

オブジェクト指向だとクラスは大量に作るもんだぞ

**デフォルトの名無しさん** · 2019/03/31(日) 22:58:47.59

それLaravel使えば問題ない話じゃね？

**デフォルトの名無しさん** · 2019/03/31(日) 22:59:24.74

アンカ抜けてた>>651

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

カオスだと感じる脳程度だけしか持ち得てないんだろう
察してやれよ

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

FXの自動売買ツールを無料で配布しています。
http://hbgvf.blog.jp

**デフォルトの名無しさん** · 2019/04/01(月) 00:33:10.08

人類最底辺の脳みそしか持ち合わせてない永遠の土方ペチプァの話題なんか出すな
スレが穢れる

**デフォルトの名無しさん** · 2019/04/01(月) 01:55:20.15

>>640
ついでにSAMも滅びろ
あいつ使いにくくてかなわん

**デフォルトの名無しさん** · 2019/04/01(月) 02:44:37.39

>>646 だれが勉強すんねん
一目見た時から、恋の花が咲いた
のでは無く、こりゃダメだと思った。

**デフォルトの名無しさん** · 2019/04/01(月) 02:48:36.94

逆に Python はなんとなく幼い頃の悪ガキ仲間と似てるなと思ってたら、立派に成長して懐の深い大人になってた。
ちょっと見の見た目で判断してはいけない。

**デフォルトの名無しさん** · 2019/04/01(月) 07:12:14.06

単純に機械学習ライブラリの虎の威借りてるだけだろ
言語としてはPHP並の糞だわ
venv周りも糞糞アンド糞だしな

**デフォルトの名無しさん** · 2019/04/01(月) 20:13:46.91

そのへん、他の軽量級言語は何故うまくやれなかったのかな。

**デフォルトの名無しさん** · 2019/04/01(月) 20:23:06.27

情報系専門でない連中が多い分野だから、言語オナニーには興味ないんだよ
Pythonは昔から数値計算系のライブラリが充実してたし学習コストも低い

**デフォルトの名無しさん** · 2019/04/01(月) 21:00:27.10

venvなぁ。
中にpython.exeがそのまんま入ってたのを見たときはコントかと思ったｗ

**デフォルトの名無しさん** · 2019/04/01(月) 21:18:09.61

数学の関数やOSのシステムコールを
いちいちオブジェクト指向に翻訳しないといけない文化は仕様が不安定になる

不安定な自作オブジェクトを集めたものが自作FWになる

**デフォルトの名無しさん** · 2019/04/01(月) 21:52:46.65

pyenvとかあの辺弄るくらいならdockerで閉じ込めた方がマシ。

**デフォルトの名無しさん** · 2019/04/02(火) 09:42:15.53

>>670
翻訳しないで済むOS作れば良いのでは？

**デフォルトの名無しさん** · 2019/04/02(火) 20:30:27.35

WinRTがそれかな

**デフォルトの名無しさん** · 2019/04/03(水) 11:55:08.65

>>671
venvに比べたら、docker重いよ。