次世代言語議論スレ[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/03(月) 23:08:44.96

>>226
小学生に算数って実は面白いかも？って思ってもらう本(電子書籍)書いてからね。
元々書きたいとは思ってるんよ。

Haskell入門以前って電子書籍は出してる。
以前って付くの一冊しか無いから一発。

普通の再帰が末尾再帰に自動変換の下りは嘘っぱちで、スタック消費を抑えただけだったみたいなんだけど、それ以外なら関数脳作る一助になると思う。
お金あるならプログラミング in OCamlのが関数脳作るのに良いと思うけど。
(これの著者がHaskell本書いてくれれば最高なのに)

**デフォルトの名無しさん** · 2017/07/03(月) 23:11:09.43

>>232
あえて嫌われ役やってんのに、課題解かずにROMれとかおいらの思う壺。
やはりHaskellはLLよりも再利用性が高い。

**デフォルトの名無しさん** · 2017/07/03(月) 23:16:44.69

>>233
2冊ww

**デフォルトの名無しさん** · 2017/07/03(月) 23:16:55.17

ジョブズのように美しいデザインに異常にこだわるタイプが
もし表現の自由や基本的人権を美しくないと判断したら何が起きるか
既に何か起きてるか

**デフォルトの名無しさん** · 2017/07/03(月) 23:30:27.58

>>235
多分尼とパブーの2冊。
内容同じ。
パブーは無料。
尼は無料に出来なくて仕方なく100円。。。

**デフォルトの名無しさん** · 2017/07/04(火) 00:13:38.28

nl, tac, grepで全部事足りるんだが

**デフォルトの名無しさん** · 2017/07/04(火) 00:47:05.17

nlなんて書いた覚えないが。。。
tacやgrepと言うコマンド名を知らなかった頃に書いたのを、リネームしただけだからね。
そう言う機能がないか調べるより書いちゃえって主義。
おいらの場合、そうでも無いとプログラミング力が付かない。

**デフォルトの名無しさん** · 2017/07/04(火) 04:24:48.11

>>231
スレチだけどVimのyuioを潰すのは許せん
それはマジで許せん

**デフォルトの名無しさん** · 2017/07/04(火) 06:47:47.53

>>239
再利用性が大事なんじゃなかったのか?

**デフォルトの名無しさん** · 2017/07/04(火) 12:23:37.78

Linux始めたばかりで探すより書いたほうが早かったから。
どっちが早いかの問題。

**デフォルトの名無しさん** · 2017/07/04(火) 12:25:05.34

>>240
自分用だから。。。
公開するとしても選ぶ自由はユーザーにある。

**デフォルトの名無しさん** · 2017/07/04(火) 14:01:02.84

やんくとアンドゥ潰すとか誰が使うんだよ

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

よく見たらinsertモードと改行insertも潰れるのかｗｗｗ
もうそれvimでもなんでもねーやん

**デフォルトの名無しさん** · 2017/07/04(火) 14:15:22.45

勉強せずに自分で作るとか言ってるとヤンクアンドゥインサート改行インサート潰すガイジに成り下がるのか
やっぱり慣例の勉強って大切だわ

**デフォルトの名無しさん** · 2017/07/04(火) 18:25:49.77

再利用性大事とか言いつつオレオレ仕様で車輪の再発明しちゃうアホンダラなんだなぁHaskellerって

机の上のお勉強はできるのかもわからんが、ギークとしてのセンスが皆無なんだな

**デフォルトの名無しさん** · 2017/07/04(火) 18:30:51.12

探す手間より書いた方が早いとか言うやつは、自分の書いたもの見せびらかしたいだけ

お勉強はできるからそこそこのものを作れるんだろうが
既存の枯れたものの仕様ガン無視で作るせいで結局作ったお前さんしか再利用できないオナニーの産物

**デフォルトの名無しさん** · 2017/07/04(火) 18:35:07.55

別に言語の再利用性は机の上でのお勉強の得意なお前さんの言う通り
Haskellの方が高いんじゃねえの？しらんけど

でもお前さんがオレオレで作ったものの再利用性は低いよなあってお話
なんせ既にあるものガン無視でオレオレ仕様の再発明しかしてねえんだから

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

>>239
いくらなんでもgrepも知らないって調べるより書いちゃえも何も、
単純にエンジニア、ライブラリアンとしてものを知らなすぎだろ

ls, find, cat, grep, sed, awk, xargsくらいは、知ってないとわけわからんよ
プログラミング力どうこう以前の問題

Haskellプログラマが全員こんなに馬鹿だと思われるのはすごく悲しい

**デフォルトの名無しさん** · 2017/07/04(火) 19:26:44.78

cat より less
cat より vi

**デフォルトの名無しさん** · 2017/07/04(火) 19:32:55.21

catよりdog

◆QZaw55cn4c · 2017/07/04(火) 20:15:18.37

>>184
Haskell のクイックソートやマージソートは本質を失っている，重要なのはインプレイス性だが haskell にそれは望めない

**デフォルトの名無しさん** · 2017/07/04(火) 20:35:49.53

>>244-246
そうか、ヤンクも潰しちゃうねぇ。。。
あれか。
Ctrl+hjklとかAlt+hjklに移動は集約しちゃうか。
コーディングしたくて気が早って"("押したら移動しちゃうとかが不便で、そう言うの起きにくい仕様にしたいだけなのよね。

オレオレのオナニーで結構だとは思うんだけど、不便にしたいわけじゃない。
少なくともおいらにとっては便利じゃないと。

>>247
ずっとWinだったんでcdとcatとlsはとりあえず分かったけど、awkとsedは聞いた事あるだけで、どんな機能か未だ分からず。
時間見て調べる予定。
grep,findはそう言う機能はあるだろうなとは思ったけどfindは望む機能じゃなかった。
grepは鯖入門書読むまで知らなかった。

元々そう言う不便な環境に身を置けば欲しい機能は自分で書くしかなくなるから、プログラミング能力伸びるだろってのが目的なんで、ある意味目論見通り。

**デフォルトの名無しさん** · 2017/07/04(火) 20:37:38.04

>>253
インプレイス性と言うのは何でせう？
それが分からんと反論も同意も何も出来ない。

**デフォルトの名無しさん** · 2017/07/04(火) 22:34:12.67

In-placeじゃね？
（ほとんど）メモリ追加せずにその場でソート

**デフォルトの名無しさん** · 2017/07/04(火) 23:18:10.83

ああ、省メモリってことね。
そりゃそうだ。
おいらだって手続き型言語で書けばなるべく書き換えで済まそうとする。
手軽さ優先か性能優先かだよ。
でも、性能優先のコードしか提示されなかった頃はどう言う動きか読み取れなかった。
その時点でプログラマの才能無いんだろうけど。
Haskellのコード見て、手続き型言語で書くには？ってなったら自然と配列書き換えられるんだから、書き換えた方がメモリ少なくて済む(&配列追加の手間が無い)ってなる。

言語によって面倒くささが違うんよね。
例えば総当たりソートとクイックソートは手続き型言語じゃ難易度に大差あるけど、関数型言語は大差無かったり。

LLでも大差無いけど、おいらのmfptn関数みたいなのがLLって感じで、難しい言語でよく使うパターンを文法やライブラリにしましたってだけで、そこから外れると普通の手続き型言語。

◆QZaw55cn4c · 2017/07/05(水) 03:30:13.16

>>256
データのコピーを極力少なくしてその場でソート

**デフォルトの名無しさん** · 2017/07/05(水) 06:47:52.98

>>250
そこから漫画みたいなインフレが起きて「perlくらい知ってないと」ってなるのが
linuxの醍醐味

**デフォルトの名無しさん** · 2017/07/05(水) 07:01:16.37

>>257
お前Haskellで書きにくいコードから逃げて、
書けるとこだけ書いてHaskell書きやすいって言ってるだけじゃねーか
お前はそのクソコードで満足なのかもしれんが、それを押し付けてくんな

違うっていうならin-placeのソート書いてから能書き垂れろ

**デフォルトの名無しさん** · 2017/07/05(水) 07:27:05.94

それの何がいけないんだろうか。。。
速度欲しい時だけCで書けば良いってのはまさにそれだが。
Haskellでも書けないことはないんだろうけど、楽するための言語なんだから、そんな事するならCで書くよ。
おいらにとってはLL的な用途にはLLよりHaskellのが楽だった。
それだけの事。

**デフォルトの名無しさん** · 2017/07/05(水) 07:33:33.70

仕様書の常套手段か
書ける仕様だけ書いて残りは実装依存で逃げる

**デフォルトの名無しさん** · 2017/07/05(水) 07:38:51.44

Haskellの再利用性に関する重大な課題は>>80-81で既に示されてるね
mfput君の意見がまだみたいだけど見解は?

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

>>142も結局mfputしか再利用出来てないし
mfput君は今のところ肝心の再利用性の高さについてはほとんど立証できていないように見える
Haskell云々というより本人の設計センスの問題な気もするが

**デフォルトの名無しさん** · 2017/07/05(水) 08:10:24.97

お前の意見なんて「自分のような初心者にとってはHaskellは分かりやすかった、以上」だけで十分なんだよ
お前のクソ初心者臭いコードやポエムを読まされて
他者が得るものがあるとでも？

**デフォルトの名無しさん** · 2017/07/05(水) 08:28:35.89

2chのレスに得るもの求めるとかガイジかよ………
Stack overflow 池

**デフォルトの名無しさん** · 2017/07/05(水) 08:33:57.06

俺は2chで煽り耐性を身に着けた

**デフォルトの名無しさん** · 2017/07/05(水) 10:00:37.58

このスレでガイジガイジ連呼してるやつマジ病気かよ
どんだけリアルで悲惨な人生だったらこうなるんだ

**デフォルトの名無しさん** · 2017/07/05(水) 10:24:17.91

漫画みたいにいつまでたっても話が終わらない
病気か才能かはわからんが

**デフォルトの名無しさん** · 2017/07/05(水) 12:26:16.42

Haskellの言ってることは一応一貫してる
そこに突っ込んでる人は一貫してる部分を読めていないとしか思えないツッコミばっかり
そんな的を外したらツッコミに逐一返信してるんだから永久に終わるわけがない

**デフォルトの名無しさん** · 2017/07/05(水) 12:32:33.78

>>263
>>81がまさにおいらの回答だが。。。

mfputはLLより短く書けないもんかと考えた時、あらゆるものが関数何だから関数化出来るじゃんって思い付いた。

**デフォルトの名無しさん** · 2017/07/05(水) 12:38:33.21

>>265
あはは。
その通りだよ。
LLより初心者に優しいってのがまず一つ。
LLに限らないけど、定型文になってる部分もパターン化して関数にし易い(LLでも出来るだろうがスマートじゃない)

**デフォルトの名無しさん** · 2017/07/05(水) 12:45:05.83

しんちゃんスレ

**デフォルトの名無しさん** · 2017/07/05(水) 12:53:14.41

>>271
81が回答とかさすがにガチハスケラにぶん殴られるぞ
ハスケラはこういう突っ込みには
「呼び出し側も含めて設計を見直せ。状態を持たせるというのは本質的に重大な変更であるから影響が大きいのは当然である。」と答えるのがテンプレだ
覚えておけば役に立つよ

**デフォルトの名無しさん** · 2017/07/05(水) 13:23:50.44

Javaでもうっかりstatic変数を使うと設計を見直させられるパターンだろ
thisとかselfとかいう引数を追加するのが定石
これはHaskellでも簡単にできる

**デフォルトの名無しさん** · 2017/07/05(水) 13:59:00.37

Javaの場合はインスタンスフィールドでいいだろ
Haskellだと直前の値を保持しているところまで遡って全部修正かな

**デフォルトの名無しさん** · 2017/07/05(水) 21:01:53.58

>>274
STモナドとかで実現は出来るんだけどさ。
GUIならGUI、DBならDBに状態保持を任せちゃった方がスマートだとは思わないかい？
テンプレじゃ無く、あんたのハートに聞いてる。

ああそうそう、実はgrepは検索文字列が見つかった前後20文字表示にするか行表示にするか迷って、行表示の方が簡単だからたまたまgrepと同じ機能になっただけで、前後20文字の場合は別にファイルの内容丸ごと記憶しておく変数を引き回しても良かった。
どうせ遅延評価で必要になるまで読み込まれないから2ファイル同時でもたかが知れてるしね。
丸ごと記憶する方法も、見つかったら29文字以前をGCしやすいようにするのと1から検索させるのとあるけど、小説10-20冊を1ファイルに収めても問題無いんだから気にする事もない。

**デフォルトの名無しさん** · 2017/07/05(水) 21:03:02.86

x29
o20

**デフォルトの名無しさん** · 2017/07/05(水) 21:21:41.45

いかにHaskellキチがお勉強できて正しいこと言ってようと
こいつがgrepを始めとしたツールを知らない無知で
オレオレ仕様で再発明してドヤ顔してるトンチキなのには変わりないんだよな

**デフォルトの名無しさん** · 2017/07/05(水) 21:23:14.50

Haskellが使える言語かどうかは知らんけどHaskellerがオタンコナスなことはまた一つ実例が出てきてしまった以上の情報はないね

**デフォルトの名無しさん** · 2017/07/05(水) 21:27:53.06

このHaskellerってファイル読み込んで同じファイルに上書きするの出来ないとか言ってたはずだけど、
それでどうやってテキストエディタ作るんだろう？
まさか全部DBにデータ入れるのか？
テキストエディタのインストールの前にDBのインストールが必要ってことか？

**デフォルトの名無しさん** · 2017/07/05(水) 21:39:14.16

>>281
一時ファイルに書き出してムープじゃね？

**デフォルトの名無しさん** · 2017/07/05(水) 21:46:58.82

>>279-280
おいらがトンチキ呼ばわりはいいんだよ。
あれ、Haskell使えるんか？使ってみようかなって人が増えれば。
んで、そんな無知で馬鹿な奴でも書けるアピールな。

**デフォルトの名無しさん** · 2017/07/05(水) 21:50:19.56

>>281
それはwriteFile関数の仕様。
readFaile幾つ読み込んでもいいし、下位の関数探ってれば複数ファイル書き込めるのもあるだろう。
安全の為の仕様だし、安全じゃないのを許容するのがあるはず。
最悪、Cで書いてFFIでHaskellから呼べば良い。

**デフォルトの名無しさん** · 2017/07/05(水) 22:04:05.82

>>277
全く思わないな
なんで勝手にGUIやDBを前提にしてるんだ?
これまで状態を持たなかった関数を前後の値を考慮するように変更したいというのは
君の大好きな「LL的なタスク」であってもそれほど珍しい状況ではないように思うぞ?

**デフォルトの名無しさん** · 2017/07/05(水) 22:42:05.37

>>281
よく知らんけどleksahって言うHaskell製IDEが実在しているのでこのHaskellの人が言ってることが間違ってるのは間違いない

**デフォルトの名無しさん** · 2017/07/05(水) 22:49:59.85

つーか>>274に>>277で返すのは会話が噛み合ってないだろ
正しい答えは「ごめんなさい」だ

**デフォルトの名無しさん** · 2017/07/05(水) 23:03:23.20

だいたいDBやGUIに持たせるといってもどこからそのコンテキストを持ってくるんだ?
結局呼び出し階層を遡って大修正だろう
暗黙的に環境の状態にアクセスするような関数があればいいとか思ってるなら、冗談抜きで怖いハスケラに夜道で襲われるレベルの邪悪な思想だぞそれ

**デフォルトの名無しさん** · 2017/07/06(木) 00:04:57.61

大きすぎて修正できないならさっさと諦めて逃げれば邪悪にはならないが
逃げるくらいなら邪悪な方がマシだと思うから邪悪になる

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

>>283
まーHaskell自体は決して使えん言語ではないのは知ってる

書くもんが大型化してくるとデフォ遅延評価のせいで副作用周りのデバッグが発狂難易度になるとか
ちょっと気を抜くと遅延サンクが膨れ上がって死ぬとか
色々あるからあんまりモノリシックにでかいものを複数人で書くのには向いてない言語だとも思うがね

そういう意味でHaskellはハードウェア記述言語に向いてると思うんだが、まだこれといったやつが出てきてないんだよな

**デフォルトの名無しさん** · 2017/07/06(木) 02:15:34.43

そもそも関数型が解決しようとした問題は、副作用の連鎖による想定外のトラブルだろ
大規模な構造をどう記述するかということであって、もうそれはOOPが解決してしまった

**デフォルトの名無しさん** · 2017/07/06(木) 08:32:49.91

つまり純粋関数型は使えないと？

**デフォルトの名無しさん** · 2017/07/06(木) 08:51:12.34

その純粋ってのを保証してるのはコンパイル時の型チェックだな
それがなければ使える

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

つまりscala最強ってことか

**デフォルトの名無しさん** · 2017/07/06(木) 09:24:44.24

オブジェクト指向プログラムで副作用は解決してないだろ。どうみても。

**デフォルトの名無しさん** · 2017/07/06(木) 09:46:24.49

288の言う「呼び出し階層を遡って大修正」は
副作用有り・無しのチェックだけじゃない
ヌルを許容する・しないのチェックで破綻するケースもある

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

>>296
あるある
汎用性を考え出すとモナドとMaybeにまみれて何のための静的関数型かよく分からなくなってくるんだよな

**デフォルトの名無しさん** · 2017/07/06(木) 17:43:28.35

>>290
うちのプロジェクトは遅延評価禁止ね全部先行評価で書け
oO（ソースが全然Haskellに見えないｗ）

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

プログラムが現実と関係を持ちつつ社会の中で動いている以上副作用を無くすことはできない。
全体を停めることができず、部分単位でアップデートを繰り返すならなおさら。
そう言った意味で『関数型言語』は結局いつまでも実現することのない賽の河原の石積み。

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

まあ言語の機能によって副作用のないコードエリアを明示するってアイディアは
良いと思うんだけどね。
haskell は変な極論を推し進めてどうしようもなくなってるという印象が強い。

**デフォルトの名無しさん** · 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

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