次世代言語Part8[Haskell Rust Kotlin TypeScript]

**デフォルトの名無しさん** · 2017/12/01(金) 23:08:21.45

スレタイ以外の言語もok

前スレ
次世代言語Part7[Go Rust Swift Kotlin TypeScript]
http://mevius.5ch.net/test/read.cgi/tech/1508403098/

**デフォルトの名無しさん** · 2017/12/11(月) 18:12:17.71

てか普通にそのコード通るテスト書けよ。

**デフォルトの名無しさん** · 2017/12/11(月) 19:33:23.48

テストは型検査みたいな静的検査と違って本質的に安全性を保証できないのでお門違い

**デフォルトの名無しさん** · 2017/12/11(月) 19:40:27.25

型検査を有り難がるのはテスト書かないドカタだけって結論出てるけどな

**デフォルトの名無しさん** · 2017/12/11(月) 19:52:37.78

お門違いの型の変数投げ入れて、
型エラー例外をトラップするようなテストかけばいいじゃん。

まあ手間なのはわかるけど、少しは頭使えばいいのに。

**デフォルトの名無しさん** · 2017/12/11(月) 20:02:58.37

テストかかなくても、ソースを書いていること自体テストもかね、入力補完強化も兼ねるからいいんじゃないの？

**デフォルトの名無しさん** · 2017/12/11(月) 20:05:57.20

それで動的型にする見返りがあるんなら良いんだが、何もないからなぁ
邪悪なことがしたい、以外のメリットが無い
少なくとも次世代言語の土俵に上がれないのは確かなので
このスレでミソカスな扱いになるのは仕方がないだろうな

**デフォルトの名無しさん** · 2017/12/11(月) 20:14:05.81

サクッとプロトタイプとしてフロントエンド作るなら圧倒的に動的のがラクだけどね。
規模が大きいんなら確かに静的でないと厳しいかなと思うけど。

**デフォルトの名無しさん** · 2017/12/11(月) 20:29:57.04

プロトタイプで作って流行ったら作り直すならいいけどね
規模大きくなっても使い続ける企業多すぎ

**デフォルトの名無しさん** · 2017/12/11(月) 20:30:14.73

多重ディスパッチが好き

◆QZaw55cn4c · 2017/12/11(月) 20:42:49.31

>>217
variant 型を使うなんて、まるで void * だけでコーディングしろ、と強要しているようなもの
型の恩恵を自ら捨てる選択には疑問、Java の嘘嘘 generics にしてもありがたいくらいだ

**デフォルトの名無しさん** · 2017/12/11(月) 20:45:00.55

俺なんかは型を書くのがそんなに面倒か？と思うし
あちらさんは型のテストを書くのがそんなに面倒か？と思うのかもしれないが
仮に、この二つが同程度の面倒臭さだったと仮定したら
その時点でバランスしてしまってるわけで・・・あとはもう自明
ただこれは昔の話で、今は型推論も普及してるから、更に

シンプルに考えて、型のテストはどこかの段階で絶対にやらなければならない
避けて通れないものとしたとき、じゃー何処でどのようにやるかという事で
どうせ不可避なら静的型のアプローチの方が良いだろうとなるだけで
システムでサポートせず人力でテストするって方向はまるで
アセンブリのようで逆行しているわ

◆QZaw55cn4c · 2017/12/11(月) 20:52:19.53

ただ、動的型付け言語の御大将は、あの lisp 族だからな…奴らには勝てない…

**デフォルトの名無しさん** · 2017/12/11(月) 20:55:22.07

Land of lispにHaskellのが良いって書いてあるから静的片付けの勝ち

**デフォルトの名無しさん** · 2017/12/11(月) 21:45:07.08

ローカル変数→型推論があるので型を書く必要はない
公開関数などの型→動的型付けでもコメントなど何らかの形式で型を書くので静的型付けだから書かないといけないという事はない
よって静的型付けの勝ち

**デフォルトの名無しさん** · 2017/12/11(月) 21:52:39.67

型でコーディングは出来んし、証明でビジネスは動かん
結局きちんと動くものをいかに速く作るかってだけの話だろ

本当に静的型が「きちんと動くものを速く作る」ことができるなら、とっくにYesodがRailsを駆逐してる
そうじゃないってことはRailsの方が、強い動的型の方が優秀なわけだ

まあPHPみたいな弱い型付けの言語は論外だが

**デフォルトの名無しさん** · 2017/12/11(月) 21:55:13.37

Railsなんて駆逐されるほど使われてるの？
Google、Microsoft、Amazon、Facebook、twitterなど、有名な会社で使われてるのを聞いたことないが…
正直技術力のないベンチャーが使ってるイメージしかない

**デフォルトの名無しさん** · 2017/12/11(月) 21:55:35.93

rust は別に好きじゃないんだが型に関するアプローチに関してはいいと思う。
関数の引数では型を気にするけど、内部は型推論で暗黙的に設定されるっていう。

**デフォルトの名無しさん** · 2017/12/11(月) 21:56:58.82

>>227
Option Explicitとはその程度のもの。
あと、Variantを器用に使ってるシステム見たことあるぞ。
バカとハサミは使いよう。

**デフォルトの名無しさん** · 2017/12/11(月) 21:59:51.45

>>232
Railsって言語だったの？

**デフォルトの名無しさん** · 2017/12/11(月) 22:01:59.46

>>233
初期のTwitterはRailsだぞ？
顔本はPHPだ

**デフォルトの名無しさん** · 2017/12/11(月) 22:03:18.72

>>236
脳内でHaskellとRubyに対応付けてくれよ……

**デフォルトの名無しさん** · 2017/12/11(月) 22:03:39.46

>>237
Railsなどという負債を抱えていたいい例やね

**デフォルトの名無しさん** · 2017/12/11(月) 22:04:41.80

初期

**デフォルトの名無しさん** · 2017/12/11(月) 22:05:55.17

>>237
いや知ってるけど、それはその2つが駆逐された話じゃねーかｗ

**デフォルトの名無しさん** · 2017/12/11(月) 22:09:18.64

twitter は erlang に移って、その後やっぱ性能出ないから他のにしたって話じゃなかったっけ？
こうみると言語にこだわるのは技術力のない証拠に思えるけどね。

**デフォルトの名無しさん** · 2017/12/11(月) 22:10:51.69

まあ十分な技術力があればJavaを使うからなｗｗｗ

**デフォルトの名無しさん** · 2017/12/11(月) 22:17:40.59

goroutin は意外とリークがめんどい、
erlang の軽量プロセスはそこまで性能が出ない
scala の互換性はひどすぎる、
では、この領域をカバーする言語は？
ってのはあるかもね。

**デフォルトの名無しさん** · 2017/12/12(火) 00:43:04.64

自称言語屋

**デフォルトの名無しさん** · 2017/12/12(火) 01:28:41.64

同期的にかけるasync awaitの良さを知ってから
gorutineもしんどくなってきたわ。
見た目命令順になるのが一番分かりやすい

**デフォルトの名無しさん** · 2017/12/12(火) 07:29:46.32

>>246
デバッグとスタックトレースが難点だけど、メリットの方が大きいからお世話になってます

**デフォルトの名無しさん** · 2017/12/12(火) 12:57:32.06

元からイベントの投げつけ合いで書いてたからどっちも便利だと思うけどな。

**デフォルトの名無しさん** · 2017/12/12(火) 21:14:39.58

lambdaの中にlambdaを書くのを繰り返すと大量のインデントと括弧が出てくる
インデントと括弧が不要になるのが一番重要

**デフォルトの名無しさん** · 2017/12/12(火) 21:25:39.50

>>249
それって Python 限定の話だろ
Python は公式ドキュメントで関数型プログラミングには不適切と
表明しているくらいなんだから、それくらい我慢するのが Pythonista だよ

**デフォルトの名無しさん** · 2017/12/12(火) 21:37:47.02

コールバック地獄は何故地獄かって話だからPython限定ではないと思うが

**デフォルトの名無しさん** · 2017/12/12(火) 22:28:11.33

>>249
引数とかにlambdaを直接書くスタイルはそれが苦にならない人達がやっているだけで、
それが読みにくいと感じるならフラットに展開しちゃえばいいんだぜ？
Promiseやasync/awaitでcallback地獄解消なんて書いている記事の大半も
本質的な部分はこっちだったりして。
ただ>>246の言うように上から実行順に書けるというメリットはある。

**デフォルトの名無しさん** · 2017/12/12(火) 22:28:51.50

Promiseパターンがすべてを解決した認識

**デフォルトの名無しさん** · 2017/12/12(火) 23:30:52.82

コールバック地獄は、JS の、co, Koa などのジェネレータランナー。
iterator, generator を使ったもの

yield Promise.all

みたいな書き方

**254** · 2017/12/12(火) 23:35:15.82

try{
yield Promise.all(非同期の並行処理)
}catch(err){
}

ジェネレータランナーは、非同期処理を同期的に書けて、
非同期処理を、try/catch できる

**デフォルトの名無しさん** · 2017/12/13(水) 14:46:46.99

Promiseは何度も帰ってくるものや、一度も帰ってこないかもしれないものが書きづらいんだよなぁ。
名前の通りだから仕方ないんだけど。
Promiseとawaitで解決できるのはcallbackを使うものの中でもとても限定的なパターンだと思う。
無いよりマシだけどね。

**デフォルトの名無しさん** · 2017/12/13(水) 16:16:33.50

コールバック地獄は慣れれば天国だろ。
実行速度もコールバック地獄のほうがプロミスより速いしな。

**デフォルトの名無しさん** · 2017/12/13(水) 18:37:50.43

>>257
おう、高級言語よりアセンブリの方が速いし一生アセンブリ使っとけよ

**デフォルトの名無しさん** · 2017/12/13(水) 18:38:50.92

>>256
何度も返ってくる物:rxjs
一度だけ返ってくるもの:Promise+async/await

**デフォルトの名無しさん** · 2017/12/13(水) 20:43:44.45

>>259
借りてきすぎて統一感ゼロ。
いっそコールバック書くか、全部イベントでこなすかや全部rxか、全部Reduxのほうが潔い。
awaitで延長される変数のライフタイムが勿体無さすぎる。

**デフォルトの名無しさん** · 2017/12/13(水) 20:52:20.95

>>258
そういう世界もあるので一概に笑えんし、少なくとも取ってつけたで満足して「これがあるから問題ない」と開き直るよりは、
コントロールを保ってモノ作ってると思うけどな。
ポリフィル(笑)

**デフォルトの名無しさん** · 2017/12/13(水) 22:30:27.71

>>260
いやいや適材適所だろ

**デフォルトの名無しさん** · 2017/12/14(木) 00:54:59.81

rxもかなりめんどくさい。概念はシンプルなのに
操作メソッドあんなにいるもんか？って思うわ。

**デフォルトの名無しさん** · 2017/12/14(木) 02:18:11.50

Advent見てても人気ねぇし、Rxは流行らんな。

**デフォルトの名無しさん** · 2017/12/14(木) 07:59:53.12

時代はBlack

**デフォルトの名無しさん** · 2017/12/14(木) 08:03:21.17

>>216
>動的型言語の「綴りミスも許さない」方針にはついていけない

変数宣言省略と動的型付けをごちゃ混ぜにするような人はプログラムしないほうがいい

**デフォルトの名無しさん** · 2017/12/14(木) 08:04:38.89

>>216
>動的型言語の「綴りミスも許さない」方針にはついていけない

変数宣言の有無と型付けを区別できない人はプログラム書かないほうがいいと思う

**デフォルトの名無しさん** · 2017/12/14(木) 08:05:20.86

>>216
>動的型言語の「綴りミスも許さない」方針にはついていけない

変数宣言の有無と型付けを区別できない人がプログラムを書くのは型エラーです
大事なことなので3回書きました

**デフォルトの名無しさん** · 2017/12/14(木) 08:07:43.17

>>223
>それで動的型にする見返りがあるんなら良いんだが、何もないからなぁ
>邪悪なことがしたい、以外のメリットが無い

こういう人って
邪悪なことって具体的にリストアップしてよ
と言うと二度と帰ってこないw

**デフォルトの名無しさん** · 2017/12/14(木) 08:22:58.23

Yコンビネータ書きたいとかだろ

**デフォルトの名無しさん** · 2017/12/14(木) 08:29:14.79

Yコンビネータは再帰型で静的に型付くだろ

**デフォルトの名無しさん** · 2017/12/14(木) 08:29:49.77

>>262
適材適所なのかなぁ。
目下の問題を解決するためにこうなっちゃいました、いい感じなんで標準クラスにするべき！に見える。
どーせwebworkerとかserviceworker、webdsocketにイベントの投げ合いなんだし、もとのようにイベントで制御するのが一番に見えるけどな。
一度きりならonce、何回も呼ばれるからon。
eventEmitterってブラウザでも使えなかったっけ？
無けりゃそれぐらい書いても良いけど。

**デフォルトの名無しさん** · 2017/12/14(木) 08:31:59.97

連投ガイジ

**デフォルトの名無しさん** · 2017/12/14(木) 10:21:22.17

動的型付けの恩恵を一切受けないコードを書くなら
動的型でも型推論で補完が効くし、
補完が効かないなら動的型の恩恵を受けるようなコードを
知らないうちに書いてるってことだよ

**デフォルトの名無しさん** · 2017/12/14(木) 12:16:59.44

なんでもガイジだなぁ

**デフォルトの名無しさん** · 2017/12/14(木) 12:51:31.09

なんでもガイジというか、ガイジがいっぱい沸いているだけ

**デフォルトの名無しさん** · 2017/12/14(木) 13:13:13.86

同じ人間でも脳の構造の違いにより考え方が全然違う。
つまり生まれつき脳の仕組みが全く違う人達がいる。

**デフォルトの名無しさん** · 2017/12/14(木) 16:27:32.32

仕組みが全く違うというのがもし本当なら
速度のみを測定するベンチマークが信用できなくなる
だから仕組みは同じで速度だけが違うと考えるのが無難である

**デフォルトの名無しさん** · 2017/12/14(木) 19:49:58.30

>>272
rxはSubject使い始めると一気に邪悪化するからな

**デフォルトの名無しさん** · 2017/12/15(金) 00:41:45.52

型無しガイジどもは死ね
迷惑なんじゃ

**デフォルトの名無しさん** · 2017/12/15(金) 07:01:30.05

型推論より要件推論ください。

**デフォルトの名無しさん** · 2017/12/15(金) 07:10:42.24

プロミスってモナドだよな。いい意味で。

**デフォルトの名無しさん** · 2017/12/15(金) 08:27:21.30

型があれば解決するかのように思ってる人が生き方を改めてほしいな。
実際問題、それだけに頼って地雷踏んだときはコアダンプ読む型なんて飾りですみたいなオッサン呼ぶ事になるんだし。

**デフォルトの名無しさん** · 2017/12/15(金) 08:32:03.35

だがそれは型による静的検証をしない理由にはまったくならない

**デフォルトの名無しさん** · 2017/12/15(金) 09:26:28.87

別にやればいいじゃんとしか言いようがない。
大抵糞どうでもいいキャストを付け加えるどうでもいい作業に時間を追われるだけだけどな。

**デフォルトの名無しさん** · 2017/12/15(金) 09:27:43.95

底辺凄いな（こなみかん

**デフォルトの名無しさん** · 2017/12/15(金) 09:41:39.57

型による静的検証で満足する理由にもならん。

**デフォルトの名無しさん** · 2017/12/15(金) 09:51:32.76

静的型があれば全て解決するとは誰も言ってないが
動的より良いというだけだぞ

**デフォルトの名無しさん** · 2017/12/15(金) 10:01:44.25

そらフレームワークに乗っかって用意された関数を呼ぶだけのドカタには
静的型の制約なんて関係ないだろうね
メタプログラミングなんてした事ないでしょ？めんどくさいよ静的型だと

**デフォルトの名無しさん** · 2017/12/15(金) 10:19:01.73

こいつ相手をドカタかつメタプログラミングをしたことない奴と決めつけて何がしたいんだ……

**デフォルトの名無しさん** · 2017/12/15(金) 10:29:03.83

なんで静的型のほうが動的型より良いって前提で話を進めるんだこいつらは……
そんなに静的型が好きならYesodでRailsレベルのシステム構築してみろっつーの

**デフォルトの名無しさん** · 2017/12/15(金) 10:44:03.14

そんな面倒なこと要求するならお前も何か動的言語でRails並のもの実装しろよな

**デフォルトの名無しさん** · 2017/12/15(金) 10:47:18.85

静的型なら動的型より生産性高いって主張してる側が実装しろよ
なんで実証をこっちがやんなきゃいけないんだよ

**デフォルトの名無しさん** · 2017/12/15(金) 10:49:44.96

実証責任を押し付ける上にテーマまで押し付けんなよ
テーマ量子化学で良ければ無限に実証してやるがやるか？

**デフォルトの名無しさん** · 2017/12/15(金) 10:55:43.94

静的型の言語はいちいちキャスト書いたり無駄にコード量がかさむ抽象クラス書いたりしてコード当たりの生産性低くなるし
メタプログラミングがかなり面倒になるしで、動的型と比べて工数が倍以上かかる
型チェックで検出できる程度のエラーなんて単体テスト書きゃ確認できる程度のモン

テスト書きたくないクソプログラマ未満には魅力的に映るんだろうがな

**デフォルトの名無しさん** · 2017/12/15(金) 10:57:08.06

>>295
ってこっちは主張してて、その実例として、RailsとYesodを提示してる
静的型を優位に推したいなら、逆の事例でも提示してみろって話だ

**デフォルトの名無しさん** · 2017/12/15(金) 11:06:17.66

動的と静的は兄弟のようなものでお助けあっていきているんだね。

**デフォルトの名無しさん** · 2017/12/15(金) 11:23:17.29

おぅん？
なんだその妄想。静的型でもテスト書くぞ
それにJavaじゃあるまいしちゃんと書いてりゃキャストはいらんしょ
メタプログラミングはともかく、その二つは言語の問題じゃない

言語の問題じゃない所を挙げて優位を主張すれば良いなら
↓みたいなこと書けばいいのか？

動的型は引数の型情報をちゃんと書かないから人のコード読むのめっちゃしんどくて生産性が低くなるし、テストが足りずにいざ動かしたら意外な所で引っかかるボケコードも存在する（しかも型があれば引っかからないような所）
いちいちクラスのメタ的なマニアックな機能を使って書いた本人以外の読解がそれなりにしんどいコードにして拡張性を下げたりし始めるし
コードを読む時間が倍以上かかる

実例としては動的型付けとしてaseとpyquante、静的型付けとしてvaspとbigDFTでも提示しておこうかな

こんな感じでええんか？

**デフォルトの名無しさん** · 2017/12/15(金) 11:27:03.08

挑発に乗って色々滅茶苦茶書いたものの実は俺は静的信者では無かったりする

**デフォルトの名無しさん** · 2017/12/15(金) 11:52:43.43

>>298
コードリーディングの過程で型情報がほしいって言うのは一理あるな。そのために間違った方のハンガリアン記法使うのもアホ臭い

ちゃんと設計してればキャストはいらないっていうのは、静的型言語では整数と浮動小数点数の組み合わせで四則演算すらできないって問題がある。OCamlがわかりやすいな
これを無理矢理できるようにHaskellみたくNum型クラスみたいなのを導入するとオーバーヘッドがかさむ

テストについては、結局型が通るか通らないか程度はテスト書く過程で見れるだろって話で、きちんとテスト書けばその程度の差は優位性にはならないんじゃないかってことな
そりゃテスト書かないと静的型でも動的型でも壊れたコードだ

◆QZaw55cn4c · 2017/12/15(金) 12:14:19.47

>>300
＞静的型言語では整数と浮動小数点数の組み合わせで四則演算すらできない
いまどきの静的型付け言語でそんなものがあるのか？静的型付け言語の意味をわかっているのか？

**デフォルトの名無しさん** · 2017/12/15(金) 12:18:48.75

OCamlは今時の静的型付け言語ではないのか？

**デフォルトの名無しさん** · 2017/12/15(金) 12:21:43.33

Scalaはこの問題を暗黙の型変換で対応してるが、これはこれで闇を醸造してるよな

**デフォルトの名無しさん** · 2017/12/15(金) 12:26:18.04

演算子オーバーロードを嫌う人がいるのは事実
演算子オーバーロードすると実行時にオーバーヘッドがかさむというのは嘘八百

**デフォルトの名無しさん** · 2017/12/15(金) 12:26:29.05

組み込みの数値型は自動変換する言語が多いし
静的・動的と関係ないね

**デフォルトの名無しさん** · 2017/12/15(金) 12:39:33.81

>>288
そうでもなかろう。
蛇足という言葉もある。
生産性ってのはもう少し厳密に扱われるべきだと思う。○○の場合は、とか。

**デフォルトの名無しさん** · 2017/12/15(金) 12:41:17.66

>>300
間違ってない方のハンガリアンならば、型なんてどうでも良いと言う事もわかると思う。
ユーザ定義型に出来れば言う事無いけどね。

**デフォルトの名無しさん** · 2017/12/15(金) 12:50:20.64

>>307
そうだな。正しい方のハンガリアン記法なら、静的型のコンパイラに頼るよりはるかに健全な運用ができる

別に静的型でもやりゃいいと思うが、コンパイラに頼るのに慣れると面倒に感じるのかね？

**デフォルトの名無しさん** · 2017/12/15(金) 12:56:07.91

静的型でチェックできることは、単体テストを書く過程で自然とチェックできる
静的型のチェックにより、メタプログラミングが書けなくなり、本質的でない型合わせのための余計なキャストも増える

結局この二点なんだよな

**デフォルトの名無しさん** · 2017/12/15(金) 12:58:02.72

可読性についてはまあわからんでもない。正しい方のハンガリアン記法でも、接頭辞の管理はコード上にないからな
IDEのサポート込めば確かにリーディング速度は上がると言える

◆QZaw55cn4c · 2017/12/15(金) 13:19:56.65

>>309
＞静的型でチェックできることは、単体テストを書く過程で自然とチェックできる
逆だ、
単体テストでのチェック内容の一部は、テストを書くまでもなく静的型でチェックできる、だ
テストを書くまでもなく、成果物の品質を一定のレベルまで引き上げるのが静的型の特徴だ

メタプログラミングはそれようの総称型を使えばよい
本質的でないキャストは総称型（ジェネリクス）で基本的に全廃できる

**デフォルトの名無しさん** · 2017/12/15(金) 13:45:16.34

>>311
＞テストを書くまでもなく、成果物の品質を一定のレベルまで引き上げる
だからって単体テスト書かないって訳でもなかろう
その単体テストを書く過程で型検査などは自然とテストされるということ
型チェックをテスト書かない言い訳にするのはそれこそ最悪

**デフォルトの名無しさん** · 2017/12/15(金) 13:46:32.11

ジェネリクスで不要なキャストが撤廃できるなら、それはそうなんだろう
上で挙げた四則演算問題がジェネリクスでなんとかなるとも思えんが

**デフォルトの名無しさん** · 2017/12/15(金) 13:59:37.30

>>311
ジェネリクスをきちんと使えばキャストはほぼ全てなくせるが、
メタプロはジェネリクスだけじゃどうにもできないだろ。
あと、ジェネリクスとC++のテンプレートは似ているようで全然違う。
メタプロに関しては動的言語のほうが簡単なのは事実。
ただ、本当にメタプロが必要になるケースになんてあまりないと思うんだが。

>>312
別にテストを書かない言い訳とかじゃなくて、
静的型なら動的型に比べてテストを書く量を減らせるということだろ。
テストを全く書かなくなることはないけど、テストの量を減らせるというだけでも
そこには立派な価値があるということが言いたいんだ思うが。

**デフォルトの名無しさん** · 2017/12/15(金) 14:00:37.68

四則演算問題って何？

**デフォルトの名無しさん** · 2017/12/15(金) 14:07:11.13

>>315
たぶん>>300の
>静的型言語では整数と浮動小数点数の組み合わせで四則演算すらできないって問題がある。
てやつのことだろ。
それって、単に言語の性格の違いのような気がするんだが。問題と呼ぶほどのものか？

**デフォルトの名無しさん** · 2017/12/15(金) 14:58:25.54

走らせないとわからないテストより前に、コンパイルでエラーが検出できたほうがいいやろ
テストについて一から勉強しなおしなさい