次世代言語15 Go Rust Swift Kotlin TypeScript

**デフォルトの名無しさん** · 2018/11/04(日) 20:30:10.42

スレタイ以外の言語もok

前スレ
次世代言語14 Elixir Crystal Julia Rust Swift
https://itest.5ch.net/mevius/test/read.cgi/tech/1536668904

**デフォルトの名無しさん** · 2019/03/27(水) 17:04:40.79

>>602
先にジェネリクスがあったらオーバーロードは不採用だったと思う

**デフォルトの名無しさん** · 2019/03/27(水) 17:15:00.98

>>627
あと一回見かけたらはてブロに通報するわ

**デフォルトの名無しさん** · 2019/03/27(水) 17:15:08.52

ジェネリックで必ず同じ操作になるならいいけど
そうでもないときはジェネリックではどうにもできない

**デフォルトの名無しさん** · 2019/03/27(水) 17:18:22.78

オーバーロード否定派は動的型付け言語か形無し言語がメインの人なんだろうか？

**デフォルトの名無しさん** · 2019/03/27(水) 18:22:56.09

Cはユーザーが定義できない演算子だけオーバーロードする
ユーザーが定義してない型の情報だけコンパイル後に残る

このユーザー定義型の不当な制限をなくすというC++の理念のおかげで
オーバーロードや実行時型情報ができた
めでたしめでたし

**デフォルトの名無しさん** · 2019/03/27(水) 19:26:19.13

ほとんどの言語が強制キャストできるのが原因で型安全でなくなっているのが
何とかならない

**デフォルトの名無しさん** · 2019/03/27(水) 19:52:11.21

>>631
静的型付けメインにも普通に居るよ
RustやGoも関数オーバーロードを導入しなかったし

作為的な例にはなるけどむしろ型システムの阻害要因になることもある
https://ideone.com/uJ1lyb
https://ideone.com/P96nVa

**デフォルトの名無しさん** · 2019/03/27(水) 19:59:52.56

後者の例で言うと、ライブラリの関数に気を利かせてオーバーロードを追加したところ
別のプロジェクトの既存コードがコンパイル出来なくなったとかもあり得る

**デフォルトの名無しさん** · 2019/03/27(水) 20:08:46.35

やはりリーナスは正しかった！
c最高！
c++はうんこ！

**デフォルトの名無しさん** · 2019/03/27(水) 20:12:19.93

暗黙の型変換を含めた場合のオーバーロードの地獄感は半端ない。

**デフォルトの名無しさん** · 2019/03/27(水) 21:04:39.85

それにテンプレートとADLが絡んでカオス

**デフォルトの名無しさん** · 2019/03/30(土) 03:45:54.68

クロスキャストはカスだから滅びろ
インターフェースの実装を鞍替えしたいんだったらFactoryとか使えや

**デフォルトの名無しさん** · 2019/03/30(土) 10:52:42.58

型名を隠蔽すればキャストできないので
無名クラスとラムダの世界ランクが右肩上がり

**デフォルトの名無しさん** · 2019/03/30(土) 13:35:24.87

本当に欲しいのは型ではなく制約

**デフォルトの名無しさん** · 2019/03/30(土) 19:28:46.42

ガイジみたいなコード書くガイジを殺していい法律を作ることだな
皆殺しにしてやるよ

**デフォルトの名無しさん** · 2019/03/31(日) 08:00:06.83

次世代かは知らんけど、Haskell奥が深い。
プログラマーのための圏論っていうのをネットから落として読んでるが、
圏論的には変数や値そのものも関数足り得るとか、読んでて面白い(理解してるかは怪しいが)

int n = 1とint n(){ return 1 }が同じと言うのは言い得て妙だなと。
Haskellで関数にカッコ使わないのはこれを体現する為なんだなと。

n = 1 ― Haskell的には変数でもあり、引数無しの関数。

関数も値でもあるんだから

sum = foldl (+) 0は、sum xs = foldl (+) 0 xsの部分適用で変数を(見かけ上)減らした関数であると同時に、
部分適用した関数に束縛した変数でもある。。。と。

と言うことはHaskellのmain関数も、関数であり変数なんだなーと。
関数を呼んでプログラムが走り出すとも言えるし、変数を評価しようとして、結果として束縛されたプログラムが走り出すとも言える。

main = putStrLn "hello" ― main関数を呼ばれたとも言えるし、変数mainを評価して値(IO ())を得る過程でプログラムが走り出すとも言える。

**デフォルトの名無しさん** · 2019/03/31(日) 10:38:58.10

概念は有用だし言語の進化に多大な影響を与えたけど
道具としてのHaskellは今の位置から上がってくることは無いだろうな

**デフォルトの名無しさん** · 2019/03/31(日) 10:43:21.70

>>644 確かにその通り。実用的な言語は、わかりやすくバグが出にくいことが重要。
他人のコードでも誰が見ても一目でわかるみたいな。

**デフォルトの名無しさん** · 2019/03/31(日) 11:07:42.57

実用なら副作用認めた方が絶対的に有利なわけでそういうのはOCamlなりF#が担えばいいよ
Haskellが勉強のための言語なのはこの先もかわらない

**デフォルトの名無しさん** · 2019/03/31(日) 13:08:06.82

xmonadとかあるし、実用的でないとは言い切れないが、いかんせん学習コストが高くてマンパワーに頼れんからな

**デフォルトの名無しさん** · 2019/03/31(日) 18:14:52.08

Haskellの再発明のようなアイデアを思いつくやつは必ず出てくるよ
これHaskellでやったやつだって教えてあげないと再発明を止められない
高い学習コストをもう一回課金される

**デフォルトの名無しさん** · 2019/03/31(日) 19:22:10.57

Haskellは数学的な背景があるから一部だけパクってもうまくいかんでしょ

**デフォルトの名無しさん** · 2019/03/31(日) 20:26:01.36

一部だけ学ぶのはダメってのは見覚えがある
Perlでやったやつだ
一部だけでいいと作者が言ってるのに全部やろうとして挫折するやつだ

**デフォルトの名無しさん** · 2019/03/31(日) 20:40:52.20

https://speakerdeck.com/uzulla/gui-tutekita-ping-cheng-zui-hou-falseoreorehuremuwakufalsezuo-rifang

なんでペチパーって自作FW作りたがるん？
もうしばらく関わってないけど、糞SIerいたとき糞案件が軒並み自社製PHP FW（糞）だったの思い出したわ

**デフォルトの名無しさん** · 2019/03/31(日) 21:26:26.85

量産型Webは技術が完全に硬直化してるから、ちょっと意識高い奴がマウント取りたくても差別化できるネタが少ないんだよ
で既存の開発プロセスのオーバーエンジニアリングに向かうわけだけど、
ペチパーレベルではインフラや言語を改善したりそもそも開発作業自体を減らすって方向には行きにくい
そこで手頃なのがFWというわけ

**デフォルトの名無しさん** · 2019/03/31(日) 21:52:14.80

もともとFWっていうのは汚いコードを寄せ集めてライブラリ化した上で
汚いコードの寄せ集めを使う処理を手順化して綺麗に見せるための仕組みだったんだけどな

**デフォルトの名無しさん** · 2019/03/31(日) 21:59:57.35

diコンテナは何のメリットがあるのか不明

**デフォルトの名無しさん** · 2019/03/31(日) 22:31:08.06

>>654
は？

**デフォルトの名無しさん** · 2019/03/31(日) 22:37:11.66

依存性注入はクラスが増えてカオスになる
何故かjavaではよく使われるのが謎

**デフォルトの名無しさん** · 2019/03/31(日) 22:49:56.27

オブジェクト指向だとクラスは大量に作るもんだぞ

**デフォルトの名無しさん** · 2019/03/31(日) 22:58:47.59

それLaravel使えば問題ない話じゃね？

**デフォルトの名無しさん** · 2019/03/31(日) 22:59:24.74

アンカ抜けてた>>651

**デフォルトの名無しさん** · 2019/03/31(日) 23:08:51.93

カオスだと感じる脳程度だけしか持ち得てないんだろう
察してやれよ

**デフォルトの名無しさん** · 2019/03/31(日) 23:49:26.60

FXの自動売買ツールを無料で配布しています。
http://hbgvf.blog.jp

**デフォルトの名無しさん** · 2019/04/01(月) 00:33:10.08

人類最底辺の脳みそしか持ち合わせてない永遠の土方ペチプァの話題なんか出すな
スレが穢れる

**デフォルトの名無しさん** · 2019/04/01(月) 01:55:20.15

>>640
ついでにSAMも滅びろ
あいつ使いにくくてかなわん

**デフォルトの名無しさん** · 2019/04/01(月) 02:44:37.39

>>646 だれが勉強すんねん
一目見た時から、恋の花が咲いた
のでは無く、こりゃダメだと思った。

**デフォルトの名無しさん** · 2019/04/01(月) 02:48:36.94

逆に Python はなんとなく幼い頃の悪ガキ仲間と似てるなと思ってたら、立派に成長して懐の深い大人になってた。
ちょっと見の見た目で判断してはいけない。

**デフォルトの名無しさん** · 2019/04/01(月) 07:12:14.06

単純に機械学習ライブラリの虎の威借りてるだけだろ
言語としてはPHP並の糞だわ
venv周りも糞糞アンド糞だしな

**デフォルトの名無しさん** · 2019/04/01(月) 20:13:46.91

そのへん、他の軽量級言語は何故うまくやれなかったのかな。

**デフォルトの名無しさん** · 2019/04/01(月) 20:23:06.27

情報系専門でない連中が多い分野だから、言語オナニーには興味ないんだよ
Pythonは昔から数値計算系のライブラリが充実してたし学習コストも低い

**デフォルトの名無しさん** · 2019/04/01(月) 21:00:27.10

venvなぁ。
中にpython.exeがそのまんま入ってたのを見たときはコントかと思ったｗ

**デフォルトの名無しさん** · 2019/04/01(月) 21:18:09.61

数学の関数やOSのシステムコールを
いちいちオブジェクト指向に翻訳しないといけない文化は仕様が不安定になる

不安定な自作オブジェクトを集めたものが自作FWになる

**デフォルトの名無しさん** · 2019/04/01(月) 21:52:46.65

pyenvとかあの辺弄るくらいならdockerで閉じ込めた方がマシ。

**デフォルトの名無しさん** · 2019/04/02(火) 09:42:15.53

>>670
翻訳しないで済むOS作れば良いのでは？

**デフォルトの名無しさん** · 2019/04/02(火) 20:30:27.35

WinRTがそれかな

**デフォルトの名無しさん** · 2019/04/03(水) 11:55:08.65

>>671
venvに比べたら、docker重いよ。

**デフォルトの名無しさん** · 2019/04/03(水) 12:10:05.50

>>668
その言語オナシストたちが挙ってPython推してるからお前も鼻が高いだろう
良かったな

**デフォルトの名無しさん** · 2019/04/03(水) 13:11:27.32

dockerがどっかー行っちゃったー

すまん。一度言ってみたかったんだ。ゆるせ。

**デフォルトの名無しさん** · 2019/04/03(水) 13:47:18.98

実際には一人で気持ち良くなるのではなく
staticおじさんを責める自分に酔ってるみたいなパターンが多い
一人じゃないから正常なんて思ったら大間違い

**デフォルトの名無しさん** · 2019/04/03(水) 13:50:02.32

パンツじゃないから恥ずかしくないなんて思ったら大間違い

**デフォルトの名無しさん** · 2019/04/03(水) 21:33:59.24

staticおじさんてなに？

**デフォルトの名無しさん** · 2019/04/04(木) 02:32:05.58

>>679
高卒や専門卒のプログラマーのことだよ
そういうのにはstaticが好きが多いからそう呼ばれてる

**デフォルトの名無しさん** · 2019/04/04(木) 05:09:05.51

>>679
つhttps://el.jibun.atmarkit.co.jp/minagawa/2010/04/post-ebc4.html

**デフォルトの名無しさん** · 2019/04/04(木) 05:48:32.02

特殊用途以外でstatic変数を使うのはアホだけど
staticメソッドもまとめてstaticおじさんとか書いてる記事は
関数型にもついてけないただの周回遅れ

**デフォルトの名無しさん** · 2019/04/04(木) 07:07:10.33

うちのおじさんはdbのクライアントをstaticにするんだよね

**デフォルトの名無しさん** · 2019/04/04(木) 08:14:30.23

シングルトンおじさんの呼び方のが正しい問題意識な感じがする。

**デフォルトの名無しさん** · 2019/04/04(木) 08:44:10.37

ここのstaticおじさんの話題で関数型を持ち出してる人間たまに居る（多分同一人物）けどimmutableに一切言及してないのはなんなんだ
関数型は言語機能で束縛をimmutableにして、それでもなお必要な時にmutableを扱うのであって、staticおじさんのpublic staticなんて言語も踏まえてmutableの可能性の方が高いでしょ

**デフォルトの名無しさん** · 2019/04/04(木) 09:23:20.89

Kotlin もよろしく

**デフォルトの名無しさん** · 2019/04/04(木) 09:29:42.90

コトリンなんてシングルトンおじさん量産言語じゃん

**デフォルトの名無しさん** · 2019/04/04(木) 09:30:46.16

static禁止の次の世代はimmutableではなく依存性注入だからね
class名をハードコードするだけでアウト
interfaceはセーフ
もちろんSingletonはアウト

**デフォルトの名無しさん** · 2019/04/04(木) 09:33:41.65

Love≒依存性

**デフォルトの名無しさん** · 2019/04/04(木) 10:37:11.62

>>687
え？そうなるか？

**デフォルトの名無しさん** · 2019/04/04(木) 10:59:33.23

class名.static変数
class名.static関数
超便利じゃん

**デフォルトの名無しさん** · 2019/04/04(木) 11:25:51.28

class名がそのままファイル名になるじゃん
定義を変えてみたくなったらファイルを上書きするしかないじゃん
そういうとこだよ

**デフォルトの名無しさん** · 2019/04/04(木) 11:31:19.04

>>685
この話題何度も出てるのか
staticおじさん云々に言及したのは初だわ
というか>>682はググって読んだ記事に対する感想な

staticメソッド：
　副作用無し → OK
　引数への副作用有り → 許容内
　標準出力などプロセスに１つのリソースへの副作用 → 許容内
　内部でstatic変数への副作用有り→ デバッグ等の特殊用途を除いてはゴミ

privateでないstaic変数
　→ 論外のゴミ

これらをただstaticというだけで
その先にある局所性や副作用への悪影響を区分せず
ひとまとめに扱う雑な記事は、何かをdisるレベルに無いという考え

**デフォルトの名無しさん** · 2019/04/04(木) 12:40:50.62

>>691
なんかIDEに怒られてstatic関数にできないときは
シングルトンのgetInstance作って
class名.getInstance.メンバ関数
で回避

**デフォルトの名無しさん** · 2019/04/04(木) 14:01:55.30

>>693
私が勢いでレスしてしまったようだすまない
確かにstaticメソッドのみでみれば関数型的な副作用の切り分けとして見れるね

ただ
>>681 リンク先
> 共有変数も、pubulic static宣言していまう。したがってプロパティなんて作らない。
というアレがあるので『staticおじさん』とした時に関数型を持ち出すのは不適であると勢いづいてしまった

**デフォルトの名無しさん** · 2019/04/04(木) 21:07:18.41

staticメソッド：
　副作用無し

↑これにめちゃくちゃ違和感がある
特定の言語は宋なのかもしれないけど…

**デフォルトの名無しさん** · 2019/04/04(木) 21:24:47.26

同じ機能を持った別個体のオブジェクト変数を持ちたい時にフィールドをstaticにしてたら何も出来ないけどね

**デフォルトの名無しさん** · 2019/04/04(木) 22:06:34.27

>>696
どういう違和感か分からないが一応補足しておくと
staticメソッドのうち、副作用無しの場合という意味な

副作用が無いメソッドというのは
引数以外に影響されず、戻り値以外に影響を与えないもの
具体例としては java.lang.Math.max

**デフォルトの名無しさん** · 2019/04/04(木) 22:39:36.52

>>698
引数以外に影響されないことは副作用のないことの必要条件ではない
参照透過とごっちゃになってるぞ

**デフォルトの名無しさん** · 2019/04/04(木) 23:09:47.59

副作用の定義によっては
参照透過と同義になってしまうかも？

**デフォルトの名無しさん** · 2019/04/04(木) 23:20:58.18

定義によってはって、「副作用」の意味を変えちゃうってこと？

**デフォルトの名無しさん** · 2019/04/04(木) 23:34:18.16

>>699
すまんその通り
オブジェクト指向に絡む話なのもあって
関数型に寄りすぎる単語を微妙に避けようとして変なこと言った

**デフォルトの名無しさん** · 2019/04/05(金) 20:17:32.71

副作用とは関数使ったら値を返すだけじゃなくて他のとこに影響出てしまうやつ

わかりやすい例で言えばファイル操作（write,read）関数とか画面に文字を出す関数(print)が
副作用があるとされている

**デフォルトの名無しさん** · 2019/04/05(金) 22:40:10.47

先生! ユーザー入力や乱数は副作用に入りますか?

**デフォルトの名無しさん** · 2019/04/05(金) 23:31:16.26

入ります。

**デフォルトの名無しさん** · 2019/04/05(金) 23:36:46.00

そう言う意味じゃHaskellはHaskell信者？は副作用は無いと言い張るが、確実に有る。
私がHaskellに注目してるのは副作用があっても参照透明性が保たれている。この一点だ。

**デフォルトの名無しさん** · 2019/04/05(金) 23:56:50.87

ブログやニュース記事ならhaskellだろうけど
ソフトウェアを書けといわれたらocamlで書くわ

**デフォルトの名無しさん** · 2019/04/06(土) 00:31:00.91

副作用があるのかないのかを型で宣言すればいいんだよ
副作用は無いと言い張るより、型は嘘をつかないと言い張る方が面白くなる

**デフォルトの名無しさん** · 2019/04/06(土) 00:31:05.44

>>706
Haskellの世界ではないんだよ
まあトリックではあるんだが
でもそこを理解しないとmonadの意義もわからない

**デフォルトの名無しさん** · 2019/04/06(土) 01:24:43.24

モナドは外見上は引数がないけど値を返す
逆に引数はあるけど値を返さないとか、引数もない値も返さないとかの方が
副作用に関してはわかりやすいのだけどモナドの意義は副作用だけではないので

**デフォルトの名無しさん** · 2019/04/06(土) 01:40:05.33

モナドとかクソしょうもない型合わせごっこの遊び道具でしかない。

**デフォルトの名無しさん** · 2019/04/06(土) 01:43:50.36

関数型コミュニティのモナドをディスっちゃいけない空気嫌い
技巧に溺れて本来の関数型のメリットである見通しの良さや宣言性を完全に見失ってる

**デフォルトの名無しさん** · 2019/04/06(土) 01:44:02.26

トレートとインターフェースの違いは何なんだ？rust難しすぎ

**デフォルトの名無しさん** · 2019/04/06(土) 02:56:29.83

JavaとかＣ＃のインターフェイスと似たようなもんだけど、後付じゃないジェネリクスと階層構造の無い型のおかげでむしろ使いやすい
OOPのインターフェイスの方がルール覚えづらいと思う。<? extends T>と<? super T>とかinとかoutとかもう覚えてないわ

**デフォルトの名無しさん** · 2019/04/06(土) 08:23:20.81

>>709
そのトリックに拘って純粋関数型言語と言う言葉に拘ってたら、
そこから話が進まなくなる場面を何度も見てきたから。
純粋じゃない言語から見れば「それもう副作用じゃん」「ただの方便じゃん」と。

だから私はHaskell使って何が嬉しいか聞かれたら、
参照透明性を保つことを徹底する所と答える。

**デフォルトの名無しさん** · 2019/04/06(土) 08:33:11.58

rustはc++に比べると一見学習コストは低いようにも見えるが
色々な機能の意義を理解するには結局c++やることになるという意味でc++以上に学習コストがかかる。

**デフォルトの名無しさん** · 2019/04/06(土) 08:37:35.86

>>710
？
モナドは常に引数あるよ。
doでしか使った事ないのかな。。。

main = do
print (1 + 1)
print (2 + 2)

は

main = print (1 + 1) >> print (2 + 2)

のdo表記だし、(>>)は

main = print (1 + 1) >>= \_ -> print (2 + 2)

の(>>= \_ ->)部分の略記。(print (1 + 1)の戻り値IO()からIOを外した()がラムダ式の引数に入るが使わない)

**デフォルトの名無しさん** · 2019/04/06(土) 08:37:59.39

>>711 >>712
でもSwift, Java, JavaScriptとかの関数型がメインじゃない言語にも
実質モナド操作であるflatMapが入ったじゃん

**デフォルトの名無しさん** · 2019/04/06(土) 08:43:32.56

>>712
そうなん？
Haskell信者は兎も角、OCamlとかLisp系とか他の言語の人もそんな空気なん？
まあモナドをディスる理由も無い気はするが。
見通しの良さや宣言性も見失ってると思わないので、参考までに聞きたい。

**デフォルトの名無しさん** · 2019/04/06(土) 08:48:46.26

そんなクソみたいなものでIOの実行を表現するくらいなら実行タスクのチェーンを作ってますって
意味をもっと明示的に取り扱った方がマシだわ。

**デフォルトの名無しさん** · 2019/04/06(土) 08:56:14.69

>>717
printはモナドを返す関数だ
printの引数は関数の引数であってモナドの引数ではない
だからprintに引数を渡しただけでは副作用が発生しない

**デフォルトの名無しさん** · 2019/04/06(土) 09:10:31.05

>>721
モナドと言ったら>>=とかの演算子の方だと思ったんだが、IOな関数(アクション)の方なの？
それなら、getLineみたいなアクションは圏論的にはある種の変数扱い。

n = 1 ― 圏論では変数であり、引数無しの関数

値も、Haskellでは出来ないが強いて書いてみると

1 = 1 ― 1という名前の変数(値は1)、もしくは1という名前の1を返す引数無しの関数

そう考えると

getLine ― 外部からの入力(IOな値)が入った変数、もしくは(ry

>>711 の言う通り、型がIOなだけで、何も特別な関数というわけじゃ無い。
少なくともHaskellから見た扱いは純粋な関数と変わらない。
(それにも関わらず、main表層にアクションが自然と集まるというだけ)

**デフォルトの名無しさん** · 2019/04/06(土) 09:13:29.66

以下は個別に分けられる話

(1) 純粋関数型ではそれ自体の制限からIOにモナドなどを必要とする
(2) Haskellでは実行タスクのセマンティクスを明示しやすくするためdo構文がある
(3) モナドの有用性はIOの表現用に限らない (他言語にも関連する)

>>720
それは(2)を考慮してもなお(1)に納得してないということ？
より良い方法があるんだろうか？

それ以前の、純粋関数型は要らないということかもしれないけど

**デフォルトの名無しさん** · 2019/04/06(土) 09:17:48.36

>>722
その文脈のモナドは、それらを持つ型あるいは値では

**デフォルトの名無しさん** · 2019/04/06(土) 09:55:46.82

これだから関数型の連中はいやなんだよ

**デフォルトの名無しさん** · 2019/04/06(土) 10:04:05.89

Rust「静的型はいいぞ」
Haskell「静的型はいいぞ」
迷探偵「これだから関数型は」

**デフォルトの名無しさん** · 2019/04/06(土) 12:47:15.25

Innullableな世界で仕事がしたい