- + JavaScript の質問用スレッド vol.124 + [転載禁止]©2ch.net
790 ：デフォルトの名無しさん[sage]：2018/02/02(金) 22:51:14.28 ID:ZJzCT+jY - ついでだから、何故韓国人を殺さなければならないか、さらに説明しておく。
非韓三原則
韓国人には、助けない、教えない、関わらない
日本人はディベートが下手だが、これは場数を踏んでないからだ。
論理は出来ている。上手くなる為には後は場数を踏むしかない。
>>757から一連のレスは（内容はさておきディベートの形式は)まあまあだ。
だから、やりたいのなら気が済むまでやればいい。
それに対して、韓国人>>760は糞だ。
これはパヨク/韓国人/ヤクザの論法で、相手にしても何も得られない。
だから相手をしてはいけない。韓国人/ヤクザは無視して殺すべきだ。
違いを見分けるのは（知っていれば）簡単だ。
ディベートはある事柄に対し「どちらがいいか」を決着する物だ。
だから通常戦術は「相手の意見を否定しつつ、『自分の意見を補強』（ここ大事）する」ことになる。
自分の意見が優勢なら＋、劣勢なら−としてスコアを付けると、
通常、双方の発言で０を挟んで天秤のように振れ、発言毎に、+1, -2, +2, -1 といった経路を辿る。
これに対して、パヨク/韓国人/ヤクザの論法はそうじゃない。
「相手を否定すること」だけを目的とし、自説の補強は全く行わない。
そして「対応できない相手が悪い」と連呼し、精神的に参らせるわけだ。
ヤクザやパヨクがよくやっている手だから見たことあると思うが。
この場合、上記スコアを付けるのなら、０から＋方向にしか振れず、意見が広がっていかない。
典型的には「対案を出せ」と対策されるケースだ。
相手は否定するばかりで、新しい知見を出さないものだから、
結局自分の意見の範囲でしか広がらず、ブレストにもならない。
韓国人死ね
|
- + JavaScript の質問用スレッド vol.124 + [転載禁止]©2ch.net
791 ：デフォルトの名無しさん[sage]：2018/02/02(金) 22:52:10.85 ID:ZJzCT+jY - > 命名規則としてソースを出して反論して (>>760)
ディベートに持ち込み、どちらが優位か結論を出す気なら、
760自身が「命名規則としてソースを出して」自説を補強すれば、それで済む。
それをせず、相手に要求して連呼するのはヤクザのやり方。上記通りだ。
相手にしたところで、何も得られない。だから無視して殺さなければならない。
多分、韓国人流の精神的勝利法の一環なんだと思うが、
そもそも、匿名掲示板上で勝った負けたしても意味無いだろ。
ここでやるべきなのは、「その案件について、一番妥当だと思える意見は何か」であって、
それを「誰が言ったか」は価値がないと見なすから匿名なのであって。
だから、何であっても、「それについては俺はこう思う、理由はこうだから（自説の補強）」が匿名掲示板での基本スタイルで、
相手に対して優位に立つ為の「相手の意見を否定する」戦術は基本的に必要ない。
そしてどっちの意見が妥当かは読者が勝手に判断するだけ。
相手の意見を全部否定できたとしても、スコアは０には戻るが、＋にはならない。
つまり、否定するだけだと引き分けには持ち込めるが、絶対に勝てない。
勝つ為に＋にしたいのなら、自説の補強をするしかないんだよ。しない時点でアホ確定だ。
だから繰り返すが、
> 命名規則としてソースを出して反論して (>>760)
この発言だけでこいつは馬鹿だと分かる。相手をしても何も得られない。
勝ちたいのなら、勝手にソースを出して自説の信者が増えるよう努力すればいいだけの話だ。
それが妥当かどうかは読者が勝手に判断してくれる。俺が否定しようがしまいが、関係ない。
ということを念頭に置きつつ、ディベートしたい奴は気が済むまでやればいい。場数を踏めば上手くなる。
ここは匿名掲示版なんだから、基本戦術は、「俺はこう思う、理由はこう（自説の補強）」でよろしく。
他人の意見を否定しても勝てない。勝つ気なら、よりよい意見で「上書き」することを目指せ。
あんまり酷いようなら行司してやるよ。
とはいえ、今のところ「余計なお世話」になりそうなのはいいことだね。
韓国人死ね 👀
Rock54: Caution(BBR-MD5:0be15ced7fbdb9fdb4d0ce1929c1b82f)
|
- + JavaScript の質問用スレッド vol.124 + [転載禁止]©2ch.net
793 ：デフォルトの名無しさん[sage]：2018/02/02(金) 22:53:36.67 ID:ZJzCT+jY - さらについでに講評しとくと、
>>777の時点で理解できないのは777がアホだから。
そこまでに十分な説明はなされているし、俺には通じてる。説明も下手ではない。
> そうすれば、ターゲットがクリックされたことを機会に、ターゲットをフリーズさせて、
> その間にドラッグするためのモジュールを読み込んでそこから再開するというようなことができる(>>773)
JavaScriptはそのように設計はされていない。
だからこれをやりたいのなら、何らかのサポートが必要なのも事実。
とはいえ、このやり方が必要かは議論になるだろう。
> だけどここまで考えてやっぱりObservableAPIが良いのかなと思い始めた (>>780)
> async世界と相性悪いねって話だよ (>>782)
はっきり言えばJavaScript含めて一般のプログラミング言語は
同期的に処理が行われる前提だからそもそも相性が悪い。
と言っても通じないだろうから簡単に説明すると、
var a = 1; // (A)
a = a + 1; // (B)
console.log(a); // (C)
とあった場合、(A)(B)(C)の順に処理されて2が出力されることを当然だと思ってるだろ？
世の中にはそうじゃない言語もある。
https://ja.wikipedia.org/wiki/%E3%83%87%E3%83%BC%E3%82%BF%E3%83%95%E3%83%AD%E3%83%BC%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0
韓国人死ね
|
- + JavaScript の質問用スレッド vol.124 + [転載禁止]©2ch.net
794 ：デフォルトの名無しさん[sage]：2018/02/02(金) 22:55:10.28 ID:ZJzCT+jY - >>782(続き）
プログラミング言語ではないが、verilogで説明すると、
assign a = b;
は b が変化するたびに再評価されて a = b が定常的には保証される。
JavaScriptで言えば
Object.observe(b, function(){ a = b;});
とほぼ同じと考えていい。
だからverilogの場合は(A)(B)(C)は独立な関数であって、実行順は規定されない。
必要なときに必要な順で評価される。この点はHaskellも同じで、例えば、
console.log(b);
assign b = a + 1;
assign a = 1;
については、JavaScriptならundefinedになるが、verilogとHaskellでは2と正しく評価される。
だからHaskellについて詳しいのなら、そっちから考えてもいいだろう。
Haskellは遅延評価でしかないが、初期値の計算方法自体はデータフロー型と似ているところがある。
君はイベントをデータフロー的に接続することを考えている。
それが効率がいいのかは俺には分からない。
ただし、一般的にverilogは難しいとされるから、その方法は流行りにくいだろう。
JavaScriptでは関数単位で非同期だが、verilogは行単位で非同期で、これについて行けない奴が多い。
JavaScriptでもそうだが、同期的に書きたがる奴はいるだろ？
結局の所、同期的に書けること自体が簡単なんだよ。そして簡単なことは重要な事なんだ。
君はJavaScriptをverilog化しようとしている。それは多分受けない。
韓国人死ね
|
- + JavaScript の質問用スレッド vol.124 + [転載禁止]©2ch.net
797 ：デフォルトの名無しさん[sage]：2018/02/02(金) 23:34:40.13 ID:ZJzCT+jY - >>795
それに対する返答も、俺は既に書いている。
日本語が読めるつもりなら、俺の投稿を理解できるまで読み返し、ちゃんと自殺しろ。
韓国人死ね
|