次世代言語9[Haskell Rust Kotlin TypeScript Dart]

**デフォルトの名無しさん** · 2018/03/06(火) 10:09:15.60

スレタイ以外の言語もok

前スレ
次世代言語Part8[Haskell Rust Kotlin TypeScript]
http://mevius.5ch.net/test/read.cgi/tech/1512137301/

**デフォルトの名無しさん** · 2018/03/06(火) 10:30:06.56

Dartきてんね

**デフォルトの名無しさん** · 2018/03/06(火) 11:03:49.49

DartとDlangの違いを教えてください

**デフォルトの名無しさん** · 2018/03/06(火) 11:43:03.15

Googleは言語選択保守的すぎるだろ
関数型言語採用しないどころかGolang作っちゃう時点で

**デフォルトの名無しさん** · 2018/03/06(火) 12:27:31.20

Goと関数型は土俵が違わん？

**デフォルトの名無しさん** · 2018/03/06(火) 14:53:26.90

関数型とは具体的に何のことやら
Rustが採用したenumとtraitは関数型か？

**デフォルトの名無しさん** · 2018/03/06(火) 20:42:26.57

>>4
別にそんなとこで冒険しても生産性上がらんよねって感覚なんだろ。

**デフォルトの名無しさん** · 2018/03/06(火) 20:42:29.39

>>6
enum・traitと関数型は関係ないだろ？どちらもHaskellの型システムをパクって来たってだけ
関数型言語の特徴として真っ先に思いつくのは関数を第一級オブジェクトとして扱えるか否かというところだろうな
ただその考え方だけだとC言語でさえ関数ポインタがあるから関数型言語に含まれてしまうことになる
そこからさらに副作用を出来る限り避ける文化があるか否かとかも判断基準になるのかな？
言語の文化とかふんわりした表現は具体性を伴わないから説得力に欠けるんだよな
改めて関数型を具体的に説明しろと言われると難しいな…

**デフォルトの名無しさん** · 2018/03/06(火) 20:57:45.92

>>8
関数ポインタは確かにC/C++系独自だけれども（Javaにはなかった）第一級オブジェクトではない、とおもうよ

**デフォルトの名無しさん** · 2018/03/06(火) 21:32:52.86

もう少しだけ動的に関数定義を変えて返したりできるのが関数型ぽい。

**デフォルトの名無しさん** · 2018/03/06(火) 21:34:37.20

Cの関数は実行時に生成挟めないから第一級オブジェクトではないよ

**デフォルトの名無しさん** · 2018/03/06(火) 21:40:19.40

c++ならクラスのメンバに情報持たせて、メソッド使うことでクロージャぽいものはできるけど。

**デフォルトの名無しさん** · 2018/03/06(火) 21:45:38.71

λ理論を念頭に置いて実装されたかどうかやぞ

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

c++なら素直にラムダ式使おうよ…

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

C++ のラムダ式でYコンビネータを記述できるのですか？
できないのならラムダ式などと呼称していいのでしょうか？

**デフォルトの名無しさん** · 2018/03/06(火) 22:36:28.04

>>15
2つの話題を勝手に混ぜるな
>>14 で >>12 に安価付けなかったのは俺が悪いけどさ

実行時の環境を用いた関数定義の有無についてc++ならラムダ式を使おうという話をしているだけだ
しゃーねーだろ言語機能としてラムダ式って命名されてるんだから

関数型言語とはなんぞやという話題についてc++のラムダ式を例に挙げてc++は関数型だ!なんて言うつもりは毛頭ない
Yコンビネータに関しては確かできた気がするが

**デフォルトの名無しさん** · 2018/03/06(火) 22:44:51.87

>>16
正論すぎて草

**デフォルトの名無しさん** · 2018/03/07(水) 00:36:57.39

>>4
goって保守的かな？結構攻めてる言語だと思うが。
swiftのほうが断然保守的。

**デフォルトの名無しさん** · 2018/03/07(水) 00:55:59.65

>>18
保守的にするという意味で攻めてる言語だな

**デフォルトの名無しさん** · 2018/03/07(水) 00:59:12.93

諦めと開き直りを全面に押し出してくる言語だな、確かに。

**デフォルトの名無しさん** · 2018/03/07(水) 01:21:30.28

goの攻めてるところ。
ライブラリのimportにuriを指定してできるようにしてgithubから直接importできるようにした。
例外を辞めた。
公開、非公開をメンバ名が大文字始まりかどうかで決めるように。
クラスをやめて、構造体だけにした。
インターフェース実装は該当メソッドの有無で決定

といった具合に他の言語の当たり前の部分を壊した。全然保守的とは思えないが。

**デフォルトの名無しさん** · 2018/03/07(水) 01:26:49.68

後は未使用ライブラリのimportをコンパイルエラーにするというのも、他の言語であんまり見ない気がする。　

これは、積み重なるとコンパイル時間に影響するから、言語設計にコンパイル時間の考慮を重きにおいている証拠の一つと言える

**デフォルトの名無しさん** · 2018/03/07(水) 01:27:38.81

>>21
例外とか構造体はC時代に逆戻りしてるだけだし、静的ダックタイピングは他の言語にもあるし、githubのurl指定は結局色々な問題起きてるし(この間のgo-bindata騒動とか)、公開/非公開の大文字小文字も気軽に変えられなくて不便だし何のメリットがあるんだ？

**デフォルトの名無しさん** · 2018/03/07(水) 01:28:30.13

>>22
他の言語はエラーにはしないけど警告出す
初期の開発中は未使用importエラーも邪魔なだけでしょ

**デフォルトの名無しさん** · 2018/03/07(水) 01:41:57.73

>>23
むしろ、今まで当たり前にあった言語仕様を振り返って本当に必要かどうかを再検討して
削りに削った仕様だと思うけどな。

c++とか触ってたとき、クラスと、構造体って、本当に両方必要か？どっちか要らないだろって思ってたりしたから、
すごくしっくりきた。

**デフォルトの名無しさん** · 2018/03/07(水) 01:51:00.36

>>24
IDE使ってると半自動だからあんまり面倒だと感じたことはない。警告を無視する開発者もいるから徹底したほうが良いんだろう。
linuxカーネルもコンパイルすると警告出てるし

**デフォルトの名無しさん** · 2018/03/07(水) 01:54:34.87

>>25
構造体とクラスに関しては個人的に同意
ただ型パラメーターとか例外がないのはありえない
エラー処理は長すぎる。if分岐でチェックとかいつの時代だよ
型パラメーターないせいでDRY原則を破るか型安全を破るかしないといけない

**デフォルトの名無しさん** · 2018/03/07(水) 01:56:06.25

>>23
go-bindata騒動はgo固有の問題でもない。nodeだって似たようなことあっただろ。

**デフォルトの名無しさん** · 2018/03/07(水) 02:03:48.32

>>27
例外いるかな？
tryで包まなきゃいけないメソッドや、関数ってドキュメント読むか、実際に実行するまでわかんなくないか？
言語によっては例外が飛ぶ可能性がある関数かどうかわかるんだっけ？
jsはわかんないから不便。

**デフォルトの名無しさん** · 2018/03/07(水) 02:08:04.97

>>27
結局interface{}使うのかよ的なね。わかる。
俺はコード生成に可能性を見出してる。
goはコード生成フレンドリーな言語仕様だし標準ライブラリに、AST系が揃ってるから

**デフォルトの名無しさん** · 2018/03/07(水) 02:19:43.98

>>28
nodeもあったけどnodeの場合はnpmの仕様変えれば解決出来るやん
でもGoはgithubに依存してるから解決不可能じゃん

>>29
それならEither型作ってメソッドチェーンで書けるようにして欲しい
Goのエラー処理は関数呼び出し毎にしないといけないからだるすぎ

>>30
型パラメーターが複雑だから、コンパイル速度に影響出るからって入れなかったのにコード生成しろって矛盾してない？
どっちが複雑だよ。どっちがコンパイル速度に影響出るよ？

**デフォルトの名無しさん** · 2018/03/07(水) 03:07:39.19

>>31
コード生成はプリプロセスとしてコンパイルの度に毎回動かすわけじゃない。stringerとか使ったことない？

inportに関しては、
nodeがnpmの仕様を変えたら解決するならgoもそうすればいいのでは？

現状でも、vendor/もコミット対象にしてしまえば、依存ライブラリを管理対象にできるから

サードパーティライブラリに頼る以上はライブラリ作者の影響をどの言語だって受ける。

**デフォルトの名無しさん** · 2018/03/07(水) 03:12:09.66

Yコンビネータ forall a. (a -> a) -> a のように
forallがつく関数は第一級オブジェクトにならないのが普通だ
総称型がある比較的新しい言語はもう第一級オブジェクトにこだわらない

**デフォルトの名無しさん** · 2018/03/07(水) 04:31:47.78

maybe/eitherが無い言語はあまり触りたくないな

**デフォルトの名無しさん** · 2018/03/07(水) 07:45:36.47

goってなんだかよく使われてる以外の理由で使う理由がないよ
同じことするならrustのがいいわ

**デフォルトの名無しさん** · 2018/03/07(水) 08:21:04.51

Goはマイクロスレッド得意なのはありがたいな。
あとチャンネルと。
そして静的リンクがデフォ。
これだけで、Go使う価値あると思ってる。

**デフォルトの名無しさん** · 2018/03/07(水) 09:16:51.01

>>35
WEBサーバ: go,php,ruby,java,Elixir
IOSアプリ:swift,dart
Androidアプリ:java,kotlin,dart
WEBクライアント:JavaScript,elm,TypeScript
cliツール:go

どこにrustが入る？

**デフォルトの名無しさん** · 2018/03/07(水) 09:50:59.47

Rustは生ポインタが使えるし、C ffiが比較的容易に可能、そのうえwebassemblyにまで対応してる
>>37以外にも組み込み、OS、ドライバ、デスクトップアプリ等どこにでも入ろうと思えば入れる
C++の後継を目指してるだけあってかなり万能な言語ではあるんだが
問題は普及するかどうか…

**デフォルトの名無しさん** · 2018/03/07(水) 10:25:38.57

>>32
goはgithubに依存してるからgithubの仕様変えないと駄目じゃん
具体的にはリポジトリやユーザーの削除禁止。でもそれは無理だろ？

>>32
毎回動かすわけじゃないけど、変更あったら動かすだろ？
しかもそれは他の言語でも差分コンパイルで出来る

**デフォルトの名無しさん** · 2018/03/07(水) 10:51:52.29

>>39
githubが便利だからgithub使ってるけど、別にgithub以外でも公開出来るし、依存してると言うより多くの人間がgithub使ってるだけでは？