次世代言語議論スレ[Rust Kotlin Haskell]第6世代 [無断転載禁止]©2ch.net

**デフォルトの名無しさん** · 2017/08/28(月) 21:53:37.12

※前スレ
次世代言語議論スレ[Go Rust Scala Haskell]第5世代
http://mevius.2ch.net/test/read.cgi/tech/1497311647/

**デフォルトの名無しさん** · 2017/09/22(金) 05:39:47.03

>>602
ソースの見通しが悪くなってバグの検出が難しくなる

**デフォルトの名無しさん** · 2017/09/22(金) 07:53:43.74

IDE補完が効きまくるという点で静的型が好き。
phpStormとか使うとphpでも補完効きまくるようになるん？

**デフォルトの名無しさん** · 2017/09/22(金) 08:34:49.37

>>601
10年以上Haskellメインで使ってますが、
あなたの言うIntへの型変換の「酷さ」が分かりません。

他言語と比べて何か問題あるのでしょうか。

**デフォルトの名無しさん** · 2017/09/22(金) 09:10:52.08

>>605
Haskellメインの現場ってどういう環境です？研究職？

**デフォルトの名無しさん** · 2017/09/22(金) 09:45:24.85

Haskellみたいなのを研究に使っていたら逆にやう゛ぁいわ
メインはホビーだろ

**デフォルトの名無しさん** · 2017/09/22(金) 09:49:39.95

まず初めに現場かホビーかの分岐があるのになぜ現場に限定するのか

**デフォルトの名無しさん** · 2017/09/22(金) 11:00:09.62

>>605
え？計算毎にいちいちNum経由にするのが酷くないって？
お前もしかしてHaskell使ったこと無いんじゃないの？

**デフォルトの名無しさん** · 2017/09/22(金) 11:06:23.68

Haskellメイン(仕事とは言ってない)

コンパイラとかの文字列処理や、モデルの妥当性検証とかに使うならまだしも、
数値計算でHaskellw
Repa位しか優位性ないだろ

**デフォルトの名無しさん** · 2017/09/22(金) 11:40:01.90

>>609
Numは型ではなく型クラスです。

具体的には、どの型からInt型への変換が酷いのでしょうか。
Stream Fusion は働かないのでしょうか。

**デフォルトの名無しさん** · 2017/09/22(金) 11:45:22.74

>>609
失礼、Stream Fusion と言うより、書き換え規則ですね。

書き換え規則が働けば、大抵の型変換は必要最小限のオーバーヘッドで行われる筈です。

**デフォルトの名無しさん** · 2017/09/22(金) 11:47:26.66

>>611
Numが型だとも型クラスでないとも言ってないし、
Stream Fusionだろうと変換はいるけど？
お前さっきから何知ったかぶってるの？

**デフォルトの名無しさん** · 2017/09/22(金) 11:48:26.85

>>612
「はずです」って、それ結局自分で書くだけだろ？

**デフォルトの名無しさん** · 2017/09/22(金) 11:49:20.78

こういう机上だけで語るクソ野郎がいるからHaskellは嫌い

**デフォルトの名無しさん** · 2017/09/22(金) 12:01:58.15

例えばInt型の３って名前の関数をNumタイプクラスの３って名前の仮想関数に変換する関数で
変換してそれをDoubleを使う関数にいれるパターンだよな。

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

だから具体的なコード書けって。変な勘違いしてるかもしれないんだから

**デフォルトの名無しさん** · 2017/09/22(金) 12:33:30.94

仮想関数は酷いってのは常識になりつつある
オーバーロードはいいがオーバーライドは酷い
だがオーバーロードとオーバーライドを勘違いする非常識なやつもまだいっぱいいる

**デフォルトの名無しさん** · 2017/09/22(金) 12:52:13.95

オーバーロードこそゴミだろ
型が柔軟になればなるほど邪魔になる

**デフォルトの名無しさん** · 2017/09/22(金) 13:14:10.74

>>601
ある型の値をInt型の値へ変換する際にあなたにとって酷いことが起きる、
あるいはあなたにとって酷いプログラムコードになる、という話ですよね。

>>609
Int型への変換の話の中で「Numを経由する」という言い方を聞いて、
あなたが Num を型だと勘違いしていると思いました。
大変失礼しました。

ある型の値をInt型の値へ変換する際は一度Num型クラスのインスタンス型の値へ変換し、
それを改めてInt型の値へ変換しないといけない、
あるいはそういう型が多い。
あなたはそう思っているのでしょうか。

もしそのような場合でも、私書き換え規則があれば経由しないようにできると私は言いました。
標準ライブラリの中で定義されている型で、
頻繁にInt型への変換が必要と思われる型に対しては、
書き換え規則がライブラリ内に書かれています。
自分で書く場合も一度書けば済むだけみます。
これが酷いのでしょうか。

改めて聞きますが、具体的にはどの型の値をInt型の値へ変換する際に、
Num型クラスのどの型の値を経由しなければならないのでしょうか。

**デフォルトの名無しさん** · 2017/09/22(金) 13:37:46.62

>>620
>改めて聞きますが、具体的にはどの型の値をInt型の値へ変換する際に、
>Num型クラスのどの型の値を経由しなければならないのでしょうか。
だから全部自分で書いた話だろそれ
VanillaじゃIntとIntegerすら必要だろ

そんな事言ったら何らかの形で暗黙の型変換許してる言語全部そうだわ
お前マジで頭の病院行ったほうがいいんじゃねえの？

**デフォルトの名無しさん** · 2017/09/22(金) 13:55:56.62

どっちもどっちだな。
両方病院言ったほうがいいかも。

**デフォルトの名無しさん** · 2017/09/22(金) 14:14:32.59

言語の問題を医学部に丸投げするなよ
今ここで必要なのは法学部か文学部のような能力だという現実を受け入れろよ

**デフォルトの名無しさん** · 2017/09/22(金) 14:19:32.05

>>621
Integer型の値をInt型へ変換する際に、
Num型クラスのどのインスタンス型にまず変換する必要があるのか、
その型を教えて頂けないでしょうか。

**デフォルトの名無しさん** · 2017/09/22(金) 14:52:17.51

具体的なコードを示せないのは、具体的なコードを示すとボロが出るからｗ

**デフォルトの名無しさん** · 2017/09/22(金) 14:56:44.72

>>624
はあ？Int側にするならNum Integer経由だろ？
お前さっきから関係ない話ばっかりじゃねーか

**デフォルトの名無しさん** · 2017/09/22(金) 15:01:10.70

>>625
書くまでもない気がするが一応な
https://ideone.com/MjF75Z
https://ideone.com/es7fao

**デフォルトの名無しさん** · 2017/09/22(金) 15:10:56.24

ほわ？そのコードの何が問題なんだ？
上も下も非常に妥当な挙動に見えるんだけど、いったいどうなって欲しいんだ？

**デフォルトの名無しさん** · 2017/09/22(金) 15:11:44.73

ああ、意図がわかった
こいつIntegralをNumって言った事とっかかりに揚げ足取りしたいんだな
IntegralはReal通してNumのサブクラスですよクソ野郎

**デフォルトの名無しさん** · 2017/09/22(金) 15:14:53.86

>>628
このクソ冗長なコードが妥当？w
これを解決するための機能まで作っておいて？w

**デフォルトの名無しさん** · 2017/09/22(金) 15:28:32.33

>>627
fromIntegral 関数は、Integer型の値をInt型の値へ変換する際に、
どのような他の型へも変換しません。
経由しません。

Inreger型の値をInt型の値へ変換するのにNum Integer を経由、
という言い方がおかしいと思うのですが。

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

>>631
言葉遊びばかりだな
fromIntegralはfromIntegerを使う時点でNum経由
あといちいち俺が言っていないことさも言ったかのように決めつけて反論するの、やめてくれないかな？

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

でもIntをDoubleに変換するときは２回変換するんだろ。

**デフォルトの名無しさん** · 2017/09/22(金) 15:54:31.81

そもそもHaskellで数値計算なんて
チューンしたところでLL並の速度なのに何を躍起になってんだか…
このクソ野郎には適材適所という言葉を送りたい

**デフォルトの名無しさん** · 2017/09/22(金) 15:59:41.73

>>632
fromIntegral = fromInteger . toInteger

Integer型の値からInt型の値への変換はどこも経由しません。

例えばWord型の値からInt型の値への変換は、
書き換え規則を働かせないようにわざわざすれば、
Integer型の値へ変換されてからInt型の値へ変換されます。

ですが、このような変換の書き換え規則を働かせないようにするメリットがありません。
初めから標準ライブラリに書かれていて、
プログラマは意識する事無くそれを使っているのだから。

ちなみに、私は>>627のコードが冗長だとは特に思わないです。
文字fromIntegralが長いと感じるのであれば、
fiにでも変えればいい話ですし。

**デフォルトの名無しさん** · 2017/09/22(金) 16:07:10.71

だから冗長な文を書くんだろうな

**デフォルトの名無しさん** · 2017/09/22(金) 16:16:34.49

上のが通ったらそれ暗黙の型変換じゃね？
そのほうが怖いわ

**デフォルトの名無しさん** · 2017/09/22(金) 16:20:54.19

>>630
え、何？まさかそこで暗黙の型変換して欲しいの？

**デフォルトの名無しさん** · 2017/09/22(金) 16:25:12.12

>>635
だからそれfromInteger使ってんだろ
そしてIntとWordが例外なのに、さも他に定義されてるように言いやがるし
詭弁が多すぎ

**デフォルトの名無しさん** · 2017/09/22(金) 16:30:27.19

>>637
あらゆる型で変換が必要だからおかしいんだよ
比較的面倒くさいOCamlでさえ1キャストで済む

**デフォルトの名無しさん** · 2017/09/22(金) 16:31:40.02

>>639
他にも色々な型の書き換え規則が定義されています。

ここで全て挙げるのはさすがに勘弁してほしいので、
興味がおありなら標準ライブラリを調べてみてください。

**デフォルトの名無しさん** · 2017/09/22(金) 16:36:07.88

>>641
いやお前が言い出したんだから、お前が挙げるんだよw
よくもまあこんな適当な事をw

**デフォルトの名無しさん** · 2017/09/22(金) 16:37:20.96

そしてこれが現実ｗ
http://hackage.haskell.org/package/base-4.10.0.0/docs/src/GHC.Real.html#line-442

**デフォルトの名無しさん** · 2017/09/22(金) 16:37:24.43

そもそもIntとIntegerを混ぜて演算する時なんてそうあるか？
浅学非才な俺には設計が悪いとしか思えないんだけど。どういう時に必要なんだ……

**デフォルトの名無しさん** · 2017/09/22(金) 16:42:22.60

>>644
逆だぞ
そんな型揃えてまで速度欲しい具体的な演算を想定したら
Haskell自体を使わない

**デフォルトの名無しさん** · 2017/09/22(金) 17:05:23.17

>>645
いや、速度関係なく、取り敢えず型は揃えとかない？
関数作る時にわざわざ一つの引数はIntegerで一つはIntとかせんだろ？
俺は大体全部Intで作ってるから、Integerは即Intにしてるわ。みたいな

**デフォルトの名無しさん** · 2017/09/22(金) 17:09:55.82

>>643
そのファイルだけではなく、他にもあります。
grepかけてみてください。

**デフォルトの名無しさん** · 2017/09/22(金) 17:53:28.33

>>619
おっと、型クラスへの罵倒はそこまでだ！

**デフォルトの名無しさん** · 2017/09/22(金) 20:04:54.06

そもそも人が
型とか、型クラスとか、
パブリック/プライベートとか
ポインタだとか
そういう言語側の都合を意識しちゃ
次世代言語として
ダメだと思うんだけどどう?

**デフォルトの名無しさん** · 2017/09/22(金) 20:08:01.73

HaskellやらOCamlやらの型は補助ツールであって言語の都合ではなかろ？

**デフォルトの名無しさん** · 2017/09/22(金) 20:24:36.31

え～、でも、そういうのも
言語側が裏で判断して処理してくれればいいじゃん
A.I.でもディープラーニングでもなんでも使ってさ
ハスケルでもエリクサーでも
古いコンピュータ言語の慣習にとらわれてて
全然、次世代って感じしないじゃん

**デフォルトの名無しさん** · 2017/09/22(金) 20:26:22.11

型がない言語にろくなものはないな…

**デフォルトの名無しさん** · 2017/09/22(金) 20:33:12.38

>>652
型がない言語って具体的に何？

**デフォルトの名無しさん** · 2017/09/22(金) 20:37:05.38

車の自動ブレーキと一緒で
危険な操作をできなくする方向で言語は進化してきているから
別に古い習慣とかじゃなく、そういう方向へ進化していくものだから

**デフォルトの名無しさん** · 2017/09/22(金) 20:40:16.61

危険な操作を禁止するといっても
やりたいことが出来なくなっては意味が無いので
その辺の制約の付け方が次世代で評価されるポイント

**デフォルトの名無しさん** · 2017/09/22(金) 21:16:44.42

変な操作を禁止する方向と
変な現象を報告するだけの方向があるぞ

そして両者の存在を認める方向と、相手の存在を禁止する方向がある

**デフォルトの名無しさん** · 2017/09/23(土) 03:41:51.45

むしろ自動ブレーキじゃなくてオートマチック車が
マニュアル車より速くなったとき次世代だと思うな。

**デフォルトの名無しさん** · 2017/09/23(土) 10:32:28.92

具体的には？

**デフォルトの名無しさん** · 2017/09/23(土) 10:47:51.80

アセンブラが人間が書くよりCの最適化のほうが速くなったときとか。

**デフォルトの名無しさん** · 2017/09/23(土) 10:48:52.56

ほぼもうなってんじゃん

**デフォルトの名無しさん** · 2017/09/23(土) 16:51:55.93

車もDCTの登場でオートマのほうが速くなったな。

**デフォルトの名無しさん** · 2017/09/23(土) 19:13:02.33

禁止するだけだともっと糞な方向に行くだけだろう。
規則で禁止しまくった SIer の現状を見ろ。
そうじゃなくてより安全な方向を提示するほうが正しい。

**デフォルトの名無しさん** · 2017/09/23(土) 19:54:26.15

そりゃそうよ。次世代と言われてるやつは大抵方向まで提示してるっしょ

**デフォルトの名無しさん** · 2017/09/23(土) 20:21:34.37

米Appleが「Swift 4.0」を公開、以前のコードを修正無しに利用できる互換性モードを新たに導入
2017年9月22日17:10 末岡洋子
https://mag.osdn.jp/17/09/22/171000

Swift 5の目標が確定、新たな発展プロセスを定義
https://www.infoq.com/jp/news/2017/09/swift-5-development-plan

**デフォルトの名無しさん** · 2017/09/23(土) 21:09:08.49

>>653
多分PHPのことを言ってるんじゃないかな。
結局動的言語ってテンプレート文字列使ってプログラミングするのと変わんないんじゃないかと思う。

**デフォルトの名無しさん** · 2017/09/23(土) 23:08:02.02

PHPとPerlはもはや門前払いだわ

**デフォルトの名無しさん** · 2017/09/23(土) 23:30:11.90

パールは多重ディスパッチ搭載されてるところが割と好き。使ったことないけど

**デフォルトの名無しさん** · 2017/09/24(日) 00:17:35.00

>>647
まだ言ってるよw

**デフォルトの名無しさん** · 2017/09/24(日) 00:33:10.78

やけんペェ～ルとプェチピィ使ってる公害はさっさと処分しましょうね～

あ · 2017/09/24(日) 01:03:00.91

まー、MT車でもニュートラルにしてブレーキペダル踏んでないとセルを回せない、なんて仕組みになったりしてるしな。
安全性としては進化しつつ、機能・機構としては複雑になったり踏切からの緊急脱出の手段を一つ捨てるといった退化してる。

結局、言語も何が正解かは使う人間と用途次第だろ。

「ポインタを捨てたりNullableとそうでない型すらもわけるのが正しい言語」「型なんて飾りです、キャストすりゃいいんです、電文？unionで解釈しましょう」みたいな言語が相容れうる訳がない。

**デフォルトの名無しさん** · 2017/09/24(日) 09:15:54.71

多重ディスパッチわりと好きなんだけど、搭載されてる言語少ないよなあ

**デフォルトの名無しさん** · 2017/09/24(日) 09:18:19.02

しかし時系列でみれば新しい言語ほど何かをするための専用の構文が追加される
傾向があって、その専用の構文では「それ」しか出来ない制限があることで
危険なことが出来なくなったり、読みやすくなったりしているのだから
次世代言語とはそういうものだろう

**デフォルトの名無しさん** · 2017/09/24(日) 11:08:39.74

ちょっと議論が抽象的すぎんよぉ
具体的に行こうぜ具体的に

**デフォルトの名無しさん** · 2017/09/24(日) 11:10:15.91

バイナリで語れよ

**デフォルトの名無しさん** · 2017/09/24(日) 15:15:34.52

>>672
それ自称シンプル言語()のGolangだろ
array、slice、map,chan。全てが専用構文
次世代言語は演算子もメソッド呼び出しだったりするから専用構文は少ないよ

**デフォルトの名無しさん** · 2017/09/24(日) 15:20:28.63

関数型言語の時代が来る事なんて一生ないよ

**デフォルトの名無しさん** · 2017/09/24(日) 16:49:57.99

もうそこまで新しい言語上の概念もないしな。

**デフォルトの名無しさん** · 2017/09/24(日) 18:21:51.74

COBOL「私を殺すと言ってた言語は、みんな死んだよ」
http://www.nurs.or.jp/~ogochan/essay/archives/5033

**デフォルトの名無しさん** · 2017/09/24(日) 18:23:00.77

LLVMって第一級関数ないんだよな……
HaskellとはバックエンドにLLVMあるんだけど、どうやって実装してるんだろ？

**デフォルトの名無しさん** · 2017/09/24(日) 18:51:05.70

新しい概念がなくても、古すぎて記憶にない概念を蒸し返すだけで十分たのしそうだな

**デフォルトの名無しさん** · 2017/09/24(日) 18:53:11.57

>>679
インタプリタで実装できるんだから、極端な話、インタプリタをそのまま埋め込んでしまえばいい。
それをいかに効率化するかは最適化次第だけど、基本的にはエミュレーションだよ。
CPU命令セットとの親和性の高い一部の低レベルな言語を除けば、
コンパイラというのは君が想像してるより非常に複雑でソースからかけ離れたコードを生成するもんなんだよ。

**デフォルトの名無しさん** · 2017/09/24(日) 19:10:03.30

>>681
いやまあ、せやね。Haskell が吐くアセンブラ複雑すぎてビビったことあるわ
しっかしやっぱりインタプリタ埋め込みかあ。Haskellもそうしてるんだろうか？

**デフォルトの名無しさん** · 2017/09/24(日) 23:54:19.09

c/c++ のコンパイラしか知らんけどそんなに複雑なものが必要かね。
あんまりイメージできないな。

**デフォルトの名無しさん** · 2017/09/25(月) 00:13:26.46

C++だってラムダはそれなりに複雑と思うな～

**デフォルトの名無しさん** · 2017/09/25(月) 00:29:03.12

ブラウザがDOM操作とかgetとかpostとかするのもインタプリタのように見える
JSをいくら最適化しても複雑なデータ構造はそのままだから

**デフォルトの名無しさん** · 2017/09/25(月) 00:30:46.06

>>664
まだ仕変とかABIとか言ってるのかよこの言語。
いい加減枯れろよ

**デフォルトの名無しさん** · 2017/09/25(月) 01:47:53.39

ポストC++としてはD言語が最適だわ
やっぱnullは便利

**デフォルトの名無しさん** · 2017/09/25(月) 10:51:28.03

Dは指針に欠けていて、書けるコードの種類が多すぎる。
最近はクラスは使わないとか言われた時はビックリしたわ。割と好きだけどさ

テンプレートとオーバーロードの充実っぷりはC++の比じゃないし、プロパティあるし、UFCSある所とか好きだけど、演算子の定義を構造体中に書かないといけない所だけは解せない

**デフォルトの名無しさん** · 2017/09/25(月) 12:10:20.51

>>679
llvmのレベルでクロージャー定義されたらつぶし効かなくなるだろ
llvmにそれを期待するのが間違ってる

**デフォルトの名無しさん** · 2017/09/25(月) 12:40:19.83

>>689
期待はしてないぞ。ヒープに関数を展開する機能がないのに、どうやってヒープに関数を展開してるんだろう？って疑問を覚えているだけだぞ

**デフォルトの名無しさん** · 2017/09/25(月) 12:54:44.69

>>690
llvmを持ち出す意味がわからん
cで実装されてる関数型言語はどうやってクロージャー実現してんだろ？とか
jitってどうやったら実現できんだろ？
という疑問の持ち方ならわかる

**デフォルトの名無しさん** · 2017/09/25(月) 13:05:30.42

>>691
「Cで実装されてる関数型言語はどうやってクロージャを実装してるんだろう」でもほとんど同じ意味だけど、別にLLVMでもいいじゃん。俺がLLVMの方を意識してるからLLVMって書いてるだけだが

Jitの方はよくわからん。関数型言語一般でJit使ってるの？

**デフォルトの名無しさん** · 2017/09/25(月) 13:25:06.64

すごい素朴には
class {
unsigned int eax;
...
void add();
...
}
みたいなアセンブラ実行クラス作ればできんじゃないの？

**デフォルトの名無しさん** · 2017/09/25(月) 15:00:43.13

そもそも関数を動的に生成する必要はない
クロージャは環境を引数に取る関数として実装するのが普通だ

**デフォルトの名無しさん** · 2017/09/25(月) 15:37:00.33

動的に関数を作るのはコンビネーターで結合させるんだろ。

**デフォルトの名無しさん** · 2017/09/25(月) 15:40:30.80

その前にまず再帰関数で100の階乗を計算すればいい
関数を100個作るやり方とは違うやり方がわかる

**デフォルトの名無しさん** · 2017/09/25(月) 20:30:11.80

>>692
単なる疑問ということはわかった
物理cpuとそのabiを扱うことを前提にしてるllvmと
λ計算を理論的基礎にしてる関数型言語とでは
メモリモデルが全く違うんだからいきなりマッピングを考えるのは
無理があるとだけ

**デフォルトの名無しさん** · 2017/09/26(火) 00:58:41.50

ハスカルデスクトップソフト作れるようになった？

**デフォルトの名無しさん** · 2017/09/26(火) 13:49:21.20

だからそれは
データは制御フローに影響を与えるし
制御フローはデータに影響を与える
このように双方が影響しあってプログラムが展開していく
(まるで電磁波のようだ)
この複雑性はソフトウェアが有用であり続けるためには仕方が無い

なので
・制御フローがデータに何か書き込むタイミング
・制御フローがデータを読み取って分岐するタイミング
の二つをトラップして言語やシステムで何かサポートしてやろう
というのが基本的な考え方なんだよ

**デフォルトの名無しさん** · 2017/09/26(火) 14:35:36.67

制御フロー？は座標系や文字のエンコーディングに影響を与えるやつですか？
エンコーディングに依存しないデータが欲しいです

**デフォルトの名無しさん** · 2017/09/26(火) 16:08:19.45

つまり、いつ実行するか？今でしょ。
ということだな。

**デフォルトの名無しさん** · 2017/09/26(火) 21:28:19.34

マイクロソフト、量子コンピュータ向けプログラミング言語を発表 https://ndjust.in/t7GAzsXB

俺の予測したとおり次世代言語は機械学習に最適化された言語ってことだな