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

**デフォルトの名無しさん** · 2017/06/13(火) 08:54:07.99

いざ、語ろうぞ。

スレタイ超過のため、一部省略。
その他もウェルカム。

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

**デフォルトの名無しさん** · 2017/07/06(木) 20:13:21.99

>>297
>>299
副作用が多くてMaybeモナドだらけになるって設計が悪いだけじゃない？
それって普通のプログラミング言語で書いても副作用だらけのプログラム書くってことでしょ？
どんなプログラミング言語でも副作用はなるべく少ない箇所に押し込むでしょ

**デフォルトの名無しさん** · 2017/07/06(木) 20:29:36.80

Haskellは副作用禁止の言語だと思ってる奴多いんか？
副作用と純粋関数に分けて書くってだけだぞ

**デフォルトの名無しさん** · 2017/07/06(木) 20:35:22.98

>>301
Haskellは極論バカだから特にそこが問題になるんでしょ
オブジェクト指向では少々副作用があろうが汚かろうがクラスに閉じ込めて外からは「問題にならない」ようにすることができる
mfput(笑)みたいな小さな問題と違って、現実世界の問題を相手にすると常に最初から完璧な設計をするなんて不可能だしね

**デフォルトの名無しさん** · 2017/07/06(木) 20:39:55.53

>>302
そんな勘違いをしてる奴は誰もいないと思うぞ
副作用の混入に対してセンシティブすぎるという話

**デフォルトの名無しさん** · 2017/07/06(木) 22:50:47.39

そもそもプログラム自体が副作用そのものだし

**デフォルトの名無しさん** · 2017/07/06(木) 23:11:16.25

Javascriptのこのクイックソートは副作用なし

// QuickSort
QS=X=>X.length<=1?X:[
...QS(X.filter((x,i)=>i>0&&x<X[0])),X[0],
...QS(X.filter((x,i)=>i>0&&x>=X[0]))];

//main
var x=1, X=[...Array(20)].map(()=>x=(7+37*x)%100);
console.log("in: "+X + "\nout: "+QS(X));

http://ideone.com/wnQXXE

**デフォルトの名無しさん** · 2017/07/07(金) 06:18:59.39

>>290
ハードウェア記述言語向きってのは使った事ないけど、分かる気がする。

おいらもHaskellでGUIから何から書き下すのは出来なくはないけどそれOOPで良いよねって思ってて、
でもある意味CUIよりGUIの方がメッセージやイベントに答えるコード書けば良いだけなんだから、
むしろGUIをHTMLやXAMLで記述するようになった今だからこそHaskellは環境さえ整えばGUIも向いてると思うんだよね。
その環境が絶望的に揃ってないだけで。

なんつーかな。
あんたと思ってんのは基本同じだな。
全部Haskellで書こうとするから無理が出る。
上手に副作用部分を外部ツールなり、他の言語に任せて連携させればこれ程シンプルかつ堅牢に作れる言語もなかろうって思う。

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

つまりhaskellではなくOOPと関数とマルチパラダイムが答えということか
あ、Scalaやね

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

今だとGoogleのお墨付きを貰ったKotlinだろう
mfput君のレベルだと全く不足ないことは上で実証済みだし

**デフォルトの名無しさん** · 2017/07/07(金) 10:33:52.64

Kotlinよさげ
型クラスもしくは高階型って使える？

**デフォルトの名無しさん** · 2017/07/07(金) 10:37:23.83

>>308
HTMLやXAMLでGUI部分書くようになった今、OOPの役割は終わったのに醜く延命してるって話。
でもコード資産があるから、ベストじゃ無いって分かっててもそうなるんだろうな。

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

>>311
GUIの中で副作用のないところをhtmlに切り出せたなら
あとは副作用をどう上手く書くかだろ？
だったらHaskellみたいな純粋関数型は益々いらんって事にならんか？

**デフォルトの名無しさん** · 2017/07/07(金) 12:31:39.94

GUIで書きたいのはただの副作用ではなく非同期な副作用
非同期とXMLを流行らせたJSの手柄をOOPの手柄にするのはアクロバティック過ぎる

**デフォルトの名無しさん** · 2017/07/07(金) 12:34:56.69

え、逆だろ？
HTMLやXAMLは副作用の排出口。
だからそれらに書き込むような表層部分に副作用部分を集める。

むしろ今だからこそHaskellがGUIで活きる可能性が出て来た。
例えばエディタ作るとして、CUIだと文字入力監視用のループがある。
GUIだと文字入力されたってイベントに対応すれば良いから、HaskellだとGUIのがエディタ書きやすいと予想してる。
んで、そっからは文字列処理得意なHaskellの独壇場。
普通のアプリなら文字列処理をロジックと読み替えて良い。

まあ実はHaskellだけでGUI書いてもJavaやC#みたいにIDEが整備されてる言語には劣るけど、整備されてない言語とならどっこいどっこいで、特にGUI苦手ってわけでも無いんだけども。
Haskellっぽくなくていやんな見た目なだけで。

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

>>311
うん、意味不明
独自のwidgetを作るのにOOPは必要

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

>>314
そこまで構想(妄想?)ができたならもうそろそろいいだろ
続きはgithubで語れ
mfput(笑)みたいなサンプルじゃなく、ちゃんと実用性のあるGUI&DBアプリを作ってくれよ
期待してるぞ

**デフォルトの名無しさん** · 2017/07/07(金) 13:39:25.73

>>314
GUIアプリを画面を入力すると画面を出力するプロセスの集合体と見做すのはCOBOL時代には主流だった発想だよ(今でもWebには色濃く残っている)
自分でやってみりゃわかるけど、確かにスケールはさせやすいんだがくだらん単純作業とコピペを延々繰り返すような開発になるし
大きな手戻りが生じるともう悲惨

**デフォルトの名無しさん** · 2017/07/07(金) 14:05:26.16

うい。
作れたら出してみる。

**デフォルトの名無しさん** · 2017/07/07(金) 21:35:56.42

出すまで帰って来るなよ

あ · 2017/07/07(金) 22:07:41.70

ダム端の画面エンジン面倒見たことあるわ。

文字入力監視のループと、GUIのイベントのdispatchループがどう違うかわからんな。
WinMainとGetMessageとか、XlibのXNextEventからGUIアプリ作ったこと無くて知らないだけじゃねえの？

副作用の出口ではないような。
WM_PAINTの処理中に描画以外やるべきで無いのと同じように、画面周りは出力に徹しないと話がまとまらん。

入力の処理なんか、フォーカス持ってるやつにメッセージ投げるだけだろ。

**デフォルトの名無しさん** · 2017/07/09(日) 05:20:26.84

昨今の話題にのせられてKotlinの入門編読んでみたけど、なんかイマイチだった･･･
関数の引数は型推論してくれんの？カリー化して部分適用とか力ずくでやらんといかんの？パイプライン演算子は･･･
今のところ不安しか感じてない、次世代言語の劣化版でバカチョン言語ってのがKotlinの実像かな？

**デフォルトの名無しさん** · 2017/07/09(日) 07:39:05.73

>>321
関数引数の型推論もカリー化もパイプライン演算子も
全部持ってるHaskellがゴミクソだったから、
それらは言語の生産性にとって特に重要じゃないって事だよ

**デフォルトの名無しさん** · 2017/07/09(日) 09:40:04.24

括弧を省略しないカリー化はゴミクソだし
中置演算子を使わないのと括弧を省略しないのはLispとJavaの伝統じゃないか

**デフォルトの名無しさん** · 2017/07/09(日) 09:45:29.15

なんだかんだカリー化は微妙だと思うなあ
部分適用の文法はClojureとかMathematicaがいい感じ
パイプライン演算子はLL的に使うときは便利やね

**デフォルトの名無しさん** · 2017/07/10(月) 01:34:13.11

>>322
HaskellがクソなのはDynamicBindingが言語的に駄目扱いされてる点だぞ
あとstatic初期化にunsafePerformIOが必要な点もクソ
デフォルトで静的型なカリー化とかあったほうが明らかに使いやすいだろ知ったか野郎

**デフォルトの名無しさん** · 2017/07/10(月) 11:47:13.63

そんなものは言語オタクが喜ぶだけで生産性と何の関係もない

**デフォルトの名無しさん** · 2017/07/10(月) 12:33:52.51

生産性（低産階級労働者にも扱えること）

**デフォルトの名無しさん** · 2017/07/10(月) 17:50:59.58

Rustが実用言語になったぞ
DockerをオラクルがRustで実装した

**デフォルトの名無しさん** · 2017/07/10(月) 20:00:12.08

お、おう・・・

**デフォルトの名無しさん** · 2017/07/10(月) 20:04:51.52

実用言語になったらもう次世代言語じゃないからこのスレとはお別れだな
じゃあな

**デフォルトの名無しさん** · 2017/07/10(月) 21:04:24.59

すげえ論理でﾜﾛﾀ

**デフォルトの名無しさん** · 2017/07/10(月) 21:59:47.07

建物は完成した時点から崩壊が始まるのでわざと未完成の部分を残しておくとかいう話を思い出した。

**デフォルトの名無しさん** · 2017/07/11(火) 11:36:48.66

そもそもオラクルって時点でお察しだが、
業界ゴロのモジカスとOSSゴロのオラクルは相性が良かったんだろうな

**デフォルトの名無しさん** · 2017/07/11(火) 15:49:53.62

>>332
誰がどう見ても未完成なら意見が対立しないからね
完成したら、一部の（自称）察しのいい奴が、まだ完成してないと主張し対立が始まる

**デフォルトの名無しさん** · 2017/07/11(火) 17:23:33.46

>>333
マルポ
http://mevius.2ch.net/test/read.cgi/tech/1495343069/262

**デフォルトの名無しさん** · 2017/07/11(火) 18:53:45.21

[][Tebla][]

}

000-"Yob*RtStrike"[%Kil\]MO,fla>%$9999VLTS

001-GYORLith"0\R"/"ESUBA"%$%

HADO-"EM","L","O","NU"###END

**デフォルトの名無しさん** · 2017/07/12(水) 22:48:51.57

実用言語になってないのが条件なら
Smalltalkも入れてくれよ

**デフォルトの名無しさん** · 2017/07/12(水) 23:51:46.66

Smalltalkは実用されてるだろ

スタートアップ界の異端児！産業機器 x IT x SmalltalkのSORABITO株式会社…人材採用のプロ・高野秀敏氏が厳選「いま最も旬なベンチャー」
https://thepedia.co/article/1068/

**デフォルトの名無しさん** · 2017/07/13(木) 00:48:32.99

一生実用言語にならないような言語は次世代とは呼ばねえだろ池沼かガイジ豆腐で撲殺するぞ

**デフォルトの名無しさん** · 2017/07/13(木) 00:52:26.73

21世紀に生まれた言語限定でええやろ！

**デフォルトの名無しさん** · 2017/07/13(木) 01:37:14.59

オブジェクト指向というだけで最低限の実用性はあるから純粋な世界に引きこもる
関数型は引きこもるとやばいから外に出る

**デフォルトの名無しさん** · 2017/07/13(木) 07:10:16.60

純粋OOPLより純粋FPLの方がいろんな意味で引きこもっとるわ
Smalltalkのシンボルがなんで「気球」なのか、知らんのか？
http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-October/022354.html

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

Smalltalkの引きこもり方は物理的っていうかなんというか
imageの世界に引きこもってるせいで外の世界で新しいツールとか流行ってても使えないし

**デフォルトの名無しさん** · 2017/07/13(木) 07:29:54.34

>>340
20世紀生まれとかバカにしてるけどな
Traitsなんて言語機能は10年とちょっと前
21世紀になってからSmalltalkで考案されたのを
新しい言語がこぞってありがたがって使ってんだぞ

Scalaに至ってはただのMixinをかっこいいからってTraitって名前つけちゃったくらいなんだぞ

**デフォルトの名無しさん** · 2017/07/13(木) 07:40:18.24

>>343
いつの時代のSmalltalkの知識で止まっているんだよ
Pharo作ってる and/or 使っている人たちの話でも聞いて錆び付いたイメージをアップデートしてみたら？

**デフォルトの名無しさん** · 2017/07/13(木) 11:47:59.75

intはオブジェクトにしない方がいい
他にもプロセスidとかファイルディスクリプタとかURI
オブジェクトの本体ではないものが必要
副作用が必要なのと同じ

**デフォルトの名無しさん** · 2017/07/13(木) 13:19:58.91

>>344
バカにしてないけど、次世代言語スレとしては21世紀生まれの子たちに絞ってええやろ
起源がなんであれそれを子どもたちが引き継いでるわけなんやし

**デフォルトの名無しさん** · 2017/07/13(木) 13:28:33.65

haskell(1990)

**デフォルトの名無しさん** · 2017/07/13(木) 13:36:01.36

よっしゃ！haskell離脱おめ！！

**デフォルトの名無しさん** · 2017/07/13(木) 14:12:19.77

>>347
そんなことが言いたいのではない

**デフォルトの名無しさん** · 2017/07/13(木) 15:05:49.91

haskellというゴミが消えてくれるならなんでもいい

**デフォルトの名無しさん** · 2017/07/13(木) 15:14:48.65

そういえばOcamlになったのって案外新しく(1996)てびっくりした
もちろんCamlさらにMLからの流れだけど

**デフォルトの名無しさん** · 2017/07/13(木) 19:08:43.36

昔2chのこの手のスレで、Smalltalkerがgitについて全くトンチンカンなコメントを連発してたので
Smalltalkは錆びついてなくてもSmalltalkerは錆びついてると思う

**デフォルトの名無しさん** · 2017/07/13(木) 19:42:54.12

>>353
なんかあったな
gitなんて業務じゃつかいもんになんねー、svnさいつよみたいなやつな

**デフォルトの名無しさん** · 2017/07/13(木) 19:53:58.91

それ文脈ぜんぜん違う話だしねつ造やめれっていうか錆び付いているのはアンチの脳ミソと記憶力
百歩譲ってそういう話だったとしても最近出没してる「おいら」がHaskellの典型的ユーザーちゃうのと同レベルの話だがや

**デフォルトの名無しさん** · 2017/07/13(木) 20:21:10.35

オブジェクトっぽくないものの語尾にerをつけて無理やりオブジェクトにする現象

**デフォルトの名無しさん** · 2017/07/13(木) 20:57:33.19

>>354
なんかsmalltalkにある独自vcsもどきがsvn程度の機能しかないのか知らんが
発想が完全にsvnだったよな

**デフォルトの名無しさん** · 2017/07/13(木) 21:26:25.99

>>357
そのvcsもどきっていうのは80年代から組み込みの古典的ChaneSetのことか？
Gitと同時期に開発されたMonticelloがsvn程度ってことはさすがにないと思うんだが

**デフォルトの名無しさん** · 2017/07/13(木) 21:44:41.50

Manager

**デフォルトの名無しさん** · 2017/07/13(木) 21:45:38.59

なんだ、やっぱり独自vcsは劣っててダメだから、ちゃんとgitに乗っかろうって動きあるんじゃん
他の言語ならフツーに出来てることに必死だなって感じだけど

https://www.slideshare.net/mobile/newapplesho/pharo-smalltalk-source-code-management-with-pharo

**デフォルトの名無しさん** · 2017/07/14(金) 01:48:02.98

>>344
有り難がるどころか、まともにtraitsなんて採用してるのphpとperlくらいだぞ
smalltalkerだけが凄いと思ってるどうでも良い機能だぞ

**デフォルトの名無しさん** · 2017/07/14(金) 05:30:08.87

>>360
へー、すごいねー。
普通の言語では、その言語で作ったアプリケーションの実行中にgitの複数のレポジトリから自己更新してきたり、実行時に構成を動的に変更したりが、とっくの昔からフツーにできているんだー？
さすが普通の言語ってすごいね。そこにシビレルね。

**デフォルトの名無しさん** · 2017/07/14(金) 06:42:12.81

そういうことをやりたいならJavaScriptに乗っかるのが普通だ
SmalltalkやJVMは普通になれなかった

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

>>361
じゃあなんでわざわざTraitsなんて名前つけてんの？ぷぷぷ

**デフォルトの名無しさん** · 2017/07/14(金) 07:44:52.22

>>361
perlのtraitはtraitじゃない
roleがそうだけど中途半端
実質phpだけじゃねーの？
rubyもmixとして実装試みたけど致命的欠陥があって諦めたし

**デフォルトの名無しさん** · 2017/07/14(金) 08:07:10.82

rustにもtraitあるよ

**デフォルトの名無しさん** · 2017/07/14(金) 08:27:52.66

Traitsを名乗るかどうかは別として
継承によらない（つまりフラット化による）合成が可能で
実装も持てるインターフェース様エンティティは
次世代以前に現世代の言語には欠かせないよね

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

実装を持った複数のインターフェースが衝突したら
（可能なら静的に）検知してエラーになるのが良い
だからフラット化も正直どうでも良いんだよね

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

継承パスなんかを持ち込んだ日にゃメソッド毎のオーバーライドの管理が面倒だろ？
それゆえにTraitsはフラット化がミソなわけよ
つーかフラット化どーでもいいとか言ってる前世代脳はミックスインで十分なんだからこっちくんな
未来永劫リニア化で疲弊してろ

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

>>369
衝突したらエラーって言ってるのが読めないのかね文盲は
ユニークなんだからフラットだろーがリニアだろーが関係ないのが理解できない？

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

衝突→エラーは当たり前だボケ
その後の対処の話してんのわかんない前世代脳はあっちいってろよ

**デフォルトの名無しさん** · 2017/07/14(金) 10:04:09.28

>>362
独自vcsがゴミでgitに乗り換えたって話の直後に
独自デプロイ機構を自慢するなんて学習能力なさ過ぎでしょ
たまにはsmalltalkの外の世界を学んで見ては？

http://qiita.com/tomooda/items/8685782c42f674307dfe

**デフォルトの名無しさん** · 2017/07/14(金) 10:19:56.39

そういうトンチンカンな攻撃しないようにアンチもちゃんと学ぶべきと思うが
そもそもアンチはSmalltalkの閉じた世界の利便性なんてクソの役にも立たんと決めつけているから
永久に話が噛み合うことはなさそうだな

**デフォルトの名無しさん** · 2017/07/14(金) 10:33:01.95

世の中の0.001%でしか使われてないマイナー言語側が外を学ぶべきなのは自明だと思うが
ていうか、学ばないから永遠にマイナー言語なんだよ

**デフォルトの名無しさん** · 2017/07/14(金) 10:46:19.81

前このスレにSmalltalk のコード書き散らしてた奴いたけどあのコード汚かったなあ
Smalltalk が汚いのかあのSmalltalkerが汚かったのか知らんけど

**デフォルトの名無しさん** · 2017/07/14(金) 11:04:48.92

世の中の0.001%でしか使われてないって情報自体が不勉強なアンチ発の情報なんで定かでないんだけど
少なくとも本人はそういう認識でいる言語に丁寧にアンチ対応するのはつくづくヒマな御仁だなとは思う

**デフォルトの名無しさん** · 2017/07/14(金) 11:19:42.57

いずれにしてもtraitはともかくsmalltalkの話はどうでもいいよ
アンチ情報が古くて役に立たないししつこくてウザイだけだよ

**デフォルトの名無しさん** · 2017/07/14(金) 12:18:47.34

>>372
SmalltalkでもJenkinsでCIできるっていうことだよね？
で、Smalltalkの何が問題？ばか？

**デフォルトの名無しさん** · 2017/07/14(金) 12:20:08.63

>>368
SmalltalkのTraitsも衝突を静的に検知できるけど、それがどうかした？

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

>>379
出来ないから嘘つくな

**デフォルトの名無しさん** · 2017/07/14(金) 13:19:34.73

むしろなぜ出来ないと思うかが謎

**デフォルトの名無しさん** · 2017/07/14(金) 14:20:15.48

実行時にクラス定義の式に到達したときにエラーが出るのを「静的に検査してる」というのは頭悪過ぎない？

**デフォルトの名無しさん** · 2017/07/14(金) 15:13:18.09

>>382
そのエラーがどうして出せるのか理解できてる？

**デフォルトの名無しさん** · 2017/07/14(金) 15:13:38.24

実行前から普通にチェックできるけど？

**デフォルトの名無しさん** · 2017/07/14(金) 15:41:16.51

アンチの頭の固さが露呈したな

**デフォルトの名無しさん** · 2017/07/14(金) 17:25:07.85

>>384
出来なかったけど？
エアプ良くない

**デフォルトの名無しさん** · 2017/07/14(金) 17:40:20.13

>>386
>>383

**デフォルトの名無しさん** · 2017/07/14(金) 19:21:36.90

え？
Smalltalkって動的にクラスを定義できない言語なの？
遅延結合の観点から言って出来損ないなんだね

**デフォルトの名無しさん** · 2017/07/14(金) 21:11:13.40

かわいそうに…追い詰められてついに気が狂ったか

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

承認欲求だか何だか知らないが
文章を正確に書きたいという欲求とは違うんだろ
むしろ書くことに興味ないから代わりに全部書いてくれる良き理解者が必要になる

**デフォルトの名無しさん** · 2017/07/14(金) 23:24:30.71

Smalltalkerじゃ頭がSmallwwwww

**デフォルトの名無しさん** · 2017/07/14(金) 23:34:39.08

めでたくアンチも発狂したことだしsmalltalkの話はこれで終わりな

**デフォルトの名無しさん** · 2017/07/15(土) 07:15:30.91

根拠を書かずに勝利宣言か
いつもなら邪魔なくらいコード出してくるのにね

**デフォルトの名無しさん** · 2017/07/15(土) 08:01:11.45

gitのときみたいに、深く突っ込まれるとボロが出るからSmalltalkerさんも速く話を畳みたいんだろ
もう逃げ出してんだから追い詰めんな

**デフォルトの名無しさん** · 2017/07/15(土) 08:15:16.38

根拠？>>383が解れば説明するまでもない話だよ
あと遅延結合が徹底されてて勘違いされがちなんで念のため言っとくと
Smalltalkは例えばJavaとかと同じ程度にはコンパイラ言語だよ

**デフォルトの名無しさん** · 2017/07/15(土) 09:04:45.79

アンチ頭悪すぎ
いつまで続けるんだこのスレ違い

**デフォルトの名無しさん** · 2017/07/15(土) 10:18:51.32

PHPのtraitsは実行時検査しか出来ないんだから383は説明になってないわな
ていうか頑なに言葉を濁すのはなぜ？

**デフォルトの名無しさん** · 2017/07/15(土) 10:29:26.28

自分も分かってないからだろ

**デフォルトの名無しさん** · 2017/07/15(土) 10:59:23.57

SmalltalkのTraitが実行前に衝突検知できるかどうかの議論で、PHPじゃできないじゃないかー！と駄々をこねるバカ（>>397）発見w

**デフォルトの名無しさん** · 2017/07/15(土) 11:11:31.57

>>383が解ってる人には>>382のどこがトンチンカンだか説明は不要だろってだけの話
「わかりません」って言ってくれればちゃんと説明するよ

**デフォルトの名無しさん** · 2017/07/15(土) 11:27:36.40

昔からWYSIWYGとかいう
ModelとViewの見分けがつかない謎のシステムがある
静的と動的の見分けがつかないシステムもそれに似ている