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

**デフォルトの名無しさん** · 2018/01/08(月) 13:31:41.59

ネットは筆記試験のようなものだよ
筆記試験もネットと同じような批判をされて面接重視になった

**デフォルトの名無しさん** · 2018/01/08(月) 14:51:35.25

>>627
おま環だろ？

**デフォルトの名無しさん** · 2018/01/08(月) 18:13:08.29

おま国だろ

**デフォルトの名無しさん** · 2018/01/08(月) 20:27:12.48

Elmってどうなんだろ。インスパイアされたhyperappとかいうのがあるけど。
新しいjsライブラリは結構TypeScriptサポートしていて嬉しい

**デフォルトの名無しさん** · 2018/01/08(月) 22:54:56.01

全てのJSプロジェクトはTypeScriptにしろ

棒案件で立ち上げ時にクソバカの老害オッサンがJSでコード書き始めたせいで
どんだけ苦労したか

**デフォルトの名無しさん** · 2018/01/08(月) 23:52:24.85

TypeScriptは認めるがBabelはほんとやめてほしい
わざわざビルドを面倒にするだけの見返りはどう考えても無い

**デフォルトの名無しさん** · 2018/01/09(火) 00:49:10.43

Babelないとjsxも書けないし新しい文法も使えないぞ
糞まみれの生JSに戻る気か？

**デフォルトの名無しさん** · 2018/01/09(火) 00:53:34.69

下痢便が軟便になる程度だろ

**デフォルトの名無しさん** · 2018/01/09(火) 17:04:26.38

TypeScriptもいずれノーマルjsに吸収される

**デフォルトの名無しさん** · 2018/01/09(火) 17:11:58.74

>>636
それ理想的だね。型を最初からサポートしたほうが良い。
typescriptを中心に据えてオプションで型無しをサポートする方針にしたほうが処理性能向上に寄与する気がする。
あとnumber型を廃止して

**デフォルトの名無しさん** · 2018/01/09(火) 18:53:23.55

>>621
もう叩いてないぞ。
割と興味出てきたのに、誰も、ここが良い！を言わないからつまんねえのって思ってるだけだよ。
スレタイに入れたいだけじゃねえの？って。

正直、使ってみた感じは悪くないけど、この便利な言語でこういう事すると楽かな？みたいなのがあんまり思いつかんので、良いサンプルは見たいな。
GoのGoroutineやchanの気軽さとか、erlangのプロセスの考え方みたいなのとか。

**デフォルトの名無しさん** · 2018/01/09(火) 18:54:28.23

>>621
スレタイに入れた奴が居るはずだろw

**デフォルトの名無しさん** · 2018/01/09(火) 19:50:56.76

Haskell使った有名なアプリってなんかあるの？

**デフォルトの名無しさん** · 2018/01/09(火) 19:55:51.91

xmonad

**デフォルトの名無しさん** · 2018/01/09(火) 20:14:49.53

monadius

**デフォルトの名無しさん** · 2018/01/09(火) 21:09:47.45

これとか？
https://code.facebook.com/posts/745068642270222/fighting-spam-with-haskell/

**デフォルトの名無しさん** · 2018/01/09(火) 21:25:06.32

データフィルタ的に使うのなら確かにいいかもな。

**デフォルトの名無しさん** · 2018/01/09(火) 23:27:20.37

>>641
linuxを、デスクトップ用途で使うならいいけどなぁ。
wafとかで革新的なやつとか無いのかね？

**デフォルトの名無しさん** · 2018/01/13(土) 21:15:44.50

>>640
Pandoc

**デフォルトの名無しさん** · 2018/01/15(月) 20:41:07.18

関数型プログラミングの流行も落ち着いた感じかね？

**デフォルトの名無しさん** · 2018/01/15(月) 21:19:36.73

さいなー

**デフォルトの名無しさん** · 2018/01/15(月) 23:18:02.53

落ち着いたも何も、みんな身につけ終わっただけだろ

**デフォルトの名無しさん** · 2018/01/16(火) 13:33:12.35

せやな

**デフォルトの名無しさん** · 2018/01/16(火) 22:37:54.03

ビットコインの流行「奴は流行の中で最弱」

**デフォルトの名無しさん** · 2018/01/16(火) 23:05:29.36

関数型の後Pythonに戻ったら、それまでとも違うけど関数型でもないコードになった

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

pythyonって関数型書きやすい？

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

書きにくい

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

lambdaが書きづらいからとか？
やっぱ関数型プログラミングはRubyのほうが強いのか

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

Rubyと比べてどうかは知らんけど、Pythonのデータ構造や文法ならいわゆるPythonicな書き方が書きやすく読みやすいので関数型特化する必要がないので、関数型には書きにくい

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

なぜ関数型とRubyが、目的と手段なんですか
理想主義と現実主義ではだめなんですか

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

関数型って何をさすのか
よくそれだけで会話が通じるなと思うわ

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

言語の標本集合をさすんじゃないですか
現実の言語にはばらつきがありますが、平均すれば理論値に収束する筈だとか

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

標本がどうのこうのじゃなくて
会話噛み合ってないだろってことだよ
頭でっかちさん

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

そうやって悪態をつくのも会話ができない人の典型

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

rubyのfirst classですらないlambdaだって書きやすくはねーだろ

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

>>658
ほんとにな。
ラムダ一つとったって型なし、型あり
型にしたって、型に依存する型、型に依存する項（関数など）、項に依存する型とか色々あるのに。

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

PythonicとかPythonistaとか、改めて見るとすごい呼称だ。

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

>>653
書きにくいから、Python の公式文書では lambda で書いたコードを
手続き型の for ループへ書き換えることを推奨している

https://docs.python.jp/3/howto/functional.html

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

>>656
あれれ、日本国内ではそういう認識が浸透してるの？

世界的には Python の lambda が欠陥であることは広く知られていて、
改善に向けた議論も重ねられたけど、結局、作者のGuido氏が
「解けないパズル(unsolvable puzzle)」と匙を投げたという残念な
結論のまま現在に至っているという共通認識があります

https://mevius.5ch.net/test/read.cgi/tech/1415419907/197/

やっぱり日本在住の Pythonista がガラパゴスなのは昔から同じですね

http://mevius.2ch.net/test/read.cgi/tech/1345123070/70-71/

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

python のラムダの使い道ってほとんどがソートに渡す比較関数くらいだと思う。

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

世界的な認識のソースでも貼ってそうな場所にあるリンクが2chの別スレへのリンクで困惑している

**デフォルトの名無しさん** · 2018/01/18(木) 05:27:53.26

Pythonあまり知らんけど、上のリンク見てて思ったのは、

1. 自分で高階関数を作れない（ラムダ式が利用できる関数が少ないと書いてある）
2. where節みたいなスコープの限定されたローカルな書き捨ての関数を用意する文法がない（読みにくいでしょ？とか書いてある）

この辺の縛りがあるからでないかい？

**デフォルトの名無しさん** · 2018/01/18(木) 09:22:04.51

ごめん、>>669は寝ぼけて適当なこと書いたぽいから、無視しといて。

**デフォルトの名無しさん** · 2018/01/18(木) 21:25:08.77

関数型っのがどういう定義かは分からないけれど、
HaskellとPythonを比べると、パターンマッチが
なくて再帰が書きにくいと感じたり、
基本破壊的だから、わざわざ非破壊で書くのが
めんどくさいと感じる。

内包表記は似ていて良いかな。

**デフォルトの名無しさん** · 2018/01/19(金) 19:12:49.43

Schemeのマクロ定義でパターンマッチを使えるがすごい不人気だったよ
おそらくパターンマッチのアルゴリズムが透けて見えないと人気出ないよ

**デフォルトの名無しさん** · 2018/01/20(土) 08:12:20.84

うちのプログラマは大半がコトリンに移ったのでわしらラストを使うことにした

**デフォルトの名無しさん** · 2018/01/20(土) 15:07:10.20

イムータムルのない言語は全て糞

**デフォルトの名無しさん** · 2018/01/20(土) 16:54:37.17

関数型言語のパターンマッチって理論的な裏付けってあるんだろうか

**デフォルトの名無しさん** · 2018/01/20(土) 17:28:38.29

理論的てのが分からんけど、例えばリストを引数にとる関数なら、
空リストとSuccの場合を定義しとけば、帰納的に任意のリストについての適用結果が求められる、
とかそういうの？

**デフォルトの名無しさん** · 2018/01/20(土) 18:09:55.87

評価順序とかモチっと低いレイヤーでの動作規定ってことでないの？
ABIレベルでのさ。

**デフォルトの名無しさん** · 2018/01/20(土) 18:18:48.11

もしかして、あ氏？
だとしたら、お久しぶりです。

**デフォルトの名無しさん** · 2018/01/20(土) 20:48:41.14

>>676
そうそうそういうの
関数型ってって原理的にはあらゆるものが原始的な計算原理に還元できるものって理解してんだけど
パターンマッチはそういう裏付けあるのかなって疑問

**デフォルトの名無しさん** · 2018/01/20(土) 20:52:07.08

>>679
単なる場合分けだから裏付けもクソもない

**デフォルトの名無しさん** · 2018/01/20(土) 21:02:06.68

補足
パターンマッチは場合分け、つまり条件分岐そのものであり、
通常はそれ自体が原始的な計算原理の一つとして定義されるってことだぞ
だから裏付けなんぞ必要ない

**デフォルトの名無しさん** · 2018/01/20(土) 21:09:03.16

学術的なことは分からないけども、静的型のパターンマッチは網羅性を
コンパイル時にチェックしてくれることが多くて
それが凄くありがたい

動的型言語にパターンマッチを持って来ても上手くいかないのは、
上のメリットが得られないからでは？

**デフォルトの名無しさん** · 2018/01/20(土) 21:28:06.72

>>679
上の人が書いてるように、ただの場合分けだと思う。ただ、>>682の人も書いてますが、本当に網羅しているか、を考えると理論が出てくる気がする。

定義域の型が、型コンストラクタで定義されてれば、そいつら全てについて場合分けする、
で、そいつらも型コンストラクタが入ってれば、、てのを続けていけば、全てについて網羅的な場合分けが出来る。

言葉だとわかりにくいですが、Agdaの動画を見るといいと思います。

定理を証明するのに、上の場合分けを考慮する必要があって（漏れたら困りますよね？）、
実際EmacsのAgdaモードだとそういうのを勝手に展開してくれるコマンドがあり、
ゲーム感覚で証明してく感じ。

で、カリーハワード対応を考えると、関数の定義も結局は同じで、実際同じコマンドを使って進めてくことになる。その流れでやれば、後で漏れてる云々は問題にならない。

こんな感じですかね？

**デフォルトの名無しさん** · 2018/01/20(土) 22:20:04.44

>>682
動的言語はデータクラスをほとんど使わず、辞書や配列を生で扱うことが多いからじゃないかな
型で分岐するケースがそもそも少ないし、when Some a みたいにパターンマッチと同時に要素を抽出したくても抽出の仕方が定義されていない

**デフォルトの名無しさん** · 2018/01/20(土) 23:10:12.11

>>678
俺は最近書いてないぞ。
つまらんからな。

**デフォルトの名無しさん** · 2018/01/21(日) 00:17:54.03

パターンマッチで変数にバインドするところとかあれってどう還元できんですかね？

**デフォルトの名無しさん** · 2018/01/21(日) 01:01:46.61

・頭文字が大文字ならコンストラクタ (引数0個以上)
・そうでなければ変数 (引数なし)
少なくともこの仕様を守れば動的言語でもパターンマッチできるよ

**デフォルトの名無しさん** · 2018/01/21(日) 01:02:49.35

難しく考える必要はない
タプルは関連する複数の値をまとめて扱ってるだけ
レコードはタプルに型名というラベル値が付いただけ
型によるパターンマッチはその型名で条件分岐してるだけ
変数へのバインドはタプルの特定の要素の値にに別名を付けただけ

**デフォルトの名無しさん** · 2018/01/21(日) 01:37:10.13

つまり・・・どういうことだってばよ？

**デフォルトの名無しさん** · 2018/01/21(日) 06:13:50.88

>>682
動的言語どうこうではなく、オブジェクト指向の情報隠蔽とパターンマッチの相性が悪い。
アクセス制御をかいくぐってデータ構造にマッチさせるぐらいなら
オブジェクトを受け取ってからメソッド叩いたり条件分岐したほうがマシ。

**デフォルトの名無しさん** · 2018/01/21(日) 10:42:33.20

>>690
SuccessとFailをパターンマイッチングするんじゃなくて
class Success implements Resultと
class Fail implements Resultみたいにしろ
ってこと？

**デフォルトの名無しさん** · 2018/01/21(日) 11:06:54.37

本物のオブジェクト指向はTrueクラスとFalseクラスを使う
Bool &True::ifTrue(Block f) {f(); return this;}
Bool &True::ifFalse(Block f) {return this;}
Bool &False::ifTrue(Block f) {return this;}
Bool &False::ifFalse(Block f) {f(); return this;}

**デフォルトの名無しさん** · 2018/01/21(日) 11:22:08.22

こういうときオブジェクト指向ってアホの自慰っぽいなと思う

**デフォルトの名無しさん** · 2018/01/21(日) 12:05:31.75

全てのif文を消し去るのです

**デフォルトの名無しさん** · 2018/01/21(日) 13:37:58.84

その次の世代はtemplateを使いvirtualを消し去る
だからifが復活

**デフォルトの名無しさん** · 2018/01/21(日) 14:30:35.35

>>695
はいサイクリングマチカル複雑度増加

**デフォルトの名無しさん** · 2018/01/21(日) 23:54:04.18

多次元配列と第一級関数をサポートしている静的言語ってなんかあったっけ？

**デフォルトの名無しさん** · 2018/01/22(月) 00:18:19.80

**デフォルトの名無しさん** · 2018/01/22(月) 00:18:46.23

サポートするの定義が曖昧すぎる。

**デフォルトの名無しさん** · 2018/01/22(月) 00:28:37.30

そうかC#があったか。ありがとナス��

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

>>697
それサポートしてない言語って何があるの？

**デフォルトの名無しさん** · 2018/01/24(水) 10:06:55.58

>>701
多次元配列サポートしてる言語なんて他にはFortran, R, Python, Julia, Racketくらいしか思いつかない
第一級関数は最近増えて来てるけどFortranみたいな古い言語はだいたいサポートしてない

**デフォルトの名無しさん** · 2018/01/24(水) 10:13:41.67

>>702
多次元配列サポートすると何の役に立つの？

**デフォルトの名無しさん** · 2018/01/24(水) 10:30:59.45

>>703
行列計算とか、その他数値的な解析がめちゃくちゃ書きやすくなる。
いわゆる数値解析や流行りの機械学習からゲーム開発まで、くまなくアルゴリズムが書きやすくなるぜ

**デフォルトの名無しさん** · 2018/01/24(水) 10:44:28.83

サポートてのは、数値計算でよく使う引数が2の関数と、そういう関数とと中置演算子との間の糖衣構文が標準でオーバーロード気味に存在するってことですかね？

**702** · 2018/01/24(水) 10:59:06.24

>>704
Racket挙げてるし中置演算子は重要度低いけど、よく使う関数はチューニングされたものを置いておいて欲しいな

Numpyだって標準ライブラリじゃないし、最悪標準ライブラリじゃなくてもいいけど、「数値計算するなら常識的に考えてこれ」という一つに定まっていてほしいな。
あるライブラリはEigenに依存しているが他のあるライブラリはublasに依存してるみたいなのはやめて欲しい

**702** · 2018/01/24(水) 10:59:37.34

間違えた。
安価は>>705で

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

>>702
良かった。言語として普通にあるもんだと思ってたから
無いことを想像したこともなかった。

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

第一級関数のことかな？
多次元配列はレアだよ

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

Pythonは多次元インデックスをオーバーロードできるけど組み込みの多次元配列は無い
PythonレベルのサポートでいいならKotlinも同等だね

**デフォルトの名無しさん** · 2018/01/24(水) 11:58:57.43

そういえばExcel方眼紙もある意味二次元をサポートしてるな
Excelの異常な人気の原因はそこか

**デフォルトの名無しさん** · 2018/01/24(水) 19:16:29.18

義務教育に向けて親もプログラミングやっときたい、どれが良い？
Pythonとかよく目にするけど、と聞かれた。

どう答える？

**デフォルトの名無しさん** · 2018/01/24(水) 19:30:37.89

相手が挙げて来た言語のメリットを適当に言ってそのまま勧めれば良い
親が教えるためにやる言語なんて何でも良いし、違いがわかる頃には子供は卒業してる
選ぶのも面倒くさい

**デフォルトの名無しさん** · 2018/01/24(水) 19:50:08.15

>>712
まずはExcelのVLOOKUPを使いこなせるようになれ
次はVBAをやれ
でいいよ
教える側が何の役に立つのか分からないまま人に教えるなんて全く何の意味もない

**デフォルトの名無しさん** · 2018/01/24(水) 20:27:01.77

>>712
教育ママに特定の言語やらせて認識を固定させんな、むしろ子供に害悪だろ
数学パズルでもやらせとけ

**デフォルトの名無しさん** · 2018/01/24(水) 20:29:15.40

子供にはScratchをやらせることになるらしいから、親もScratchをやればいいじゃん

◆QZaw55cn4c · 2018/01/24(水) 20:39:13.05

>>712
やはり再帰的思考が勘所かと考えていますので、scheme をお勧めしようかと思っています

**デフォルトの名無しさん** · 2018/01/25(木) 01:24:29.68

>>712
Haskel
関数型を理解できないバカはプログラミングする資格も意味もなし
保守困難なウンコをひり出すだけのゴミは消えろ

と伝えてくれ

**デフォルトの名無しさん** · 2018/01/25(木) 02:32:13.16

>>718
Haskellの綴りも正しく書けない池沼は文章を書く資格も意味もなし
無意味なウンコをひり出すだけのゴミは消えろ

**デフォルトの名無しさん** · 2018/01/25(木) 12:45:10.82

>>711
excelは関数型言語だ、と言う人々も居るくらいだからな(笑)

**デフォルトの名無しさん** · 2018/01/25(木) 14:09:07.50

Excelはビジュアルリアクティブプログラミング環境と言えばまあ間違ってはないんだけど
二次元配列以外の構造の扱いが難しすぎて、学習用にしてしまうと
他のデータ構造を学ぶ機会がないまま何でも二次元配列に落としこむ悪癖がついてしまいそうで

**デフォルトの名無しさん** · 2018/01/25(木) 14:31:25.81

>>721
人間が無理なく扱えるデータは二次元の表が限界なんだよ
考えてみろ
お前がよく使う構造体やクラスのリストや辞書は実質二次元の表だろ
オブジェクト指向では直接深く階層掘ったアクセスは嫌われるだろ？
なんだかんだ格好いい理屈を付けても、結局人間にはExcelのデータ構造が馴染むんだよ

**デフォルトの名無しさん** · 2018/01/25(木) 14:38:39.64

>>722
再帰的 or 多相な構造どうすんのよ、ってのはまあExcelの用途では滅多にないとしても
単純に三次元配列が欲しい時もあるし
Sheet増やしだすと急に面倒くさくなるんだよなあ

**デフォルトの名無しさん** · 2018/01/25(木) 14:41:15.02

>>723
再帰なんか同じ表の行番号を持たせるだけだろ

**デフォルトの名無しさん** · 2018/01/25(木) 17:16:48.70

３次元以上を汎用に使おうとするとSQLみたいだったり tensor flow だったり
かなりめんどくさいインターフェイスになるのはしゃーない。

**デフォルトの名無しさん** · 2018/01/25(木) 17:55:47.33

まぁ、Haskellで作られたものより、Excelで作られたモノのほうが多いしな(笑)
純関数型(笑)

**デフォルトの名無しさん** · 2018/01/25(木) 20:01:29.48

>>719
このようなtypoを防ぐためにも強い型付けが必要なんだよ