次世代言語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/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

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

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

役に立たない仕事で収入を得るのは特別な能力が必要だから当然

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

Google社内では本当にDart使用していると言い張っているようだな

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

俺を無視するな無能ども

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

多数派ほど年収コストカットの標的になる

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

>>684
それな
ここは次世代スレだからそろそろ退場して欲しい

**デフォルトの名無しさん** · 2018/08/09(木) 07:19:31.82

最近の言語ってなんで文末のセミコロンを無くしたがるのかはホント理解できんね

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

文末に。を付けないやつが言うな。

**デフォルトの名無しさん** · 2018/08/09(木) 10:42:24.61

うまいツッコミｗｗ

**デフォルトの名無しさん** · 2018/08/09(木) 11:20:46.07

文末は「ｗ」を付けようｗ

**デフォルトの名無しさん** · 2018/08/09(木) 11:32:06.24

正解が二個以上あっても正気を保てるのは言語オタクだけだ
だから改行を唯一の正解とする
改行の強制はインデントの強制でもある

**デフォルトの名無しさん** · 2018/08/09(木) 11:45:07.69

。文頭に。

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

>>691
じゃあ次世代言語上げてくださいますか？

**デフォルトの名無しさん** · 2018/08/09(木) 12:14:58.58

次世代言語って、現世代では全く使われていない言語を指すの？
そうなると、ここでは書いたことの無い言語の話しか出来ないんじゃないかな。

もう少し冷静に、新しいか、成長の余地がある言語にすりゃ良いかと思うよ。

新しくもないし凝り固まってるしパラダイムも充分に理解されてるがメジャーではない言語、を入れるかに悩むならわかるけど。

**デフォルトの名無しさん** · 2018/08/09(木) 12:30:39.38

Javaみたいなゲージ御用達スーパーゲージ変換じゃなけりゃなんでも良いだろ

**デフォルトの名無しさん** · 2018/08/09(木) 12:41:46.37

みんなスルースキル高くて草

**デフォルトの名無しさん** · 2018/08/09(木) 12:49:51.63

>>699
業務でってのが一つの基準な気がするけど

**デフォルトの名無しさん** · 2018/08/09(木) 13:56:19.73

つまりｗ改行しなければｗいいんだなｗｗｗｗ

**デフォルトの名無しさん** · 2018/08/09(木) 20:59:51.98

スレタイの中だとrustかswiftくらいしか成長の余地なくない？

**デフォルトの名無しさん** · 2018/08/09(木) 21:20:23.73

Kotlin もよろしく

**デフォルトの名無しさん** · 2018/08/09(木) 21:38:29.91

kotlinは生まれながらにしてjavaの業を背負ったどん詰まり言語じゃん

**デフォルトの名無しさん** · 2018/08/09(木) 22:30:00.52

だって必要ないじゃん;
意味ある？;
これ;
(;_;);

**デフォルトの名無しさん** · 2018/08/09(木) 22:44:04.28

てか何気にRustよりGoの方が古いってのは意外だったな

**デフォルトの名無しさん** · 2018/08/09(木) 22:47:27.72

>>706
実行環境についての話でいいなら、Kotlin/Nativeが成長途中という状況だよ

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

>>708
ゆとりwwwww

**デフォルトの名無しさん** · 2018/08/09(木) 23:33:53.62

>>709
kotlin nativeはjavaに足を引っ張られたkotlinに足を引っ張られるんじゃないかと勘ぐってるけどそんなことないのかな？

**デフォルトの名無しさん** · 2018/08/09(木) 23:40:49.80

それは逆コンパイルしたら中身jvmだったりしないの?

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

しないと思うんだがなあ

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

じゃあなんでScalaは死んでしまったの？

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

不器用でScala…

**デフォルトの名無しさん** · 2018/08/10(金) 02:00:19.91

>>681
これ見るとkotlinよりscalaの方が求人多くね？
kotlinも死んだ？

**デフォルトの名無しさん** · 2018/08/10(金) 07:23:01.25

>>715
クッソﾜﾛﾋﾟｵ