次世代言語12 Go Rust Swift Kotlin TypeScript

**デフォルトの名無しさん** · 2018/07/04(水) 09:38:15.76

スレタイ以外の言語もok

前スレ
次世代言語11[Rust Swift TypeScript Dart]
https://mevius.5ch.net/test/read.cgi/tech/1528037607/

**デフォルトの名無しさん** · 2018/08/03(金) 04:43:38.64

ESの付け焼き刃的実装に限界があるでしょ

**デフォルトの名無しさん** · 2018/08/03(金) 06:06:54.20

嘘つき「何も宣言しないよりはマシ」
付け焼刃「何もしないよりはマシ」
ギャンブル依存症「何も賭けないよりはマシ」

**デフォルトの名無しさん** · 2018/08/03(金) 10:32:16.64

所詮MSの作った詐欺言語だわな

**デフォルトの名無しさん** · 2018/08/03(金) 10:34:43.31

>>390
の徹底を求めます

**デフォルトの名無しさん** · 2018/08/03(金) 10:46:59.25

TypeScriptはもうデファクトスタンダードなのよね

**デフォルトの名無しさん** · 2018/08/03(金) 11:49:14.47

>>590
病的になんだか拗らせてるのかな

**デフォルトの名無しさん** · 2018/08/03(金) 14:13:45.54

なぜ病気とか健康とかなんですか
悪とか正義とかではだめなんですか

**デフォルトの名無しさん** · 2018/08/03(金) 14:37:25.10

Linus氏曰く「マイクロソフト嫌悪は『病気』」
https://srad.jp/story/09/07/28/0326208/

**デフォルトの名無しさん** · 2018/08/03(金) 15:01:39.29

病人は生産性がないなんて言ったらたぶん炎上するし
悪人は生産性がないと言う方が無難だと思うけどなあ

**デフォルトの名無しさん** · 2018/08/03(金) 21:26:18.77

生産性がないならまだいいが生産性がマイナスな輩というのがいる。
こういう輩を見るとベイシックインカムはいいんじゃないかと本気で思うよ。

**デフォルトの名無しさん** · 2018/08/03(金) 22:58:37.04

>>586
嘘って？

**デフォルトの名無しさん** · 2018/08/04(土) 10:28:43.19

やっぱ副作のないメソチェが最高やろ
リス内記は読つら

**デフォルトの名無しさん** · 2018/08/04(土) 10:30:16.07

>>597
それは愛だよ

**デフォルトの名無しさん** · 2018/08/04(土) 10:58:41.10

初心者用の言語は上級者の要求を満たすことが出来ないということだな。
上級者が初心者用の言語使うのが間違ってるな。
haskellを使えば副作用を分離出来るし、メソッドチェーンも出来るし、
直積のタプルも0次元からN次元まで使えるし（1次元は普通の集合）
解決だな。

**デフォルトの名無しさん** · 2018/08/04(土) 11:18:31.48

ハスルケはセパレイタとしての記号が少ないからリイダビリティが悪い
そして誰もいなくなっただろう

**デフォルトの名無しさん** · 2018/08/04(土) 12:29:28.79

Haskellはタプルを使わなくてもコンストラクタのアリティを2以上にできる
多変数コンストラクタの具体例のひとつにすぎないのがHaskellのタプル
1変数コンストラクタも無数にある
だから a と (a,) が同じ型にならないPythonを見ても違和感はない

**デフォルトの名無しさん** · 2018/08/04(土) 14:55:00.60

>>601
オレオレ略語とか変なカタカナ表記とか、お前さんのレスもreadability低いぞ

**デフォルトの名無しさん** · 2018/08/04(土) 16:06:26.17

>>603
これが通なんだよなあ

**デフォルトの名無しさん** · 2018/08/04(土) 18:12:45.89

ナウいハスルカー来たな

**デフォルトの名無しさん** · 2018/08/06(月) 14:41:08.25

>>598
だからなんでリスト内包vsメソッドチェーンの対立になってんだよ

**デフォルトの名無しさん** · 2018/08/06(月) 16:48:04.88

ハスケルはエコシステムが腐ってるという話を聞いたけど本当？
言語がいくらすごくても環境構築で、しんどい思いするなら用無しなんですが

**デフォルトの名無しさん** · 2018/08/06(月) 16:59:19.53

改善されたことになっているが正直クソ

**デフォルトの名無しさん** · 2018/08/06(月) 17:02:40.30

理論ばかりの頭でっかちの奴等ばっかりだからな。
実用性なんかどうでもいいんだろ。
だから実用されないんだよｗ

**デフォルトの名無しさん** · 2018/08/06(月) 19:32:00.71

>>607
パッケージ管理ツールのcabalもstackも依存把握がすぐぶっ壊れる。
あれは何が副作用がないからバグが少ないだって気分になるわ。

**デフォルトの名無しさん** · 2018/08/06(月) 21:10:23.18

1. 関数プログラミング自体が実は大したことない
2. 副作用禁止の強制が邪魔
3. 使ってるプログラマーのレベルが低い(偏屈しか使わない・ユーザー層が薄い)
4. まだ成熟していないだけ

どうだろう。4だと思いたいが…

**デフォルトの名無しさん** · 2018/08/06(月) 21:20:23.85

・Web系→モデルやロジックが単純なので関数型のメリットなし
・ゲーム系→常に時間変化を扱うので関数型のメリットなし
・業務系→PGの単価が上がって割に合わないので関数型のメリットなし

**デフォルトの名無しさん** · 2018/08/06(月) 21:28:53.61

関数型の定義が未だに分からない
2だけならどの言語でも原則として受け入れられているんじゃないの

**デフォルトの名無しさん** · 2018/08/06(月) 21:45:44.03

関数型はテストするまでもなく結果の明らかな極めて宣言性の高いコーディングができるというのが実用上最大の強みなわけだけど、
関数型マニアの関心は主に無限リストやら再帰やらモナドやら、自らその宣言性を捨てるテクニックにばかり向いていて、
結局関数型の何が嬉しいのかよくわからん状態になってしまってるのが現状

**デフォルトの名無しさん** · 2018/08/06(月) 21:58:21.43

具体的にはどんなコードになるの？
そんな単純なコードの断片だけを組み合わせるだけで実用に耐えうる可読性や性能を発揮できるもんなの？

**デフォルトの名無しさん** · 2018/08/06(月) 21:59:00.02

関数単位、メソッド単位でなるべく純粋にしておくのは重要
短い関数内部の実装まで純粋にしようとするのは宗教

**デフォルトの名無しさん** · 2018/08/06(月) 22:15:10.24

平気で数百メガあるようなデータに対して副作用のないメソッドチェーンで加工するのって普通にやることなの？

**デフォルトの名無しさん** · 2018/08/06(月) 22:27:24.52

>>617
そういうのはステップ毎に一時ファイルに書き出すのが普通でしょ
COBOL時代からの伝統的なスタイルであり、今でもHadoopなどに受け継がれている
副作用がなくむしろ関数型的だ

**デフォルトの名無しさん** · 2018/08/06(月) 23:04:02.54

じゃあ数メガぐらいのデータなら？

**デフォルトの名無しさん** · 2018/08/06(月) 23:11:20.61

遅延評価だったりストリーム使えるんなら大体気にしなくていいんじゃないかね

**デフォルトの名無しさん** · 2018/08/06(月) 23:47:33.03

関数型言語の本質は関数そのものを柔軟に扱うことだと思うんだけどな
例えばジェネリック関数のある言語ではジェネリック関数をジェネリックなまま引数や戻り値として扱えないと関数型言語っぽくない気がする

**デフォルトの名無しさん** · 2018/08/06(月) 23:57:07.45

>>613
副作用はよろしくない、というのは確かに広く受け入れられている。
でもHaskellなどが要求する基準は、もっとずっと高い。
ちょっと前にstackツールのコードを見たことがある。今どうなってるかは知らんが当時は、
ある純粋な関数の中でデバッグ用ログをより詳細に出力するってフラグを、ソースコードに即値でベタ書きしていた。
これは他の言語では例えば環境変数を読み込む関数をその場で実行すれば良いだけなのだが、
Haskellでそれをやろうとすると、関数のシグニチャを非純粋なものに置き換えて、使用する全箇所も合わせて換えるか、
あるいはフラグを引き渡す配管を新設するか、などの工事が必要になる。

**デフォルトの名無しさん** · 2018/08/07(火) 00:00:17.86

>>620
それは勘違い
遅延ストリームでステップ毎にコピーしてるんなら、コピーするオブジェクト数はバッチでステップ毎に全件コピーするのと変わらん
というかメモリアクセスが細切れになる分だけ遅くなる
遅延ストリームはレイテンシの低減には有効だけどスループットも下がるよ

**622** · 2018/08/07(火) 00:12:00.15

...という工事が必要になる。だから仕方ないと言えなくもない。

このような事態は純粋な言語では良くあるのだが、このことだけで、すわHaskellあかんやん、は早計だと思う。
Implicit ParametersやGivenのようなアイデアも出てきてるし、これは解決する余地のある課題なのかもしれない。
あるいはこのような事態を引き起こす設計に問題があるのかも。

**デフォルトの名無しさん** · 2018/08/07(火) 00:18:57.06

次世代言語たって、シングルスレッドのJSをこねくり回してドヤってる人と
Native言語でハードウェアの性能を最大限引きだそうとしてる人とで
必要とするもの違うからいっしょに議論してもかみ合わない

**デフォルトの名無しさん** · 2018/08/07(火) 00:20:39.37

そもそもハスケルの仕様通りの評価順序で実装してたらまともな実行速度でないっしょ。
そういうごまかしを含んでる時点でしょーもねーわ。

**デフォルトの名無しさん** · 2018/08/07(火) 00:30:11.90

副作用はよろしくない、といってるくせに再帰やら遅延ストリームやらモナドやら状態依存のコードを好んで書きたがるのが関数型マニア
そもそも状態に依存するコードなんか極力書くな、避けられるならモナドなんか使うな、という正論を言えない空気があり、
競って予測困難で難解なコードを書いて「俺すげえ」のマウント合戦を繰り広げている
こんな状態で流行るわけがない

**デフォルトの名無しさん** · 2018/08/07(火) 01:14:56.51

状態依存は避けられないのに状態を禁止してしまったからやたらと状態関連が発達してしまっているけど、状態なしで書ける部分と状態が必要な部分を分けて書くという理念は守られているはず……

**デフォルトの名無しさん** · 2018/08/07(火) 01:27:00.12

Haskellの定義を知ってる人ならいるけど関数型の定義は誰も知らないんだよ
だから「Haskellは関数型である」とか
「Haskellマニアと関数型マニアは同一人物である」とかいう根拠がそもそも存在しない

**デフォルトの名無しさん** · 2018/08/07(火) 01:37:43.21

つまりおまいらはまたオブジェクティバラブルなコード時代に戻るというの？

**デフォルトの名無しさん** · 2018/08/07(火) 01:38:48.13

日本語でおｋ

**デフォルトの名無しさん** · 2018/08/07(火) 01:39:33.68

関数型言語の定義ってラムダ計算を計算モデルにしてる言語でいいだろ

**デフォルトの名無しさん** · 2018/08/07(火) 02:09:48.40

そのラムダ計算には型があるのかないのか
副作用があるのかないのか
なにも定義されていない

**デフォルトの名無しさん** · 2018/08/07(火) 03:28:30.29

型なしラムダ計算だったとしてもlispだし型付ラムダ計算だったとしてもML/Haskell/etc…だし広義には問題なくない？
副作用の有無=純粋性は程度で片付けなきゃやってられない(どの汎用言語にもプログラムならどこかしら副作用が存在する)し

定期的に定義に固執しすぎなレス見掛けるけど自分でその問い掛けを考えたか？って感じなのが多い

**デフォルトの名無しさん** · 2018/08/07(火) 03:47:47.09

計算機科学の研究課題としては興味深いが
プロダクション用途ではないだろう
だから何が悪いというわけではないが

**デフォルトの名無しさん** · 2018/08/07(火) 06:13:33.64

>>614 がいいこと言った。
見通しが良いコードにするための宣言型言語のはずが
むしろ見通しを悪くしている。

**デフォルトの名無しさん** · 2018/08/07(火) 07:56:24.18

Scalaという見通しの悪い言語が関数型として世に知られてしまったのも不幸だったよね
意識高い系のオモチャに選ばれたのがScalaではなくF#だったら状況はだいぶ違っていたのではないか

**デフォルトの名無しさん** · 2018/08/07(火) 07:59:10.87

状態に依存する部分と純粋な部分を切り分けること自体は純粋関数型言語じゃなくてもできること

そもそもHaskell使える開発者が集まってるならHaskellじゃなくてもみんな極力そのように書くし、
強制されないと副作用ごちゃまぜコードを書くような土方はHaskellは使えない

純粋性を強制するメリットが禁止して柔軟性を失うデメリットに釣り合ってない

**デフォルトの名無しさん** · 2018/08/07(火) 08:35:30.11

純粋性を強制するメリット、を考えてみた。
例えばエディタの設定ファイルをHaskell自身で書くことができる。
設定ファイルがSafeHaskellであることを要請して、かつ設定操作に限定された型のみを許すようにする。

これで設定ファイルに、勝手にビットコインを採掘するスクリプトを忍ばせるような悪さができなくなるし、
Haskellそのものの柔軟性を活かして好きなだけ設定を短く表現できる。
安全さと強力さが両立された。

**デフォルトの名無しさん** · 2018/08/07(火) 08:38:42.25

Haskellは状態に依存するコードを書こうとすると途端に
可読性の低い冗長なコードになるのがダメなところだと思う
純粋な部分の構文に比べて手抜きすぎなんだよ

**デフォルトの名無しさん** · 2018/08/07(火) 08:54:53.62

手抜きではないだろ、むしろ逆
worldを隠しつつ宣言的に書くという変態技のために
モナド用の構文糖衣が多数あるせいで関数型の簡潔さが失われている

**デフォルトの名無しさん** · 2018/08/07(火) 09:11:21.06

シンタックスシュガーを幾ら用意しても簡潔に書けるようにする工夫がないから
どう書いても冗長って話なんだけど？分かってないなぁ

**デフォルトの名無しさん** · 2018/08/07(火) 10:46:00.40

それは手抜きと表現すべきではない。わかってないなあ

**デフォルトの名無しさん** · 2018/08/07(火) 10:58:16.01

>>642
じゃあ例えばどういう工夫なの？
お前のHaskellの理解力が試されてるから慎重に答えてね
無理なら別に逃げてもいいよ

**デフォルトの名無しさん** · 2018/08/07(火) 11:45:14.63

工夫するたびに言語の差は大きくなって言葉が通じなくなる
逆に言語を一つにしたければチューリングマシンだとかラムダ計算だとか
人が手を加えないまるで手抜きのような方向に行けばいい

**デフォルトの名無しさん** · 2018/08/07(火) 11:56:41.38

>>644
そうだなぁ。何でもいいんだけど、たとえば in-place quicksort をHaskellで可読性高く書けるかって話ですよ
いままでCにも劣る可読性のコードしか見たことないわ
だから、お前が可読性高い in-place quicksort を書いて見せたらこっちの意見は取り下げてもいいけどね

無理なら別に逃げてもいいよw

**デフォルトの名無しさん** · 2018/08/07(火) 11:56:53.80

関数型は実行モデルに由来する制約が少なくて言語設計の自由度が高い分、アイランドモンキー族にとって馴染みにくいものになってると思うんだよな
「結論から言え」なカルチャーが色濃く出すぎてる

**デフォルトの名無しさん** · 2018/08/07(火) 12:42:49.18

>>646
お前の可読性の基準なんかこっちはしらんがな
お前が言う工夫が例えば何かって聞いてんだよ
まさかノーアイデアで批判だけしてんの？

**デフォルトの名無しさん** · 2018/08/07(火) 13:44:16.06

可読性が低く冗長なのが問題だ。簡潔に書ける工夫があればよい。
例えばどういう工夫が？
例えば in-place quicksort が問題だ。簡潔に書ける工夫はないだろ？

----
まあ問題意識は判った。確かに可読性と速度の両立は課題だと思う。

**デフォルトの名無しさん** · 2018/08/07(火) 13:56:33.53

CとHaskellの両立ができないやつは二刀流を自粛している
これは自粛であって禁止ではない

**デフォルトの名無しさん** · 2018/08/07(火) 14:11:05.26

あれっひょっとして >>642 は
「もっと状態方面を簡潔に書けるよう工夫しろよ」って非難してるのか。
だとしたら誤読だったすまん。

**デフォルトの名無しさん** · 2018/08/07(火) 14:14:10.11

インプレースに書かなくてもインプレースにしてくれるのが stream fusion

**デフォルトの名無しさん** · 2018/08/07(火) 14:20:07.94

副作用を書かなくても書ける（副作用禁止とは言っていない）

**デフォルトの名無しさん** · 2018/08/07(火) 16:25:52.99

>>633
> そのラムダ計算には型があるのかないのか
> 副作用があるのかないのか

副作用を入れたものは本来はλ計算ではないよ
そういう変てこなバリエーションをデッチ上げて「何ちゃらλ-calculus」とか呼んで発表してるのは幾らでもあるがゴミばかり
状態などというものを考えず単純に構文的な置き換えだけで扱えるλ計算の長所を破壊し放棄する拡張をしても何もメリットはない
単にほとんど誰にも論文のカウント数を１増やすだけ
まあ御当人の学位取得や助教職のアプリケーションには有効なのかも知れないが

**デフォルトの名無しさん** · 2018/08/07(火) 16:27:13.31

>>654訂正
誤> 単にほとんど誰にも論文のカウント数を１増やすだけ
正> 単にほとんど誰にも読まれない論文のカウント数を１増やすだけ

**デフォルトの名無しさん** · 2018/08/07(火) 16:59:37.73

モナドクラスは副作用を入れたinstanceと入れないinstanceの見た目を同じにする
副作用を禁止しても見た目が美しくなったりしない
Haskellには副作用を禁止するモチベーションがない

**デフォルトの名無しさん** · 2018/08/07(火) 17:10:14.56

副作用あったら遅延評価できないじゃんｗｗｗｗｗ

**デフォルトの名無しさん** · 2018/08/07(火) 17:44:51.87

>>648
ここはHaskellスレじゃないんですよ？
ゴミ言語にはゴミである理由さえ説明すれば十分ですよ

**デフォルトの名無しさん** · 2018/08/07(火) 21:56:56.28

Inplaceが必要な時はHaskellを使うべきではない
Inplaceが不要な時に力を発揮する言語だし、Inplaceなんて避けておけというメッセージのこもった言語だ

**デフォルトの名無しさん** · 2018/08/07(火) 22:38:15.68

>>659
それって言い方を変えると
HaskellもPythonみたいにクリティカルな部分はCで書いてそれ呼び出せ
って解釈できる気がするんだが、そう解釈しておk？飛躍しすぎ？

**デフォルトの名無しさん** · 2018/08/07(火) 23:17:08.03

>>660
個人的には正直そうした方が良いと思う

**デフォルトの名無しさん** · 2018/08/07(火) 23:57:01.73

たかがin-placeが必要なだけでCの助けが必要って？
そんなウンコは次世代言語に相応しくないな

**デフォルトの名無しさん** · 2018/08/08(水) 00:39:35.00

結局C++で全部書けばいいじゃんってなる

**デフォルトの名無しさん** · 2018/08/08(水) 00:41:13.08

>>662
なるべくin-placeは避けろという言語に対してin-placeがかけないなら云々とかもう思想が合ってないとしか言いようがないな

**デフォルトの名無しさん** · 2018/08/08(水) 00:46:04.90

Haskellは富豪プログラム専用。in-placeがどうしても必要になるような貧乏人の道具ではない

**デフォルトの名無しさん** · 2018/08/08(水) 01:04:09.78

副作とノー副作を合一合体して書けるScalaサイキョってことか？

**デフォルトの名無しさん** · 2018/08/08(水) 01:05:18.29

ちなInplaceって何ンゴ？

**デフォルトの名無しさん** · 2018/08/08(水) 01:17:44.98

関数型言語に学ぶ価値はあるけど使う価値はないっ昔から言われてるじゃん
Monad勉強してへーうまくできてんなー(実行効率悪そうだけど)
って思っときゃいいの
そして最近の言語はOptionalとかいいとこだけうまく取り込んでるわけだ

**デフォルトの名無しさん** · 2018/08/08(水) 01:33:19.58

シンプルさと実用性を兼ね備えたF#が最強でいいよ

**デフォルトの名無しさん** · 2018/08/08(水) 06:39:46.68

>>669
F#って、何処で使われてるの？

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

既存の手続き型言語で培われてきたアルゴリズムは
ミュータブルなデータ構造に対して最大限の効果を発揮するものなんだから
イミュータブルなデータ構造が基本の言語で同じことをやろうとするのが誤り

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

イミュータブルなデータ構造の方が速い、ってケースはあり得るのかしらん

**デフォルトの名無しさん** · 2018/08/08(水) 08:23:57.11

ミュータブルがイミュータブルを包含するなら無い。

**デフォルトの名無しさん** · 2018/08/08(水) 08:26:42.80

速いってケースは思いつかないけど(ヒープを遠慮なく使う時点でたぶんアウト)
SSAとかは興味深い

**デフォルトの名無しさん** · 2018/08/08(水) 08:42:20.41

なんか俺がいなくても結局誰かをガイジ呼ばわりして叩くスタンスには変わりないんだな

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

誰だよ

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

いや？引き続きお前がガイジだけど？

**デフォルトの名無しさん** · 2018/08/08(水) 09:24:26.65

ビットコドンドコで大負けくらってる僕よりガイジーヌなやちゅなんておらんJARO草ァwwww
んでさでさ、Inplaceて何ンゴンゴ？＿？

**デフォルトの名無しさん** · 2018/08/08(水) 09:48:10.71

宣言的に書くならC#のLinqよりF#で書いた方が速いね
もちろん速くするだけならC#の方が速いけど

>>670
金融、財務とかかね
stackoverflowのアンケでは給料の高い人が使ってる言語の１位になってるし
日本じゃほぼ使われてないのかもしれんけど

**デフォルトの名無しさん** · 2018/08/08(水) 11:11:01.92

>>677
それが変わったとは言ってなかろうw

**デフォルトの名無しさん** · 2018/08/08(水) 11:33:37.96

https://prtimes.jp/main/html/rd/p/000000004.000034075.html
日本だとgoやな

**デフォルトの名無しさん** · 2018/08/08(水) 11:39:50.23

https://insights.stackoverflow.com/survey/2018/#top-paying-technologies
stackoverflowはこれやな
トップ3は関数型やのう

**デフォルトの名無しさん** · 2018/08/08(水) 12:50:00.95

Clojureたっかｗ

**デフォルトの名無しさん** · 2018/08/08(水) 12:50:15.63

GoもKotlinもTSももう次世代じゃなくて現世代だな

**デフォルトの名無しさん** · 2018/08/08(水) 15:37:13.59

関数型言語が高いんじゃなくて関数型言語使えるような人は土方と違って生産性も収入も高い人が多いってだけなんだよな。

**デフォルトの名無しさん** · 2018/08/08(水) 15:50:13.09

なんでもそうだけど、役に立たない仕事ほど年収が高いんだよね。