2016年05月20日の日記

2016-05-20

http://anond.hatelabo.jp/20160520062438

FRPの複雑さが、状態渡しの複雑さと一緒だ、とか明らかにデタラメを言ってるからだろうな。

http://anond.hatelabo.jp/20160520163030

「悪質な詐欺が横行しているが、正しい物もある」(それはうちの商品…)

って詐欺師のやり方と同じに見えるので、

詐欺じゃないなら、水素水を飲むと人間健康になる、エビデンスくださいな

http://anond.hatelabo.jp/20160520061937

http://kenokabe-techwriting.blogspot.jp/2016/05/timeengine.html

nonstarterの言うことがハッタリじゃなければ、さっさとToDoListの課題Ocaml関数型の状態渡しをもって実装してみせればいいだけだが、言い訳始めてるからな。

もちろん、OCamlであれHaskellであれ破壊的代入の類の副作用使用せずに書くのもなんら困難ではありません。

nonstarterはこの発言の時点では、Ocaml関数型の状態渡しに限界があることはお首にもだしていない。読んだものはそうだったのか、何でもできると思って不思議ではないだろう。

しかしなぜか、Haskellが急に登場する。別の言語の助けを求め始めた最初がここ。

そのうち、OCaml実際的環境じゃスケールしないという指摘がはいる。

nonstarterは、複雑性への限界を認めるが、同時に、FRPの足をひっぱることも忘れ得なかった。つまり「負けてない!」ってことなんだろw

しばらく有耶無耶にされていたが、お絵かきアプリもまだ書けないといか書かれているのを目撃した岡部氏が、すでに実装していた自作FRPライブラリお絵かきアプリを示して、

ついでに、ハードルを引き上げた。

nonstarterの言うとおり、

もちろん、OCamlであれHaskellであれ破壊的代入の類の副作用使用せずに書くのもなんら困難ではありません。

かつ、FRPも同じ複雑さへの限界ならば、

岡部氏が示したFRPコードと同等のかんたんさで、OCamlでも出せるはずだ。

もちろん、他のHaskellFRPは使うな、という至極当然の縛りつき。

ちょっと本気出されたら、言い訳始めた、それが今。

http://anond.hatelabo.jp/20160520153948

OCamlでは」普通に副作用を使うライブラリしかいかスケールしない、って書いてあるのに

なんで勝手一般化して、Haskellとかでもスケールしないことにしたいの? 本当に牽強付会オンパレードですね。

そもそもの最初がesumiiやlambadaなどのOCamlユーザへむけての課題で、

nonstarterが、

もちろん、OCamlであれHaskellであれ破壊的代入の類の副作用使用せずに書くのもなんら困難ではありません。

と急に何故かいきなりHaskellを持ち出し、Haskellコードを引っ張り出した。

いろいろとっちらかしてんじゃねーよ、ってことだろ。

OCamlではライブラリも足りず机上の空論だったという、ひとつ区切りはついた。

もちろん、OCamlであれHaskellであれ破壊的代入の類の副作用使用せずに書くのもなんら困難ではありません。

とこの点について「一般化」を試みた、誤魔化そうとしたのは、nonstarterだ。

からごましてんじゃねーよ、ってそこをまず明確化されている。

http://anond.hatelabo.jp/20160520061815

TImeEngineは命令型でも破壊的代入でもない

http://kenokabe-techwriting.blogspot.jp/2016/05/timeengine.html

まさにtimeengineプログラムに頻出するフィールドtが「状態」、tへの破壊的代入が「変化」ですね。

と、書いてる人間が言外に馬鹿だとこきおろされている。

まあ、すでに別の流れで、おまえにはFRP語るな、と釘さしておいたが。

http://anond.hatelabo.jp/20160520162247

分子水素が含まれ水素水なら効果があるのは間違いないんですが、

問題は、水素が含まれていないのに水素水と命名して販売していたり、

水素が抜けてほとんどただの水になっているもの水素水として売りつける業者が後を絶たないということなんです。

http://anond.hatelabo.jp/20160519120217

Qiitaでもこの2ch誹謗中傷スレ連携して、集団攻撃している、と指摘されてたね。

LambadaのQiitaポスト2ch書き込みと数分違いとか。必死否定していたけど。Qiitaはそういうの知ってて容認してた。

http://anond.hatelabo.jp/20160520161816

自分が座ることで相手迷惑を掛けることを恐れて遠慮するのです。

水素水なんてウソッパチだ!

一周回って逆に、「水素水って実は効果があるんじゃ?」と思ってきている。ヤバイ

電車自分の隣に人が座らない現象外国人説明できるか

電車自分の隣に人が座らない現象」を外国の人は自分差別されているのではないかと考えてしまうらしい。


日本にくる外国人あるある現象らしいんだけど日本人に聞いても「差別であるとは言われず大抵曖昧言葉否定される。

これは日本人ならなぜそう答えるのか大体わかるんだけど、いくら説明しても海外の人は差別であるといい続けるしその疑念がぬぐえないみたいだ。


まずそもそも「電車自分の隣に人が座らない現象」は外国人だけではなく日本人経験している人が多い。

その理由として挙げられるのは以下のような理由である


・顔が怖い、表情が怒っているように見える

・外観(髪型服装や態度)がガラが悪そう、ヤンキーっぽい、あるいはオタクっぽい

・不潔(非常に汗をかいている、風呂に入らない、服を着替えない)

特にワキガ自分では気付かないことが多い)。この中で最悪かも。

・太っている(隣に座れない、狭い)。

・一人の世界に浸ることが好き。独り言をよく言う、車内でパソコンなど場所を取ることをやる、等。

・足の位置(意外に重要)。足を組んだり、大きく開かないと安定が悪くて落ち着けない。他人迷惑です。

Yahoo知恵袋引用 -http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1070593140


電車自分の隣に人が座らない現象」は多くの日本人自身がそもそも経験しており、更に上記のように複数理由が考えられるため

「外観が原因である。」

という理由だと特定できない。

まさか隣に座らずなぜか立っている人にいちいち聞くわけにもいかないし、そもそも特定できないのだ。

なのでネット上で検索すると「女性に席を移動された(意図不明)」「誰も俺の隣に座らない(臭いからか?)」「私の香水が臭かった?(よくわからない)」みたいな悲しい事例があふれるほど出てくる。


よって、「電車自分の隣に人が座らない現象」は差別が原因であるとは断定できず、更に考えられる理由複数あるため日本人反論は「差別とは限らない」みたいな曖昧な返事になってしまうわけだ。


なのでこの反論を聞いた外国人はかならず「本当は差別だけど日本を悪く言われたくないか日本人適当言い訳しているんじゃないか」と思うことになる。


上記の理由からかこの話題過去から現在まで延々とループし続けている。

海外ではこの現象は発生しづいか日本に来て目立つのか、そもそも日本人パーソナルスペースが広いとか干渉を避けたがるとか色々理由はあるとは思う。

でも差別が原因だとは容易に特定するのはそもそも不可能だ。

なにか外国人でもこの事情をズバッと理解できるような明快かつ簡単説明や例えは思いつかないだろうか。

http://anond.hatelabo.jp/20160520155029

系統が凄い

京都方面奈良方面京都方面八木方面大阪方面奈良方面大阪方面八木方面を平面交差で捌く。

→そのため、構内のポイント数がかなり多い。

・来る列車の種類が凄い

近鉄だけでも通勤タイプ特急タイプが来る上に、阪神京都地下鉄車両も来る。

NHKのDボタンニュース

いつもはザッとまとめてある印象のニュースだけど、Windows強制アップデートの件は3ページつかってめっちゃ詳しく書いてたから参考になったよ。

はてなを長くROMってたからかブコメ増田打率がやたら高い

初めて書いた増田で200ブクマ行ったり5回に1回は人気コメント入ったりする

自然と口をついて出てくる言葉ブクマから人気を集める

そんな星の元に生まれている

http://anond.hatelabo.jp/20160520153948

もちろん、OCamlであれHaskellであれ破壊的代入の類の副作用使用せずに書くのもなんら困難ではありません。

nonstarterはこの発言の時点では、Ocaml関数型の状態渡しに限界があることはお首にもだしていない。読んだものはそうだったのか、何でもできると思って不思議ではないだろう。

しかしなぜか、Haskellが急に登場する。別の言語の助けを求め始めた最初がここ。

そのうち、OCaml実際的環境じゃスケールしないという指摘がはいる。

nonstarterは、複雑性への限界を認めるが、同時に、FRPの足をひっぱることも忘れ得なかった。つまり「負けてない!」ってことなんだろw

しばらく有耶無耶にされていたが、お絵かきアプリもまだ書けないといか書かれているのを目撃した岡部氏が、すでに実装していた自作FRPライブラリお絵かきアプリを示して、

ついでに、ハードルを引き上げた。

nonstarterの言うとおり、

もちろん、OCamlであれHaskellであれ破壊的代入の類の副作用使用せずに書くのもなんら困難ではありません。

かつ、FRPも同じ複雑さへの限界ならば、

岡部氏が示したFRPコードと同等のかんたんさで、OCamlでも出せるはずだ。

もちろん、他のHaskellFRPは使うな、という至極当然の縛りつき。

ちょっと本気出されたら、言い訳始めた、それが今。

大和西大寺駅のすごさが分からない

今住んでる、近所にあるすごい駅らしいけど、

なにがすごいのか分からない。

ホームが一杯あるって言うなら、

哀愁漂う門司駅とか幡生駅とかがグッとくるけどな

俺はクズ

クズの俺が生き残り

頭のいいあいつは世界からいじめられて

絶望して死んだ

俺は馬鹿

http://anond.hatelabo.jp/20160520154237

国際学会」ねー。

FRPについての合意について?w

ソースは?ほら出してみろよw

http://anond.hatelabo.jp/20160520153948

http://anond.hatelabo.jp/20160520153948

nonstarterのいうことが嘘ハッタリじゃないのならば、さっさとOCaml関数状態渡しでToDoリストアプリ書いて見せればいいだけ。

出来ない時点で終わってる。

もちろん、OCamlであれHaskellであれ破壊的代入の類の副作用使用せずに書くのもなんら困難ではありません。

nonstarterはこの発言の時点では、Ocaml関数型の状態渡しに限界があることはお首にもだしていない。読んだものはそうだったのか、何でもできると思って不思議ではないだろう。

しかしなぜか、Haskellが急に登場する。別の言語の助けを求め始めた最初がここ。

そのうち、OCaml実際的環境じゃスケールしないという指摘がはいる。

nonstarterは、複雑性への限界を認めるが、同時に、FRPの足をひっぱることも忘れ得なかった。つまり「負けてない!」ってことなんだろw

しばらく有耶無耶にされていたが、お絵かきアプリもまだ書けないといか書かれているのを目撃した岡部氏が、すでに実装していた自作FRPライブラリお絵かきアプリを示して、

ついでに、ハードルを引き上げた。

nonstarterの言うとおり、

もちろん、OCamlであれHaskellであれ破壊的代入の類の副作用使用せずに書くのもなんら困難ではありません。

かつ、FRPも同じ複雑さへの限界ならば、

岡部氏が示したFRPコードと同等のかんたんさで、OCamlでも出せるはずだ。

もちろん、他のHaskellFRPは使うな、という至極当然の縛りつき。

ちょっと本気出されたら、言い訳始めた、それが今。

そもそもの最初がesumiiやlambadaなどのOCamlユーザへむけての課題で、

nonstarterが、

もちろん、OCamlであれHaskellであれ破壊的代入の類の副作用使用せずに書くのもなんら困難ではありません。

と急に何故かいきなりHaskellを持ち出し、Haskellコードを引っ張り出した。

いろいろとっちらかしてんじゃねーよ、ってことだろ。

OCamlではライブラリも足りず机上の空論だったという、ひとつ区切りはついた。

もちろん、OCamlであれHaskellであれ破壊的代入の類の副作用使用せずに書くのもなんら困難ではありません。

とこの点について「一般化」を試みた、誤魔化そうとしたのは、nonstarterだ。

からごましてんじゃねーよ、ってそこをまず明確化されている。

http://anond.hatelabo.jp/20160520141111

それこそ国際学会とかで認められてるのがどっちか考えれば明らか。

三大「相手の主張を封じるかっこいい言葉



あと一つ思いつかなかった

http://anond.hatelabo.jp/20160520153916

最近だけど?

さっさと書いてみせたら?ここで言い訳してるから白旗あげてるっぽいけど。

書けるならとっくに書けるだろ。簡単な例題なんだし。

http://anond.hatelabo.jp/20160520153456

OCamlでは」普通に副作用を使うライブラリしかいかスケールしない、って書いてあるのに

なんで勝手一般化して、Haskellとかでもスケールしないことにしたいの? 本当に牽強付会オンパレードですね。

http://qiita.com/nonstarter/items/2763f5d85f2b8df3b18b#comment-d9a8cdf2efc67044c158

OCaml の全ての GUI ライブラリ状態副作用を使うことを前提にメインループ設計されているからです。これを乗り越えるとすると @Lambada さんのようにメインループ自体自分で書く事になり、一般的にはスケールしません。HaskellGUI ライブラリでは普通状態State なり IO を含む GUI モナドを使って書く事になりますが、そのような GUI ライブラリOCaml 上で作れば同じような事が出来るはずです。OCaml でそこまで純粋関数型のコードを書く事に実用意味があるとは思えませんが。

ログイン ユーザー登録
ようこそ ゲスト さん