C#, C♯, C＃相談室 Part95

2017/10/17(火) 00:41:22.60

■Visual Studio 2017 Community(無償の統合開発環境)等はこちら
http://www.visualstudio.com/downloads/

■コードを貼る場合はこちら
http://ideone.com/

■前スレ
C#, C♯, C＃相談室 Part94
http://mevius.2ch.net/test/read.cgi/tech/1492843013/

■次スレは>>970が建てる事。
建てられない場合は他を指定する事。

VIPQ2_EXTDAT: checked:vvvvv:1000:512:----: EXT was configured

2019/12/29(日) 15:30:19.53

テキスト送信して相手にレンダリングさせるものと自身のウインドウ環境に直接レンダリングするものを本気で横ならびで比較する時代になったのね

2019/12/29(日) 15:59:41.03

>>465
なったというか、いわゆる(短期的な)「生産性」ってのは、どうでもいいところで如何に手を抜くか、でもあるからね。
グラが勝負なら自前でレンダリングしかないが、
>>253とか俺とか、>>452もほぼ確実にそうだと思うが、
計算ソフトの初期値設定をするだけ、みたいなGUIに時間かけて凝っても意味無いんだよ。
そこは「計算」に凝るべきであって、とりあえず多少遅かろうが表示出来れば何でもいいんだよ。

というか、こういうのを分かっててお前らはC#を選んでいるんじゃないのか？
ならまあ、お前らが奇妙なほどに信者化するのも分からなくもないが。

ちなみにUnity、内部エンジンはC++で上位スクリプトだけC#か？なら確かに芽があるかもしれん。
しかしこの構成なら、じきに上位スクリプトもPythonで書かせろ、になるとも思うが。

2019/12/29(日) 16:06:57.90

>>461
機構のどこが丸パクリなんだよ。
Cだけじゃねえか。
Formsでもイベントのさばき方次第だろ。全然Forms触ってねえだけじゃねえか。
で、イベントも普通はそう捌くんじゃなくて、バインディングするもんだよ。
何意味不明な事言ってんだよ。

2019/12/29(日) 16:08:17.70

語れば語るほど行毎に突っ込みどころ量産してるのが凄い…
釣りでガイジのフリやってるなら大したもんだわ

2019/12/29(日) 16:11:04.28

> ちなみにUnity、内部エンジンはC++で上位スクリプトだけC#か？なら確かに芽があるかもしれん。
> しかしこの構成なら、じきに上位スクリプトもPythonで書かせろ、になるとも思うが。

なんでこんな予測になるのか意味不明
unityから使用できるjavascriptが廃れた経緯があるのにまた変更なんかこないよ
ゲーム開発においてスクリプト言語が来る時代は来るかもしれんがそれはunityにはこんだろう
新しいエンジンが来たときにその時代に沿った新しい言語が採用される可能性はある

2019/12/29(日) 16:14:19.03

実際にUnityで選択肢として使えたjsとpythonがC#に駆逐された経緯とか知ったらこのキチガイ脱糞しそう

2019/12/29(日) 16:27:43.79

>>467
逆だろ。Bはこれからパクる、Cはパクリ、D/Eは直っていればパクリ、直ってなければ糞だ。

あとFormsはバインディングできない。（から自前でやるにはReflectionすることになり、これが糞）
ただバインディングについては、
バブルされたイベント拾ってそこでバリデーションして問題なければ反映、アウトなら戻す、
みたいな方が格好悪いが結果的に楽な気はする。
(既に言ったとおり俺自身がWPF使ってないから全てに於いてバインディングだけで上手く行くのかは分からない。
勿論全く問題ないならバインディングした方がいいけども)

>>469
>>470
おお、その釣り針は喜んで食いつくから、駆逐された経緯とか書いたページがあれば紹介してくれ。
つってもちょっと（席を）外すが。

2019/12/29(日) 16:36:33.93

食いつかんで良いから自分の浅はかな知識で事を語っていることを認識し悔い改めていただきたい
知りたきゃご自身でお調べ下さい

2019/12/29(日) 17:14:51.69

>>471
WPFがバインディングが基本だと言っとろうが。
FormsにもDataSourceと言う概念があって出来んもんでもないしリフレクションも必要ではない。

2019/12/29(日) 18:30:55.82

>>461
> B. CSSが当てられる。
> B. 出来ないのが悲しい
書くのが異様に面倒だけどスタイル定義はできるよ
てか、よく知らないならROMってれば？

2019/12/29(日) 19:00:10.06

>>473
> DataSource
ああそれは確かに俺は触ってないわ。何かあったけど放置してた。

一応軽く見てみたが、ちょっと使ってみないと分からんね。
.NETは若干かっこよさを追求しすぎていて、既に言った
「フォームの値をプログラムから変更してもイベントが『同期』で発生する」
もそうだけど、格好良く自動連動を目指したのだろうけど、余計に使いにくくなってる。
同様に、余計なイベント接続が行われている可能性もあるから、実際に使えるかどうかは試してみないと分からん。
JavaScriptの場合はもっとドベタに
「プログラムから変更したらイベントは発生しないから、必要なら自分で呼べ」
でしかないから、本当にドベタにユーザーが挙動を定義出来る。

言ってしまえば、JavaScriptはライト層向けにできていて、
.NETはプロ向け（.NETのことを隅々までよく知っている前提）だと言えなくもないが、
ちょっとチューニングを失敗しているように思う。
結果、JavaScriptの方が取っつきやすいから、最近はどうでもいいUIはだいたいWebアプリになってるだろ。

>>474
これか？
https://www.atmarkit.co.jp/ait/articles/1009/07/news096_2.html
これは確かにCSSの一部だが、これでは全然足りない。
スタイルを適用したいのはコントロールそのものに、ではない。
CSSが美味しいのは、左右はもちろん上下ですら表示位置を簡単に入れ替えられること。
だから見た目全く違う物も同じHTML構造を取れ、結果、
同じ関数からお約束のHTMLを吐き出して後はCSSでも当てて、みたいな手抜きがあっさり出来る。
（見た目毎に出力関数を用意する必要がない）
CSSの表現能力についてはWeb系の馬鹿共がよく「CSSでここまで出来る！」みたいなページを作っているから見てみればいい。

2019/12/29(日) 19:12:12.77

詳細を突っ込まれると
そうだね、けどこの面では…的な論理展開ばっかだけど自分で気にならないの？
これを繰り返してるうちに自身の主張が何かよくわからなくなって無意味に多方向にdisを撒き散らしてるだけになってる

2019/12/29(日) 19:21:15.54

>>475
> CSSが美味しいのは、左右はもちろん上下ですら表示位置を簡単に入れ替えられること。
それはコンセプトの違い
WPFはXAMLでコントロールの位置を変えればいいだけ
データとはバインディングで繋がってるから位置を変えてもDataSourceはいじる必要はない

2019/12/29(日) 19:24:54.99

>>475
自動連携なんて目指してない。
変更したならイベントが起こって然るべきだからイベントが起こるんだよ。

2019/12/29(日) 19:33:22.61

>>472
以下は読んだ。
https://blogs.unity3d.com/jp/2017/08/11/unityscripts-long-ride-off-into-the-sunset/
開発側の人的資源の問題と、C#のIDEが素晴らしいからだな。
まあ妥当といえば妥当。（というかそう読めるように書いてあるもんだが）

そもそもJavaScriptが動くとは知らなかったし、信者でも無いから、ダメージもないのだけど。
まあそれ以前に俺はここだからC#の話をしているだけであって、
JSはJSでそれなりに糞だから、JSスレでならJSの悪口言ってるよ。

C#のIDEが圧倒的にいいのは事実だよ。あれと同じ物を自前で用意するのは無理だ。

2019/12/29(日) 19:53:49.10

>>479
で、unityはそのうちpythonになるだろうという君の主張はどうなったの？
また同じ論理展開で主張が飛んでるよ？
そんなの知ったこっちゃないってのなら始めからズレた主張しないでね

2019/12/29(日) 20:00:11.04

>>477
だからそれが駄目だと言ってるんだよ。
XAMLを変更＝HTMLを変更と同じで、それだと、全く同じ関数とか使えないんだよ。
XAMLを弄って変更した場合、文書階層が変わるから、バブルしてくるイベントも経路が変わってしまうだろ。
すると、イベント周りも修正が必要になってくるだろ。

CSSだけで位置変更出来れば、本当に表示位置だけを変えられる。
バブルしてくるイベントはHTML通りにバブルしてくるから、見た目重なってもいない要素からもバブルしてくるようにも出来るんだが、
それだからこそ、同じプログラムで対応出来るんだよ。
違うのは人間からの見た目だけであって、プログラム上からの見た目は同じだから。

と、説明しても意味分からんと思うけど、多分やれば分かるよ。
「こんな手抜きの仕方があるのかよ！」みたいな事が結構出来たりするから。
典型的な例だと、HTML/CSSでは display:none （表示させないだけ、Formsで言う Control.Visible = false)を多用する。
勿論上記の通りFormsでも出来るけど、文化的にほぼ使われてないでしょ。（と俺は思っている）
ここら辺の手抜きの仕方がWeb系の方がこなれてる。
俺もそうだったが、,.NET界隈も真面目にプログラミングやりすぎてるんだよ。

「常に見えない設定の物を表示ルーチンに渡すのは無駄だ」というのは当たり前だけど、
それで別関数になるくらいなら、display:noneで同じ関数使おうぜ、ということ。
CSSの表現能力が高いからこれがかなり有効なんだよ。

2019/12/29(日) 20:05:42.44

かまうほうも頭おかしいんだけど自覚ないの

2019/12/29(日) 20:06:05.21

>>478
原理原則論としてはそうなのだろうけど、だから逆に使いにくくなってるんだよ。
多分これも、JavaScriptみたいに「自前でやらないと発火しない」フレームワークを使えば分かるよ。

君が既に両方使ったことがあって、
HTML/CSS/JavaScriptよりも.NETの方が使いやすいと判断しているのなら、それでいいが。

2019/12/29(日) 20:06:32.69

なんでxamlとhtmlの比較の典型例にformsがでてくんの？
xamlでもコントロールの非表示なんて日常茶飯事だと思うが

2019/12/29(日) 20:08:02.86

cssを採用したjava fxってどうなったんだろうね？

2019/12/29(日) 20:12:37.27

>>480
ん？Pythonについてなら君の言うとおり、
> ゲーム開発においてスクリプト言語が来る時代は来るかもしれんがそれはunityにはこんだろう
これについては納得したぞ。俺の負けでいい。

あのブログはもう2-3年前になるが、まあ、少なくともunityにはスクリプトは来ないね。
あれはC#と心中する、という決断だ。（逆に言えばC#は死なないとunityは判断してる）

2019/12/29(日) 20:20:44.20

差し支えなければどなたか>>464を…

2019/12/29(日) 20:21:07.58

>>481
> XAMLを弄って変更した場合、文書階層が変わるから、バブルしてくるイベントも経路が変わってしまうだろ。
WPFではイベントは直接使わないよ（使うこともできるけどあまりよろしくない）
モデル側でコマンドを定義してコントロールにバインドする
って言っても君にはちんぷんかんぷんかもね
まあ理解する気なさそうだから君はそのままでいいと思うよw

2019/12/29(日) 20:21:43.91

>>486
俺は複数の分野を横断的に知ってて各方面の弱いところをよく知ってる、だからマウントとれる、
と思ってるのかもしれないけど、職業プログラマだったらそんなの実務レベルで当たり前で、
むしろある分野を専門的にやってる人には勝てないなと思ってるからそんな大げさな物言いはしないんだけどね。
（〇〇の分野だと□□という概念があるんだけど、△△だとそういう概念はある？ぐらいに控えめに話題にする）

「C#信者」、「FORTRAN信者」だの、「Web系の馬鹿共」だの、「HTMLの良さがわからないのは君が知らないからだ」だの、
「説明しても意味わからんと思うけど」だの、よくもまあ自分以外を下に見る発言が沢山出てくるもんだ。
皆、あんたが偉そうに発言する割には、中身が誰でも思いつくことでしかも間違いが多いからツッコミを入れてるだけだぞ。それを「こいつはわからないから反論してきてるんだ」と思うようじゃ単なる天狗で自分の成長につながらないよ。
このスレでたった2日やりとりしたぐらいで、経験知識不足で頓珍漢な理屈を並べてると思われちゃってるんだから。

最終的に、実世界で相手されなくなって5chに書き込むしかなくなる悲しい人生になるぞ。

> 「今でもFORTRAN向けBLASの一つの実装がアップデートされている」
正直笑ってしまった。わかってないようだがOpenBLASはFORTRANのコードをコンパイルしてCから呼び出すんだよ。
FORTRAN専用のコードじゃない。CやFORTRANで呼び出せる共通バイナリをFORTRANで書いてるの。

2019/12/29(日) 20:23:58.98

>>484
そうなら第一段階は出来ていることになる。
でも本当にそうなら、もっとStyle側に押し込めればコードを減らせる＝XAMLのスタイルなんて非力すぎる、
というのも実感出来てるはずだけど。

>>485
俺についてはCSSを採用してることすら知らなかったな。
ただJavaのGUIはどうやっても死んでるだろ。

色々原因は言えると思うが、既に言ったとおり、Javaの変数管理がGUIに向いてないんだよ。
これはC#も同じで、よく騙して来れてる方だよ。

2019/12/29(日) 20:25:19.89

>>486
勝ちとか負けとかそんな話してないんですが…
俺が突っ込めるのは俺がわかる範囲だけだが、そういった浅い知識で何でも語る人間なら全ての話が適当なんだろうなとしか見えないね

2019/12/29(日) 20:25:25.54

>>484
たぶんID:EA/Onx+o0はWPFのことをFormsをXMLで記述できるようにしたもの程度の認識なんだろうと思う

2019/12/29(日) 20:33:25.70

>>488
> モデル側でコマンドを定義してコントロールにバインドする
そんなことになってんのかよ。
んー、まあ何か理由はあるんだろうけど、格好良すぎて余計に分かりにくくなってる気はするが。

まあいずれにしても俺の勉強不足はそのとおり。俺はWPFはやってないし、今すぐやれる準備もしてないからね。

>>489
だからそもそもマウント取りに来ていると考えているのが間違いなんだよ。
なんで一々そんなことしないといけないんだよ。

> FORTRAN専用のコードじゃない。CやFORTRANで呼び出せる共通バイナリをFORTRANで書いてるの。
おーマジか。知らんかったわ。というかFORTRANのバイナリなんて呼び出そうともしたこと無いし。
してOpenBLAS以外はFORTRANで書かれているのか？
Cじゃねえの？という気はするし、それ以前にアセンブラで書く気はするが。（勿論Cのインラインアセンブラな）

2019/12/29(日) 20:37:07.30

>>491
> 勝ちとか負けとかそんな話してないんですが…
メンドクセエ奴だな、じゃあどう言って欲しかったんだよ？

俺のことをどう見るかは君が決めることであって、俺がどうこう言っても意味無いだろ。
好きにすればいい。

2019/12/29(日) 20:44:08.21

>>494
適当な知識を撒き散らし嘘を広めるような言動をやめてほしかったんですよ

2019/12/29(日) 20:44:40.41

>>493
初めの主張を否定されたら「知らんかったわ。だけどこれはどうなの？」とか言って話をずらすのは、
気付いてないのかもしれないが、マウントを取る行為そのもの。
会話をしている相手への礼儀に欠いている。
少なくともFORTRANが現状では死んだ言語だという主張は間違いなわけだ。あんたが呼び出そうとしたこともないかどうかで事実が変わる訳でもない。
やったことない領域は分からないんだと謙虚な態度で考えることがエンジニアリングにおいても人間関係においても大事。
伝聞からの外挿で精度の悪い話を吹聴しても勝てないんだよ。相手は大抵人間じゃないか自分より能力や経験値が高いから。
日常が精度の悪い話で勝てる状況なら、正直その環境を見直した方がいいと思うぞ。低レベルな環境で過ごしてて、知識や技術は身につかないのに歳だけ取るということになるからね。
エンジニアリングを生業にしてないのなら、まあ、趣味の範囲で好きに生きるといいと思うよ。

2019/12/29(日) 20:52:25.70

>>496
マウント行為の重要なところが抜けてた。、他人を信者呼ばわりしたり、専門的にやってる人を「馬鹿共」と言ったり「分からないだろうけど」「知らないんだろうけれど」と決めつけたり、
なんの根拠もなしに他人を下に見て一方的な勝利宣言をするこれらの発言、マウント以外になんか理由があるのかい？

2019/12/29(日) 20:52:59.69

>>495
嘘は広めてないだろ。
俺は俺の見解を述べてるだけで、間違いはその都度認めてるつもりだが。
俺は広報しているのではなく、会話をしているだけだ。

紛らわしいから白黒正せ、というのがあれば、一々挙げてくれたら回答するが。
既に言ったがunityにはPython(というかスクリプト)は来ないだろう、というのは君の見解の方が正しいだろう。

2019/12/29(日) 21:03:21.41

>>498
広めるような、ね。
知識が無いのに明言してんじゃん
知識ある人がちょっと突っ込むだけで破綻するのになんで適当なこと言ったの？
知らないなら質問するだけにするか始めから触れなきゃ良いだけなのに

俺は突っ込めんがfortranもwpfも同じ流れじゃん
突っ込めない人間から見れば真実に見えかねない

2019/12/29(日) 21:08:15.64

ここの書き込み毎日凄いね。
ついてけね～
C++のめんどくさいから来たから有用な書き込み求むわ。

2019/12/29(日) 21:09:38.83

>>500
ここ質問スレのふらっとの隔離スレだから有用な書き込みなんか期待するのが間違い

2019/12/29(日) 21:15:40.85

>>496
> 少なくともFORTRANが現状では死んだ言語だという主張は間違いなわけだ。
そんなことはない。というかマジでこれは止めろ。

現状のHPCはどう見てもAI/MLであって、そこが環境を用意していない以上、死んだも同然だ。
君はCOBOLを現役だ、と言っているに等しい。(いや、アセンブラが現役だ、の方が近いか？)
若い研究者が今からFORTRANに賭けたらいきなり死ぬんだから、こんな事を言ってはいけない。
君こそ、
> 手続き型言語だったら考え方は大して変わらないからね。
というのならさっさとCに乗り換えるべきで、今の若手にはCを強制すべきだ。
まあ君がFORTRAN使いでカチンと来ているのは分かったが、しかしさすがに今の若手に
> FORTRANが主役 (>>459)
はマジで止めろ。
というか君の発言は「FORTRAN信者」と言われても全く文句言えないレベルだと思うが。

>>497
して
> と、説明しても意味分からんと思うけど、多分やれば分かるよ。 (>>481)
は馬鹿にしてないだろ。こんな説明では説明がイマイチで分からないのは当然だけど、やれば分かる、と言っているだけだ。
まあそれ以外は馬鹿にしているのも多々あるが、それは本当に馬鹿にすべきだからだよ。
例えば、「Web系の馬鹿共」、実際に行ってCSSのページとか見てみればいい。
そこじゃねえんだよ、ってところで頑張ってて、肝心のそこだよ、ってところが抜けてるんだよ。
だから本当にWeb系は玉石混淆（といえばよく聞こえるが、ほぼゴミ）なんだよ。
これは事実だし、実際Web系は馬鹿にされまくってるだろ。PHPerとか特に。
それは馬鹿にされるだけの理由が確かにあるんだよ。(これも本当に、見れば分かるよ。
なお俺はPHPerは過小評価されすぎで、むしろJavaScripterの方が問題だと思っている）
ただし上手いところは本当に上手くCSSを使い、
え？この関数しかないの？こんなんで出来るの？スゲー、みたいな構造になってたりする。
そういうところは勿論馬鹿にしてないし、するはずもない。

要は、馬鹿だから馬鹿にする、というだけの話で、それ以上でもそれ以下でもないし、
それが俺は匿名掲示板のいいところだと思っている。

2019/12/29(日) 21:23:23.75

>>499
> 突っ込めない人間から見れば真実に見えかねない
だから具体的にどれについてだ？
真実に見えかねないから全部訂正して回れ、というのなら、一々挙げろ。対応はする。

単に黙れ、というだけなら、お前が去れ。
ここは自由に意見を述べられる場所であって、それ以上でも以下でもない。
意見を自由に述べる以上、全部「正しい」なんて事にはならない。
というか、仮に全部「正しい」のであれば、そもそも議論が成立しない。

だから、俺の見解が間違っているというのなら、その意見を具体的に述べろと言っている。
そして必要なら俺は訂正する、とも言っている。
というのは>>498で述べたとおりの内容であって、お前が分からないようだから一端咀嚼したが、
無限ループするようならもう無視するから、その辺よろしく。

2019/12/29(日) 21:36:21.89

>>503
突っ込めない人間が居ない話題についてはどう訂正なんかするんだよって話だよ
君の無知からくる発言全てにその分野の知識ある人間からツッコミ入れさせるの？
始めから知らん内容を推測で発言すべきじゃないと言ってんの

間違ってるなら訂正してやるから教えろ
じゃなくて間違ってる可能性の高い内容を流布すんなって話
無闇に手を広げずに自分が話せる内容に留めておけ
知見を広げたいための会話ならそうなるようなレスをしろ

2019/12/29(日) 21:52:09.23

もー放っておけよ

こんだけデタラメ積み重ねてりゃ内容わからん人間でも
他人をディベートごっこに巻き込んでるだけで
なにひとつ言ってることが信用できないと既に印象付いてるから大丈夫だよ

1を聞いて-10を語るキチガイ相手じゃまともな方が何も得るもの無さすぎてかわいそうだわ

2019/12/29(日) 21:54:28.45

これ数日前にusingウゼーとかゴネてた人？w
なんかすごい執念だね
でも結局何が言いたいんだろうw

2019/12/29(日) 21:57:34.59

中身のない長文かけたら作文楽だったんだろうなあ

2019/12/29(日) 21:59:52.09

>>507
わかるw
作文教育なんてやめた方がいいねw
あんなの思ってもいないことを平気で書ける不誠実な人間を育てるだけだ

◆QZaw55cn4c (ﾜｯﾁｮｲ ea47-7AkR) · 2019/12/29(日) 22:20:16.44

>>508
そうそう、書くんだったら普通に英文和訳の方が力が伸びますね、そもそも嘘は書けないし

2019/12/29(日) 23:12:04.78

>>502
数値計算屋がFortranを捨てるべき３つの理由
(リンクがRock54で貼れないので、ググってくれ)

今でもこんな記事が書かれるほど、現場ではFORTRANが使われているということだろ。
自分はFORTRANはほとんど書いたことはないし、Cなんて当然のように使ってるし、人に教えるのならPythonだ。
(なぜ手続き型言語だとCなのかも謎だが)

FORTRAN使いとかいうのもお得意の決めつけなわけよ。

HPCはどう見てもAI/MLというのは、根拠がどこかにある話なのかな。よく知らないので否定しないので教えてくれ。HPCをどういう意味として使っているのかも教えてくれ。

2019/12/29(日) 23:13:45.21

>>502
「説明しても意味分からんと思うけど」
は、通常「説明しても（お前が馬鹿だから）意味が分からないと思うけど」と解釈される。馬鹿にする意図がないなら「この説明では伝わらないかもしれないが」のように書くべきだろう。
また、Web系が馬鹿にされるべき理由があろうとも、その理由が会話の内容と関係のないものなら無文脈に馬鹿にすべきじゃないだろう。
レッテル貼りして否定して回るのは紛れもないマウンティングなんだよ。
マウンティングする気がないのなら、発言の仕方に気をつけよう。端的に言ってあんたの発言は精度も態度も雑すぎて、聞き手に対して無礼極まりない。いくら内容が正しくても相手の機嫌を損ねてまともに聞いてもらえないぞ。
そんな奴は知に対して素直じゃない、とか思うかもしれないが、知に対して素直になりたいのなら、知以外の部分で余計なマイナスの修飾をすべきじゃない。
504とは違う意味になるが、「知見を広げたいための会話ならそうなるようなレスをしろ」というのはそのとおりだ。
中学生とかじゃなくてもういい大人なんだろうから、態度についてちょっとでも意見されたときに、脊髄反射的に否定するんじゃなくて、
一旦自分にそういうところは本当にあっただろうか、メタな視点で振り返ることができるようになろうよ。
それをした上で自分の行為はマウンティングじゃない、と客観的な言葉で説明できるのならそれはそれで良いからさ。

2019/12/30(月) 01:03:51.03

>>510
> HPCをどういう意味
HighPerformaceComputingだよ。普通に使われてる言葉だ。

> HPCはどう見てもAI/ML
むしろ今それ以外どこだと言うんだ？俺は君がここに疑問を持つことが疑問だが。

2019/12/30(月) 01:04:22.43

>>511
どうでもいいわ。ここはお前の日本語力の養成所ではない。
その後に「多分やれば分かるよ」と続けているのだから、
普通に読めばある程度相手の技術力に信頼を置いていることは明白だし、
仮にそれが君みたいに誤読してかってに切れられたとしてもマジで割とどうでもいい。
ついでに言うと、誤読でなく、実際に俺の人格が糞で切れていたとしても、どうでもいい。
マウンティングだと取りたければ取ればいい。
ただ、俺は君自身が「本当の議論」をしたことがないだけだと思う。

君が議論に人格を持ち込む奴なのは>>489が端的だし、それ以前から色々におわしていた。
君はリアルでもそういう議論『ごっこ』をして、反対意見を『年長者』という勢いで潰してきているのだろう。
が、そもそも俺は話者の人格なんて見てないし、興味もない。
そしていくら人格について言われても、意見を引っ込める気はない。
それとこれとは全く別だからだ。

俺はこのスタンスでずっと続けているが、繰り返すがそもそも俺は相手の人格になんて興味なく、
相手が技術的に糞だった場合はズタボロに言うものの、こちらが間違いなら普通に負けを認めてるから、
そもそも相手の技術力が高い場合にはさほど衝突しない。
だから俺はこれで全く問題ないし、ここではこのスタンスが最適だと経験的に結論づけてる。

当初は確かに俺も丁寧にやってたが、結局それだと馬鹿が図に乗るだけで収拾がつかなくなるだけだった。
馬鹿に優しいと、馬鹿にとっての楽園になってしまって、余計に馬鹿が集まる循環にしかならなかった。
だから馬鹿は叩かれるべきだし、当然俺が馬鹿だと思えば叩いて来ればいい。
そうして馬鹿はたたき出される、ということにしないと、匿名掲示板の健全さは保てない、と知った。
そしてお前らが技術的に叩けなくなったら「人格ガー」と言い出すのも理解している。

2019/12/30(月) 01:05:20.88

もう一度言う、「FORTRANが主流だ」(>>438)という嘘を平気でつくのは止めろ。
本当にそれは害悪だ。俺の人格云々ではなく、そっちの方が大問題だ。
これは見解の相違とかではなく、事実をねじ曲げてるレベルだからだ。

が、これ以上はどう見ても水掛け論だから、一応纏めておく。

君
・スーパーコンピュータで科学技術計算する分野では今でもFORTRANが主役(>>438)
理由はOpenBLASの実装がFORTRANで書かれているから(>>441)

俺
・FORTRANなんぞとっくに死んでる
理由は現在のHPCの主戦場であるAI/MLの中心に位置するCUDA/TensorFlow等に於いて
FORTRANはそもそもプロットフォームとして提供することすら議論されていない。
（ただしCUDAにはたまたま勝手ポートをした会社があり、それを買収して公式化されたので使えるが）

これをどちらが正しいと取るかは読者の判断だ。
技術的内容より人格だ、と思うのならそれでいいし、逆に、俺の人格は糞でも筋は通っている、と思うのも自由だ。

2019/12/30(月) 01:06:18.52

>>504
そもそもそのスタンスが間違ってるんだよ。
発言の自由があるということは、結果的に間違っている発言もある程度存在することを許容しないといけないし、
そもそもここは学校のように「正しい知識を教えてくれる場所」ではない。
勝手に各自が発言した内容を、自身で精査して、どれが正しそうかを君自身が掴み取らなければならない。
それに君が人格フィルターを使うのも自由だし、それ以外を使うのも自由だけど、
いずれにしても君自身が「精査」出来ないのなら、ここを使って「正しい」知識を得るのは無理だ。

俺は意図的に間違いを言っているつもりはない。
だから間違っていると思うなら突っ込んでくれればいいし、勿論ブッ叩いてくるのもありだし、放置ならそれでもいい。
ただ、「正しい発言しかするな」は「発言の自由」とは原理的に両立しないし、そもそも俺は一応「正しい」と思って発言している。
だから君の態度がナンセンスなんだよ。

あと、ここはディベートが出来る場所ではない。>>505
あくまでもパネルディスカッションであり、「この問題については俺はこう思う」以上のことは出来ない。
それで複数人から意見を聞いて、どれが正しいかを判断するのは読者自身だ。それは読者の責任であり、俺の責任ではない。
繰り返すが、俺は一応正しいと思って言っているし、同様に、間違いだと思うことには噛みついている。
それが俺の責任範囲であり、それ以上のことは出来ない。
各意見を並べた上で、どれを採るかを決めるのは、読者の判断であり、俺はそれに関与出来ない。
俺は人格者だからーみたいなことを言う気も毛頭無い。俺の発言を全て読んだ上で、君がどう判断するかは、君の自由だ。
この態度に徹しきれないのは、君たちが議論慣れしてないからだ。それは自覚した方がいい。

>>464,487
巻き込んで申し訳なかった。
ただ申し訳ないが、俺にはそれに答えられる知識がない。
タイミングが悪かったのはそちらの責任ではあるが、流し去ってしまったことについては謝っておく。

2019/12/30(月) 01:20:14.54

>>515
515の2行目を読んでから514の1行目読んでみなよｗ

常に正しい情報しか発信しないが理想論でしか無いのは当然
だからといって間違った情報を流布していい免罪符にはならない
間違ってないことが望ましいしそうなるように努めるべき

君のレスはどれも適当に言いくるめようと自身に都合の良いような情報を作っているように見える
事実unityで適当こいたしwpf周りも相当怪しい
fortranは俺にはさっぱりだがこの流れなら君の意見に対する信頼度は皆無

君は自分が正しいと思っていると言うがもう少し自身のハードルをあげたほうが良い
usingの頃からあらゆる方面についてさんざんツッコミを受けているんだから

2019/12/30(月) 02:05:00.30

>>516
何度も言っているが、君がそう判断するならそれでいい。

ただ俺はusingについても特段間違ってないつもりだけどな。
君らが間違っていると思うのも自由だが。
一応纏めておくと、

1. usnig書け。usingを忘れるとリークする。最速。
2. usnig書け。ただし書き忘れてもFinalizerで救済する。
　でもその分GCが複雑化して多少遅くなるから、要らないときにはSuppressFinalize呼んでね←今の.NET
3. using不要。ただしローカルにしか確保出来ない。最速。←俺はこれがいいと思う
4. usnig不要。メソッド内でGDI+リソースを確保/解放することにより完全に隠蔽。
　確保/解放分各メソッドは遅くなるが、絶対安全ではあるのでFinalizer不要になりGCは高速化する。
　結果的に速くなるか遅くなるかは未知数←423のツッコミ

俺は今でも3がいいと思うよ。ただ当たり前だが俺には決定権なんて無いから関係ないけど。
安全側に倒すのなら4だし、これも理屈的にはありだけど。
2なんて完全に泥縄的仕様で、美しくはないだろ。ただMSはこういうのも許容するところはあるが。
3はC的寿命設計が必要にはなるが、別段難しくないし、GCに慣れきってる奴でもやらせれば出来る範囲。
DIコンテナの先は知るか、でも、おそらく問題はない。
GDI+リソース周りはそのDIコンテナの先に入り、ユーザーが管理することにはならないはずだから。
4でFinalizerを外すにはfileリソース等含めて全面的にusingを撤廃する必要があり、多分すぐには無理。
各メソッドでGDI+だけ隠蔽するのは出来るが、それだと単純に遅くなるので、やるなら上記の通り足並み揃えて全面改訂だとは思う。

これでどう間違っているか言ってみ。
というか俺はお前が「俺が間違っている」ということにしたがっている理由が分からん。
俺が「全面的に間違っている」か「全面的に正しい」かで、この『人』は信じられる、この『人』は信じられない、にしたい？
ならそれは諦めろ。ここはこの『意見』は正しそう、この『意見』は間違ってそう、にしかならない。

unityについては公式見解を読む限り俺の「スクリプトが来る」予想は撤回であり、それ以上にも以下にもならんよ。
ただそれは君も分かっているとおり、unityには、でしかないよ。

2019/12/30(月) 02:17:14.52

>>516
> 515の2行目を読んでから514の1行目読んでみなよｗ
あ？ダブスタって話か？

なら俺は「分かり切っている嘘には噛みつく」という、君の言う
> 間違ってないことが望ましいしそうなるように努めるべき
をやってるだけだな。それでどっちが間違っているかを判断するのは君の責任だ。
さっぱりなら、「こういう事があった」ということだけ覚えていればいい。
そして後日、分かるようになったときに思い出したら、ああ、そういうことだったのか、でいい。

相手が言うことを止めることは無理だから、精々こちらは噛みつくことしか出来ない。
それで判断が保留されるのなら、それでも及第点ではある。
それが俺の精一杯だよ。

2019/12/30(月) 02:59:24.65

>>517
割り込んで申し訳ないけどusingについては結構奇妙なこと言ってると思うよw

まず、コンピュータのリソースには希少どころか物理デバイスみたいに排他的にしか
利用できないものもあるので、解放されるタイミングをプログラマが制御できないのは困ると思うよ。
非同期メソッドがあるC#ならなおさら「メソッドのスコープを抜けたら解放」なんてそんないい加減な話困っちゃうでしょw

次に、希少なリソースを握ってるオブジェクトだからってそれを戻り値にできないような言語、
普通は使いたくないのでは？その制約はどういう利益のための代償ですか？w

こういうの「倒錯」って言うんだと思うよw
強迫神経症ともいうねw
そもそも大して冗長でもないusuingを目障りだ、という問題意識が恐らく盛大に間違っているんだと思うけどw

2019/12/30(月) 05:35:58.11

Qiitaでやれ

2019/12/30(月) 07:15:03.12

>>512
AI/MLはHPC分野で新たにシェアが伸びた分野ではあると思うが、
今までの数値シミュレーションだって当然需要がなくなるわけもなく、HPC分野の大きな一ジャンルだろう。
"High Performance Computing (HPC) on Azure"というページをググって見てくれ。AI/MLとは別に項目になっているのだから、
AI/MLに食われるような存在ではないということだろう。
そして、根拠を示してくれと言ったのだがそこはスルーなのな。

その根拠を示さない限りは、
>>514の言説の仮定の一つとなっている、「HPCは科学技術計算ではなくAI/MLである」の正しさが検証できず、
HPCでFORTRANなんか使われてない、は示せない。AI/MLではFORTRANなんか使われてない、としか言ってないだろう。
事実を捻じ曲げている、というのなら、明確な根拠をどうぞ。

>>513
あんたの大層な論の細部がめちゃくちゃだからツッコミを入れると、「信者」だの「知らないだけ」だの言って
ズレた反応を示しながら相手の発言と自分の知識の間違ったところのすり合わせをしないから「人格に問題がある」って言ってるんだよ。
端的に言うと、「馬鹿って言ってるけどお前のほうが〇〇の理由で馬鹿だぞ」と言われたときに、「〇〇は果たして間違っていただろうか？」と考えず、
「いや、やっぱりお前のほうが馬鹿」ってのを繰り返してるんだよ。思い込みを指摘されて、根拠はあるの？と言われてもまだ思い込みで返してくる。
少なくとも調べなおそうよ。
もう、技術的にあんたの経験不足、知識不足を指摘するのは諦めてるんだけど、あんたは人を馬鹿にできるほど経験も知識もない。
WindowsのGUIアプリはなんでもかんでもブラウザベースでOK、とか、インターネットにつながってない環境は考慮する必要ない、とか、
そりゃそういう世界もあって良いけど、そうじゃない世界もあって、そこでは通用しない考え方なんだよ。
自分の考えが通用しないからって、「そんな世界はない」と言ってるようだけれども、事実そんな世界はあるんだよ。
仕事でそんな世界にアプリを納品する必要があったら、ブラウザベースじゃないGUIアプリを作るとか、
インターネットに繋がってなくても当然のように使える開発プラットフォームを使うとか、別の方法をとるまでだ。
ちなみにSIerではないからね。設計から実装まで任されててもたまにそういうところはある。
そんなときにあんただったらどうするんだい？「こんな馬鹿な環境では仕事してらんないから辞めてやる！」のか？

2019/12/30(月) 09:16:55.19

年末に何やってんだ君たち暇なの？
家族や友人とは交流しないの？

2019/12/30(月) 09:58:05.51

中途半端な知識で何とか丸め込もう、話を付け替えて何とかしようとするから長文になる
わかってる人は、核心付くだけで済むから短文で済む

長くコンピュータに関わってたら、それぞれ皆わかってる程度の内容を書き連ねて暇だね～
えっ！？君園児？それなら凄いわ

2019/12/30(月) 10:14:08.57

何でもブラウザでできる時代になる論は20年前にも10年前にあったw

これ数年前にも書いたけど、そういうドリーマーにGMailやOutllook.comのUIが
どう見えているのか興味はあるねw

何年たってもどっか使いづらいままだよねw
UIの使い辛さ以上の利便性があるから使われているだけのことで

2019/12/30(月) 10:31:39.03

outlookのWebUIは最近の365だと割とまともじゃないか？
使えない機能が多いのは確かに考えもんだけど。

2019/12/30(月) 10:36:33.41

今のOutlookのUIってクライアント版もかなりWeb寄りになってるから、その気になればWebベースでも十分再現できそう
プログラマにとって最も馴染みの深いツールの一つであるテキストエディタがVSCodeでWebベースになった時点で、もう言い訳はきかんよ

2019/12/30(月) 17:39:30.58

using はユージングって読む人が多いけど、ついウシングって読んでしまう。VBのときのストラコンブとかと同じような感覚で

2019/12/30(月) 17:49:06.40

その読み方はした事ないけど自分の中で使っちゃうやつってのはあるね
charは脳内だといつもチャー読みだわ

2019/12/30(月) 19:59:49.22

気絶するほど悩ましいな

**デフォルトの名無しさん** (ｽﾌｯ Sd94-hoej) · 2019/12/30(月) 20:29:05.94

char は敢えてシャアと読むべきだね
https://marycore.jp/programmer/char-aznable-type/

2019/12/30(月) 20:43:25.72

>>521
いやもうお前はいいよ。
前半はどういう論理でどう白黒つけたいのかさっぱり分からんし、後半は要するに俺への文句だろ。

君の中では俺は糞という結論が出ているのだし、それでいい。
それを周りの人がどう取るかも含めて読者の自由だ。
俺は技術論しかする気ないんだよ。

一応OpenBLAS見てみたんだが、やっぱFORTRANが生きているとは言い難いぞ。
アーキ毎に高速化されてる奴はkernelの中に入っているが、アセンブラとCしかない。
高速化されてない奴は確かにFORTRANの実装を呼んでるっぽいので、
実際に呼ばれるFORTRAN/C/アセンブラの割合がどれくらいかと、
最近他にFORTRANで改訂された物がどれくらいあるかだね。
つってもBLASの作りだと、単なる(FORTRANで書かれた）アセンブラライブラリでしかない。
現役だというのならまずその上位コードがFORTRANで書かれてないといけない。

2019/12/30(月) 20:43:49.47

なお論調がまた勘違いして読み間違っているようだからもう一度はっきり言っておくと、
俺は君の意見なんて全く認めてないし、FORTRANは死んでると今も認識してる。
そしてお前は本当に議論が出来ないようだが、お前が今やるべきは、
A. 俺の『意見』を否定することにより、俺の『意見』を無効化する
B. 俺の『人格』を否定することにより、ここの人格重視の馬鹿C#er共と一緒に喚き立てて俺の発言全てを無効化したことにする
ではなくて、
C. 君の意見を補強する材料を提示して、俺の意見を木っ端微塵にする
なんだよ。お前みたいな議論が出来ない馬鹿はAやBにこだわるのが常だけど、
それだと、-1が0にしかならず、結果、その議論は何も得る物が無く、結論も出ない。
そうではなく、やるべきはCであって、+10とかぶっちぎってしまうことであり、
それが出来れば俺が-20とか出さないと勝てなくなるんだよ。
議論は足の引っ張り合いではなく、突っ張りあいをやるべきなんだよ。

お前は最新のプラットフォームで相手にもされてないのがどれだけのことなのか理解出来ないのか？
そしてこれを越える材料を持って来いと言ってるんだよ。

なおお前が実際にFORTRANでスパコン使いまくってる、というのなら俺にブチ切れるのも分かるが、
そうでないと言うのだから、ここにこだわる理由も分からんがな。
そして材料が無いなら、蒸し返そうが何しようがそれ以上話は進みようがないだろ。
「FORTRANが主役」「FORTRANはもう死んでる」で読者に判断を委ねるで済ませられない理由は？

> 別に項目になっているのだから、
> AI/MLに食われるような存在ではないということだろう。
お前はそもそも「スパコン」が何か理解出来てないようだが、何故ここまでこだわる？

◆QZaw55cn4c (ﾜｯﾁｮｲ ea47-7AkR) · 2019/12/30(月) 20:47:34.21

「FORTRAN」「求人」でたくさん引っかかるのですが
本当に FORTRAN は死んだのでしょうか？

2019/12/30(月) 20:57:59.29

>>533
お前にレスするのは不本意だが、なかなか良いツッコミだ。
が、俺は
> あれはスパコンのCOBOL扱いになってるはずだが。
> （もしかしてベクトルはFORTRANしか受け付けないのかな？これはあり得るが） (>>439)
と既に言ってるだろ。

COBOLなら求人があるのは分かるよな？そういうことだ。
http://labs.timedia.co.jp/2017/06/gnufortran.html

2019/12/30(月) 21:35:10.50

最新、トップシェア以外のものは死んでるという前提の理論はいらん

2019/12/30(月) 21:44:50.82

いやスパコン言ってるなら既に出されてる京のpdfを否定する資料をまず出せば？
相手にされてないってものCUDA Fortranで自分で否定してるし

なんか対等にやりあってる風を装ってるけど
既に木っ端微塵されたところから全然建て直しできてねえぞ？

2019/12/30(月) 22:05:30.33

>>527
ウンチングが正解
これ以外で読んだやつを信用してはならない

2019/12/30(月) 22:13:55.24

まあFORTRANの話はいずれにしてもスレチだし、俺も終わりでいい。

ただお前らが思っている世界とスパコン界隈は全然状況が違うが、
それにしても興味もないだろうし、お前らに俺が間違っているとされても俺は問題ないので。
ただ、俺の話を少しでも信じる気があれば、
「FORTRANなんて既に死んでる」と言っていた奴が居たことを頭に留めておいて欲しい。
そしてもしなにか機会が発生したら、その時に俺が言っていたことを吟味してくれればいい。
それだけで、だいぶ違うはずだから。

2019/12/30(月) 22:16:46.91

>>519
そう思うならそれでよし。
君は今の.NETの実装、つまり俺の纏めた 2 が妥当だと思ってるんだろ？
ならそう言えばいいだけ。
余分な人格評価とかすると（一般的には)君の評判自体も落ちると思うぜ。
そこも含めて自由にすればいいとも思うが。

> そもそも大して冗長でもないusuingを目障りだ、という問題意識が恐らく盛大に間違っている
これはちょっと違ってな、というか俺も以前は今の君のように何も考えずに「書くものだ」で書いてたんだけど、
それだと「書ける人」にしかならないんだよ。
ただの1行、ただの1ステートメントですら、
「本当にこれ必要なのか？無くすことは出来ないのか？」と考えないと、本当に余分のないコードにはならない。
ジョブスがやってた、「ボタンは一つにしろ」と同じだよ。
コードは、書くよりも、削る方が難しいし、削るときに腕前は上達する。
というのは以下のどこかにあったはずだが、出てこない。が、まあ、実感としてこれは当たってる。
https://xn--97-273ae6a4irb6e2hsoiozc2g4b8082p.com/

ググってたら出てきたからついでに
何事においても、完璧に到達するのは、付け加えるものが何もなくなったときではなく、削るものが何もなくなったときである。（アントワーヌ・ド・サン＝テグジュペリ）

2019/12/30(月) 22:21:24.79

>>524
どっちが優れていたとしても、優れていた方がパクられて、最終的に同じUIになるのは確実だろ。
区別する意味ないと思うが。

ただ俺が言っているのは、君が勝手に想像しているそれではない。
俺は単に、
・HTMLの方がUIが作りやすい
と言っている。

例えば00年代初頭にはJavaでクライアントアプリを作って配布することもあった(と聞く)勤怠アプリ、
今ではWebアプリ一択だろ。これには、君らは
1. デプロイの手間がない
2. 鯖にデータが勝手に溜まる
だけだと思っているのだろうけど、俺は、
3. GUIを作るのが楽
がでかいと思っている。
そしてそれがデスクトップに出てきたのがelectronだ。当然1,2の利点はなく、3だけで勝負してる。

ならなんでUIが糞なのさ、というのは言ってしまえばWeb系のデザイナのセンスが糞だからだろ。
フラットデザインが糞なのは、マルチデバイス優先で手抜きされてるからのようだが。
> しかし、もっとも大きな理由は「マルチデバイスへの対応に最適だから」と言えます。
https://webbu.jp/flatdesign-2762

2019/12/30(月) 22:44:33.73

散々中立ぶっててこの未練がましさはさすがに草
無能さをさも自分がニュートラルであると振る舞って誤魔化す手合いだな
もうちっとまともな化けの皮を被れ

2019/12/30(月) 23:05:34.31

コンピュータ関係者向けの漫談ぶっこんで、盛大に白けて終わったな

2019/12/30(月) 23:16:18.62

>>541
メンドクセエ奴だな。
TensorFlowは既に言ったろ。>>445
ついでにTPUも確認してみた。>>456

TensorFlow: Python,/C/Java,/Go
TPU: Python/JavaScript/C++/Java/Go/Swift、これらは公式サポート
C#/Haskell/Julia/Ruby/Rust/Scala、これらはコミュニティサポート

喜べ、C#はTPUを使える。TensorFlowSharpとTensorFlow.NETだとさ。
https://www.tensorflow.org/versions/r1.14/api_docs/

2019/12/30(月) 23:20:33.54

ヤーッホーフォートランランラン
ヤーッホーフォートランランラン
て歌ってたな。
30年前だけど。

2019/12/30(月) 23:50:47.66

やっぱり終わらない笑
そしてまた持論の範囲を狭めて説得力ごと削ってゆくスタイルはもはや芸人である

2019/12/31(火) 02:01:20.46

ガイジの群れ

2019/12/31(火) 02:52:44.77

おまえらいい加減にしないとpythonいっちゃうぞ？

◆QZaw55cn4c (ﾜｯﾁｮｲ ea47-7AkR) · 2019/12/31(火) 15:54:10.80

>>534
褒めていただき光栄です！

＞お前にレスするのは不本意だが、
そういわずに、私もよいコメントを出そうと常に思っていますので今後ともよろしくお願いいたします

2019/12/31(火) 19:20:27.09

>>524
補足。

WPFは糞だが、これは『現在の』HTMLと比べるからであって、
WPFが登場/仕様検討された頃のHTMLと比べればましだと思うよ。
だからMSが間違ったとか技術不足ではなくて、単に、進化の速度が遅いだけ。
それはMSも分かっていて.NETもアーリーリリースに切り替えたけど、それにはお前らは不満たらたらなんだろ？
なおWebの状況は「仕様に採用された！やったぜ！」とか騒いでいたから
（数ヶ月後に）使おうと思ったら未実装で使えないとか、
或いは新規機能もバグってて使い物にならないとか、普通にある。たぶん.NETの方がまだましなんじゃないかな。
ただ、何だかんだで仕様が決まってさえすれば次第に実装はされるから、結果的な進化速度は早くなる。
おかげでWeb系は「この機能は使っていい、これは駄目」みたいな全く無駄な努力を常に強いられる糞環境なものも事実だけど。

でもこの構造だと一度抜かされたら二度と追いつけないんだよ。で、今もうそうなってると思うよ。
そしてWeb系もそんなに勤勉なわけでもないから、WPFを勉強してまでデスクトップアプリを作ろうとはしない。
それは君らがHTMLを勉強してまでWebアプリを作ろうとはしないのと同じように。
だから結果的に分断されていたわけだが、垣根はなくなりつつあるし、そこまで余裕かませる理由が分からんけどね。
C#でちゃんと『プログラミングが出来る』のなら、JavaScriptの修得自体は容易なのは事実だけど、
『.NETを知っているだけ』ならほぼゼロからやり直しだよ。
とはいえ個人的には、既に言ったがPHPerは馬鹿にされすぎてるが実はそこそこ実力はあり、
調子に乗りすぎてるのはJavaScripterで「お前らがやってるのはプログラミングではなく塗り絵だ」のレベルが多いから、
C#erが大量流入して皆殺しにして欲しいのだけど。

2019/12/31(火) 19:21:12.67

ただ逆に言えば、そんな馬鹿ばっかでも何とかなってしまうのがWeb系『フレームワーク』の実力で、
それは構造的に三層WebでMVC縛りだとか、
CSSの自由度が高くてVとCもほぼ分離出来るとか、
元々GUI向きなJavaScriptを使っているとか、そういうところなんだよ。(これらは既に言ったが)
最後のところはC#を使っている限り埋まらない。
今まで規模が3倍強のJavaに飲み込まれず、むしろ善戦してること自体が驚異的ではあるのだけど、
JavaScriptとは「異種格闘技」を強いられてしまうし、HTMLフレームワークは実はPHP+JavaScriptで4倍規模だから、
それも跳ね返していけるか、となると、正直きついだろうというのが俺の予想だね。

Web系なんてC#やJavaで「ちゃんと」設計出来てる人から見たら全てゴミだけど、
そのゴミでも何とかなっているというのがミソで、
MSはちょっと技術力が高すぎて、ユーザーに精度（技術力）を求めすぎているんだよ。
フレームワークを細かく整備していけば、勿論最終的な生産性は上がるのだけど、
当たり前だがそのフレームワークについて正確に知っていること,、正しく使うこと、という精度を要求してしまう。
結果、デタラメに仕様追加され、デタラメなコードになっていたときの劣化具合が余計に激しくなってしまう。
そこはMSが想定する「常識レベル」の技術者なら上手くリファクタ出来るレベルに留めているはずなのだけど、
それが(MS自体に馬鹿が少ないから）結果的に高めになってる。
ここら辺のズレが致命傷になると思う。(要は、.NETはニワカが使うには難しすぎる）

逆にWeb系は「生き残ってる物が正義」みたいな状況になってるから、結果的にずれることがない。
PHPなんて中級者に成りたて＝とりあえず一通りは出来るようになった！
みたいな馬鹿が書いたような仕様ばかりなので、いらつくしムカつくんだけど、
当然だが、そのレベルの人達にはそれが本当に心地よいんだよ。
だからそのレベルホイホイになっているところはあって、結果的に新規参入者が絶えない。
これも広い意味で言えばPHPの実力なんだよ。
ただし言語としてはかなり最悪の部類であるのも事実だが。

2019/12/31(火) 19:40:51.62

>>548
君は多分狙いすぎてるんだよ。

投稿自体の切れ味は割といいと思うんだけど、『常に』ムカつくタイミングで出てくるから、
イラッとするし、そういうことを狙っている（そういうことしかしない）のだと取られてしまう。
また、大体は議論が紛糾している時であって、
レス付けたら余計に話がおかしくなるから無視するしかない、
みたいなタイミングで『しか』出て来ないのもどうにかしろとは思うよ。
話をしたいのなら、普通に話に混ざった方がいい。
いや俺はツッコミ専門だ、話なんてする気無い、というのならそれも自由だが、それだと今後とも嫌われると思うよ。

ただ俺は君の空気を読まないスタンスは素晴らしいと思う。
そもそもここではネットならではの議論をすべきであって、それは
「ここで突っ込んだら相手の面子丸つぶれだな…でも明らかに間違いだしな…」みたいなところで躊躇する必要がまるでないことであって、
馬鹿がよくやってる罵倒合戦ではないんだよ。
君はこれは完全に出来てて議論慣れしてるところはいいと思うよ。
ただ繰り返すが、話をする気があるのなら、出てくるタイミングが酷すぎる。

2019/12/31(火) 21:01:44.58

長ったらしい説明は要点がボケる傾向にある。

2019/12/31(火) 21:07:56.98

もうあんたら、学歴ジャンケンでどっちが頭がいいのか決着をつけたらどうだ？
それかQiitaに行けよ

2019/12/31(火) 21:25:28.17

長文連投キチガイの法則はデスノートなみに正確だということ

2019/12/31(火) 23:51:30.11

今年最後にあぼーんで埋まってゆく…

2020/01/01(水) 00:38:31.16

そういえば、なぜJavaScriptに初心者が魅了されるのかというと、
コンパイラがなくてもすぐに始められるために、初めて触る言語が
それであることが多く、それに慣れてしまっているからではないかと思う。

しかし、Promise(とasync)の辺りとか、イベントのキャプチャーフレーズ、
ターゲットフレーズ、バブリングフェーズの違いや preventDefault や
stopPropagation を正しく理解するのはかなり難しい。

PromiseとResponceに、ServiceWorkerと responseWith、waitUntil
などの辺りなどは、ちゃんとした仕様が書いてあるサイトを見つけるのすら
難しい。

2020/01/01(水) 00:43:43.30

>>549
なぜ、HTMLアプリが増大しているかの理由については以下も参考になる。
OSとみなした場合に、WindowsやAndoridに比べてシェアが圧倒的に大きいからと考えられるそうだ：

【Wasm】ブラウザをOSとみなすとシェアはTOP
https://medaka.5ch.net/test/read.cgi/prog/1576520355/

2020/01/01(水) 13:50:13.63

>>556
それもあるが、敷居が低いのは「インタプリタがある」からだよ。PHPもこれがデカい。
C#もあるにはあるようだけど、構造的に本物と全く同一動作というわけには行かないだろうから、ここも本質的に敷居が高くなってる。
https://ufcpp.net/study/csharp/cheatsheet/apscripting/
だたまあ、ある程度慣れれば「インタプリタでのデバッグなんて効率悪すぎ」で使わないのも事実だが。
この意味だとC#やJavaはプロ仕様で、いわゆるスクリプト言語は「アマ向け」なんだけど、
国民総プログラマ時代（俺はこれには大反対だけど）には敷居が低い言語の方が向いているんだよ。

JavaScriptは以前は環境が要らない、というのが大きかったけど、
スマホだと開発者ツールがついてないから以前のようにF12を押すだけ、とは行かない。
一応C#はコンパイラはWindows同梱だし(csc.exe)、ここについては形式的には完了してる。
ただ、HTMLは見た目のインパクトが大きい。例えば、
<img src="xxxx" style="position:fixed">
だけで画像がポップアップする。これは俺には「たったこれだけ？」と衝撃だった。
同様に、他言語/環境から入ったらその簡単さに衝撃を受ける。それくらい簡単さが違う。

2020/01/01(水) 13:50:36.93

Promiseは俺に言わせれば完全な糞仕様で、あれは入れるべきではなかった。
C#でasync/awaitだけで問題ないのが分かっていたのに、止めることも出来ず、
今でも「あれがないとasyncが理解出来ない(ｷﾘｯ」と嘯いて正当化してるわけだが。
JavaScriptは本当に仕様委員会自体が糞で、仕様に政治を持ち込んだりもしてる。（httpSでしか使えない新仕様とかある）
完全に自殺中だ、というのが俺の見方だ。

ただそもそもPromise自体は「非同期を無理に同期的に組む」時に必要なものであって、組み方で回避出来る。
JavaScripterは非同期を極めているつもりの奴が多いが、
JSのは上手く色々省けるようにした「なんちゃって非同期」でしかなく、（これ自体は素晴らしいことだし、大成功だが）
連中はガチの非同期を知らないから、ここら辺を何度説明しても理解出来ない。
まあいずれにしても、ヘルズバーグも「でもPromiseはねーわ」だったし、俺はC#の判断の方が断然正しいと思う。

イベントバブルについては、理解すること自体は簡単だが、
それを上手く利用した構造を作ることは「ちゃんと設計する能力」が必要になる。（そんなに難しくもないと思うが、慣れは必要）
ただ、そこを何も考えない作りの時に威力を発揮するのがjQueryであり、
要はForms同様各GUIコンポーネントにイベントを一々付けていくわけであるが、
これをやってて、そしてまた、それでも問題ない事が多いのもまた事実だよ。
なおこれはWebページのみならず、一般のGUIもそう。
だから.NETはちょっと格好いいところを目指しすぎてて敷居が上がっている、とは思う。
といってもこれはWPFでも技術的には出来ることではあるから、コミュニティ的なもの、
つまりいまだにjQueryみたいな糞を使っていても大して文句を言われない、というところの違いかも。

JavaScriptは一部から生理的に拒絶されていたりするのでelectronも直接の驚異にはならないかもしれない。
パンドラの箱が開くのは、PythonがJS並の速度を持ったときだとは思う。

2020/01/01(水) 20:06:48.58

>>464
コンバーターって、ValueConverterのことだよね？
StaticResourceとして定義すれば行けるはずだけど。
xamlを貼ってみると、回答しやすいんではないかな。みんな。

2020/01/02(木) 12:00:38.14

>>559
無茶苦茶だな
C#のasync/awaitはTaskがベースでpromiseとほぼ同じだ
そしてJavaScriptにもMS主導でasync/awaitが導入済み

2020/01/02(木) 19:11:21.24

>>561
そりゃTaskも最早ゴミだからだよ。
実際「asyncと書いておけば、後は小さいオッサンが何とかしてくれる」程度の理解で問題ないように出来てるだろ。
C#1.0からasyncだったら神だったろうよ。
そして俺はお前らの「今はもう要らない」仕様についても崇拝を続ける姿勢を信者だと揶揄してるんだよ。

ただJavaSriptのasync/awaitはMS主導なのか？だったらPromiseにこだわるのは政治か。
JavaScriptの仕様委員会は本当にどうしようもないな。

2020/01/02(木) 19:24:07.49

>>562
アホか
C#のasync/awaitがTaskのシンタックスシュガーであるのと同様に、
JavaScriptのasync/awaitもPromiseのシンタックスシュガーに他ならない
そして、あなたが敵視している「JavaScriptの仕様委員会」において仕様策定をリードしているのは紛れもなくMSであり、
あなたの敬愛するヘルスバーグもいわばJavaScriptのパイロット版ともいえるTypeScriptの開発を通じて関わっている

2020/01/02(木) 19:34:18.12

古い技術より新しい技術のほうが優れてるから最初からそっちだったらいいのに、なんて言うのは誰でもできるわな
それと非同期処理はasync/awaitが覇権を握ったけど並列処理でまだまだTaskが現役だぞ

2020/01/02(木) 19:52:10.23

Taskイラネって、WaitAllみたいなユースケースは頭にないんだろうな
障害児はプログラミングなんかしなくていいんだぜ
迷惑だからな
新海面処分場に自主的に向かってくれや生ゴミ