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

■ このスレッドは過去ログ倉庫に格納されています
2017/10/17(火) 00:41:22.60ID:JxIRdCj70
■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
508デフォルトの名無しさん (ｱｳｱｳｳｰ Sab5-655U)
垢版 |
2019/12/29(日) 21:59:52.09ID:axIq/xVYa
>>507
わかるw
作文教育なんてやめた方がいいねw
あんなの思ってもいないことを平気で書ける不誠実な人間を育てるだけだ
2019/12/29(日) 22:20:16.44ID:yqbBnK7b0
>>508
そうそう、書くんだったら普通に英文和訳の方が力が伸びますね、そもそも嘘は書けないし
510デフォルトの名無しさん (ﾜｯﾁｮｲ 4697-esi/)
垢版 |
2019/12/29(日) 23:12:04.78ID:ecPco4090
>>502
数値計算屋がFortranを捨てるべき３つの理由
(リンクがRock54で貼れないので、ググってくれ)

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

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

HPCはどう見てもAI/MLというのは、根拠がどこかにある話なのかな。よく知らないので否定しないので教えてくれ。HPCをどういう意味として使っているのかも教えてくれ。
511デフォルトの名無しさん (ﾜｯﾁｮｲ 4697-esi/)
垢版 |
2019/12/29(日) 23:13:45.21ID:ecPco4090
>>502
「説明しても意味分からんと思うけど」
は、通常「説明しても（お前が馬鹿だから）意味が分からないと思うけど」と解釈される。馬鹿にする意図がないなら「この説明では伝わらないかもしれないが」のように書くべきだろう。
また、Web系が馬鹿にされるべき理由があろうとも、その理由が会話の内容と関係のないものなら無文脈に馬鹿にすべきじゃないだろう。
レッテル貼りして否定して回るのは紛れもないマウンティングなんだよ。
マウンティングする気がないのなら、発言の仕方に気をつけよう。端的に言ってあんたの発言は精度も態度も雑すぎて、聞き手に対して無礼極まりない。いくら内容が正しくても相手の機嫌を損ねてまともに聞いてもらえないぞ。
そんな奴は知に対して素直じゃない、とか思うかもしれないが、知に対して素直になりたいのなら、知以外の部分で余計なマイナスの修飾をすべきじゃない。
504とは違う意味になるが、「知見を広げたいための会話ならそうなるようなレスをしろ」というのはそのとおりだ。
中学生とかじゃなくてもういい大人なんだろうから、態度についてちょっとでも意見されたときに、脊髄反射的に否定するんじゃなくて、
一旦自分にそういうところは本当にあっただろうか、メタな視点で振り返ることができるようになろうよ。
それをした上で自分の行為はマウンティングじゃない、と客観的な言葉で説明できるのならそれはそれで良いからさ。
2019/12/30(月) 01:03:51.03ID:y1laSdPm0
>>510
> HPCをどういう意味
HighPerformaceComputingだよ。普通に使われてる言葉だ。

> HPCはどう見てもAI/ML
むしろ今それ以外どこだと言うんだ？俺は君がここに疑問を持つことが疑問だが。
2019/12/30(月) 01:04:22.43ID:y1laSdPm0
>>511
どうでもいいわ。ここはお前の日本語力の養成所ではない。
その後に「多分やれば分かるよ」と続けているのだから、
普通に読めばある程度相手の技術力に信頼を置いていることは明白だし、
仮にそれが君みたいに誤読してかってに切れられたとしてもマジで割とどうでもいい。
ついでに言うと、誤読でなく、実際に俺の人格が糞で切れていたとしても、どうでもいい。
マウンティングだと取りたければ取ればいい。
ただ、俺は君自身が「本当の議論」をしたことがないだけだと思う。

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

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

当初は確かに俺も丁寧にやってたが、結局それだと馬鹿が図に乗るだけで収拾がつかなくなるだけだった。
馬鹿に優しいと、馬鹿にとっての楽園になってしまって、余計に馬鹿が集まる循環にしかならなかった。
だから馬鹿は叩かれるべきだし、当然俺が馬鹿だと思えば叩いて来ればいい。
そうして馬鹿はたたき出される、ということにしないと、匿名掲示板の健全さは保てない、と知った。
そしてお前らが技術的に叩けなくなったら「人格ガー」と言い出すのも理解している。
2019/12/30(月) 01:05:20.88ID:y1laSdPm0
もう一度言う、「FORTRANが主流だ」(>>438)という嘘を平気でつくのは止めろ。
本当にそれは害悪だ。俺の人格云々ではなく、そっちの方が大問題だ。
これは見解の相違とかではなく、事実をねじ曲げてるレベルだからだ。


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

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

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

これをどちらが正しいと取るかは読者の判断だ。
技術的内容より人格だ、と思うのならそれでいいし、逆に、俺の人格は糞でも筋は通っている、と思うのも自由だ。
2019/12/30(月) 01:06:18.52ID:y1laSdPm0
>>504
そもそもそのスタンスが間違ってるんだよ。
発言の自由があるということは、結果的に間違っている発言もある程度存在することを許容しないといけないし、
そもそもここは学校のように「正しい知識を教えてくれる場所」ではない。
勝手に各自が発言した内容を、自身で精査して、どれが正しそうかを君自身が掴み取らなければならない。
それに君が人格フィルターを使うのも自由だし、それ以外を使うのも自由だけど、
いずれにしても君自身が「精査」出来ないのなら、ここを使って「正しい」知識を得るのは無理だ。

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

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


>>464,487
巻き込んで申し訳なかった。
ただ申し訳ないが、俺にはそれに答えられる知識がない。
タイミングが悪かったのはそちらの責任ではあるが、流し去ってしまったことについては謝っておく。
2019/12/30(月) 01:20:14.54ID:oG91u3Zf0
>>515
515の2行目を読んでから514の1行目読んでみなよｗ

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

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

君は自分が正しいと思っていると言うがもう少し自身のハードルをあげたほうが良い
usingの頃からあらゆる方面についてさんざんツッコミを受けているんだから
2019/12/30(月) 02:05:00.30ID:y1laSdPm0
>>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.52ID:y1laSdPm0
>>516
> 515の2行目を読んでから514の1行目読んでみなよｗ
あ？ダブスタって話か？

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

相手が言うことを止めることは無理だから、精々こちらは噛みつくことしか出来ない。
それで判断が保留されるのなら、それでも及第点ではある。
それが俺の精一杯だよ。
519デフォルトの名無しさん (ｱｳｱｳｳｰ Sab5-655U)
垢版 |
2019/12/30(月) 02:59:24.65ID:IsEWodDca
>>517
割り込んで申し訳ないけどusingについては結構奇妙なこと言ってると思うよw

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

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

こういうの「倒錯」って言うんだと思うよw
強迫神経症ともいうねw
そもそも大して冗長でもないusuingを目障りだ、という問題意識が恐らく盛大に間違っているんだと思うけどw
520デフォルトの名無しさん (ﾜｯﾁｮｲ f12d-vQnI)
垢版 |
2019/12/30(月) 05:35:58.11ID:TxCLIlob0
Qiitaでやれ
521デフォルトの名無しさん (ﾜｯﾁｮｲ 4697-esi/)
垢版 |
2019/12/30(月) 07:15:03.12ID:tsk9MmEe0
>>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.19ID:bS1/9EJkM
年末に何やってんだ君たち暇なの？
家族や友人とは交流しないの？
2019/12/30(月) 09:58:05.51ID:EEF4A29R0
中途半端な知識で何とか丸め込もう、話を付け替えて何とかしようとするから長文になる
わかってる人は、核心付くだけで済むから短文で済む

長くコンピュータに関わってたら、それぞれ皆わかってる程度の内容を書き連ねて暇だね〜
えっ！？ 君園児？ それなら凄いわ
524デフォルトの名無しさん (ｱｳｱｳｳｰ Sab5-655U)
垢版 |
2019/12/30(月) 10:14:08.57ID:enwINxmVa
何でもブラウザでできる時代になる論は20年前にも10年前にあったw

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

何年たってもどっか使いづらいままだよねw
UIの使い辛さ以上の利便性があるから使われているだけのことで
2019/12/30(月) 10:31:39.03ID:duSdEw3c0
outlookのWebUIは最近の365だと割とまともじゃないか？
使えない機能が多いのは確かに考えもんだけど。
2019/12/30(月) 10:36:33.41ID:5236BLqUa
今のOutlookのUIってクライアント版もかなりWeb寄りになってるから、その気になればWebベースでも十分再現できそう
プログラマにとって最も馴染みの深いツールの一つであるテキストエディタがVSCodeでWebベースになった時点で、もう言い訳はきかんよ
2019/12/30(月) 17:39:30.58ID:sCWLu8Vm0
using はユージングって読む人が多いけど、ついウシングって読んでしまう。VBのときのストラコンブとかと同じような感覚で
2019/12/30(月) 17:49:06.40ID:ATxCdpD+0
その読み方はした事ないけど自分の中で使っちゃうやつってのはあるね
charは脳内だといつもチャー読みだわ
2019/12/30(月) 19:59:49.22ID:87J66wvt0
気絶するほど悩ましいな
2019/12/30(月) 20:29:05.94ID:5ZlpxjqAd
char は敢えてシャアと読むべきだね
https://marycore.jp/programmer/char-aznable-type/
2019/12/30(月) 20:43:25.72ID:y1laSdPm0
>>521
いやもうお前はいいよ。
前半はどういう論理でどう白黒つけたいのかさっぱり分からんし、後半は要するに俺への文句だろ。

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

一応OpenBLAS見てみたんだが、やっぱFORTRANが生きているとは言い難いぞ。
アーキ毎に高速化されてる奴はkernelの中に入っているが、アセンブラとCしかない。
高速化されてない奴は確かにFORTRANの実装を呼んでるっぽいので、
実際に呼ばれるFORTRAN/C/アセンブラの割合がどれくらいかと、
最近他にFORTRANで改訂された物がどれくらいあるかだね。
つってもBLASの作りだと、単なる(FORTRANで書かれた）アセンブラライブラリでしかない。
現役だというのならまずその上位コードがFORTRANで書かれてないといけない。
2019/12/30(月) 20:43:49.47ID:y1laSdPm0
なお論調がまた勘違いして読み間違っているようだからもう一度はっきり言っておくと、
俺は君の意見なんて全く認めてないし、FORTRANは死んでると今も認識してる。
そしてお前は本当に議論が出来ないようだが、お前が今やるべきは、
A. 俺の『意見』を否定することにより、俺の『意見』を無効化する
B. 俺の『人格』を否定することにより、ここの人格重視の馬鹿C#er共と一緒に喚き立てて俺の発言全てを無効化したことにする
ではなくて、
C. 君の意見を補強する材料を提示して、俺の意見を木っ端微塵にする
なんだよ。お前みたいな議論が出来ない馬鹿はAやBにこだわるのが常だけど、
それだと、-1が0にしかならず、結果、その議論は何も得る物が無く、結論も出ない。
そうではなく、やるべきはCであって、+10とかぶっちぎってしまうことであり、
それが出来れば俺が-20とか出さないと勝てなくなるんだよ。
議論は足の引っ張り合いではなく、突っ張りあいをやるべきなんだよ。

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

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

> 別に項目になっているのだから、
> AI/MLに食われるような存在ではないということだろう。
お前はそもそも「スパコン」が何か理解出来てないようだが、何故ここまでこだわる？
2019/12/30(月) 20:47:34.21ID:tdJlCQBf0
「FORTRAN」「求人」でたくさん引っかかるのですが
本当に FORTRAN は死んだのでしょうか？
2019/12/30(月) 20:57:59.29ID:y1laSdPm0
>>533
お前にレスするのは不本意だが、なかなか良いツッコミだ。
が、俺は
> あれはスパコンのCOBOL扱いになってるはずだが。
> （もしかしてベクトルはFORTRANしか受け付けないのかな？これはあり得るが） (>>439)
と既に言ってるだろ。

COBOLなら求人があるのは分かるよな？そういうことだ。
http://labs.timedia.co.jp/2017/06/gnufortran.html
2019/12/30(月) 21:35:10.50ID:EmtYQ5a60
最新、トップシェア以外のものは死んでるという前提の理論はいらん
2019/12/30(月) 21:44:50.82ID:XBOZEUQCp
いやスパコン言ってるなら既に出されてる京のpdfを否定する資料をまず出せば？
相手にされてないってものCUDA Fortranで自分で否定してるし

なんか対等にやりあってる風を装ってるけど
既に木っ端微塵されたところから全然建て直しできてねえぞ？
2019/12/30(月) 22:05:30.33ID:uKQ1L5j80
>>527
ウンチングが正解
これ以外で読んだやつを信用してはならない
2019/12/30(月) 22:13:55.24ID:y1laSdPm0
まあFORTRANの話はいずれにしてもスレチだし、俺も終わりでいい。

ただお前らが思っている世界とスパコン界隈は全然状況が違うが、
それにしても興味もないだろうし、お前らに俺が間違っているとされても俺は問題ないので。
ただ、俺の話を少しでも信じる気があれば、
「FORTRANなんて既に死んでる」と言っていた奴が居たことを頭に留めておいて欲しい。
そしてもしなにか機会が発生したら、その時に俺が言っていたことを吟味してくれればいい。
それだけで、だいぶ違うはずだから。
2019/12/30(月) 22:16:46.91ID:y1laSdPm0
>>519
そう思うならそれでよし。
君は今の.NETの実装、つまり俺の纏めた 2 が妥当だと思ってるんだろ？
ならそう言えばいいだけ。
余分な人格評価とかすると（一般的には)君の評判自体も落ちると思うぜ。
そこも含めて自由にすればいいとも思うが。

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

ググってたら出てきたからついでに
何事においても、完璧に到達するのは、 付け加えるものが何もなくなったときではなく、 削るものが何もなくなったときである。 （アントワーヌ・ド・サン＝テグジュペリ）
2019/12/30(月) 22:21:24.79ID:y1laSdPm0
>>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.73ID:XBOZEUQCp
散々中立ぶっててこの未練がましさはさすがに草
無能さをさも自分がニュートラルであると振る舞って誤魔化す手合いだな
もうちっとまともな化けの皮を被れ
2019/12/30(月) 23:05:34.31ID:EEF4A29R0
コンピュータ関係者向けの漫談ぶっこんで、盛大に白けて終わったな
2019/12/30(月) 23:16:18.62ID:y1laSdPm0
>>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.54ID:CqEb/nEc0
ヤーッホーフォートランランラン
ヤーッホーフォートランランラン
て歌ってたな。
30年前だけど。
2019/12/30(月) 23:50:47.66ID:XBOZEUQCp
やっぱり終わらない笑
そしてまた持論の範囲を狭めて説得力ごと削ってゆくスタイルはもはや芸人である
2019/12/31(火) 02:01:20.46ID:YC1setdFM
ガイジの群れ
2019/12/31(火) 02:52:44.77ID:R+4lw4Fp0
おまえらいい加減にしないとpythonいっちゃうぞ？
2019/12/31(火) 15:54:10.80ID:uegmaB/s0
>>534
褒めていただき光栄です！

＞お前にレスするのは不本意だが、
そういわずに、私もよいコメントを出そうと常に思っていますので今後ともよろしくお願いいたします
2019/12/31(火) 19:20:27.09ID:uqnsAvu+0
>>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.67ID:uqnsAvu+0
ただ逆に言えば、そんな馬鹿ばっかでも何とかなってしまうのが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.62ID:uqnsAvu+0
>>548
君は多分狙いすぎてるんだよ。

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

ただ俺は君の空気を読まないスタンスは素晴らしいと思う。
そもそもここではネットならではの議論をすべきであって、それは
「ここで突っ込んだら相手の面子丸つぶれだな…でも明らかに間違いだしな…」みたいなところで躊躇する必要がまるでないことであって、
馬鹿がよくやってる罵倒合戦ではないんだよ。
君はこれは完全に出来てて議論慣れしてるところはいいと思うよ。
ただ繰り返すが、話をする気があるのなら、出てくるタイミングが酷すぎる。
2019/12/31(火) 21:01:44.58ID:3He7PpF20
長ったらしい説明は要点がボケる傾向にある。
553デフォルトの名無しさん (ﾜｯﾁｮｲ f12d-vQnI)
垢版 |
2019/12/31(火) 21:07:56.98ID:KGMG1qTB0
もうあんたら、学歴ジャンケンでどっちが頭がいいのか決着をつけたらどうだ？
それかQiitaに行けよ
2019/12/31(火) 21:25:28.17ID:YPeginhU0
長文連投キチガイの法則はデスノートなみに正確だということ
2019/12/31(火) 23:51:30.11ID:uRSSI5660
今年最後にあぼーんで埋まってゆく…
2020/01/01(水) 00:38:31.16ID:NLfsRE4W0
そういえば、なぜJavaScriptに初心者が魅了されるのかというと、
コンパイラがなくてもすぐに始められるために、初めて触る言語が
それであることが多く、それに慣れてしまっているからではないかと思う。

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

PromiseとResponceに、ServiceWorkerと responseWith、waitUntil
などの辺りなどは、ちゃんとした仕様が書いてあるサイトを見つけるのすら
難しい。
2020/01/01(水) 00:43:43.30ID:NLfsRE4W0
>>549
なぜ、HTMLアプリが増大しているかの理由については以下も参考になる。
OSとみなした場合に、WindowsやAndoridに比べてシェアが圧倒的に大きいからと考えられるそうだ：

【Wasm】ブラウザをOSとみなすとシェアはTOP
https://medaka.5ch.net/test/read.cgi/prog/1576520355/
2020/01/01(水) 13:50:13.63ID:6pvjYbyn0
>>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.93ID:6pvjYbyn0
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.58ID:qG+Zau3f0
>>464
コンバーターって、ValueConverterのことだよね？
StaticResourceとして定義すれば行けるはずだけど。
xamlを貼ってみると、回答しやすいんではないかな。みんな。
2020/01/02(木) 12:00:38.14ID:TpBXcd1kM
>>559
無茶苦茶だな
C#のasync/awaitはTaskがベースでpromiseとほぼ同じだ
そしてJavaScriptにもMS主導でasync/awaitが導入済み
2020/01/02(木) 19:11:21.24ID:FzsUW8F+0
>>561
そりゃTaskも最早ゴミだからだよ。
実際「asyncと書いておけば、後は小さいオッサンが何とかしてくれる」程度の理解で問題ないように出来てるだろ。
C#1.0からasyncだったら神だったろうよ。
そして俺はお前らの「今はもう要らない」仕様についても崇拝を続ける姿勢を信者だと揶揄してるんだよ。

ただJavaSriptのasync/awaitはMS主導なのか？だったらPromiseにこだわるのは政治か。
JavaScriptの仕様委員会は本当にどうしようもないな。
2020/01/02(木) 19:24:07.49ID:TpBXcd1kM
>>562
アホか
C#のasync/awaitがTaskのシンタックスシュガーであるのと同様に、
JavaScriptのasync/awaitもPromiseのシンタックスシュガーに他ならない
そして、あなたが敵視している「JavaScriptの仕様委員会」において仕様策定をリードしているのは紛れもなくMSであり、
あなたの敬愛するヘルスバーグもいわばJavaScriptのパイロット版ともいえるTypeScriptの開発を通じて関わっている
2020/01/02(木) 19:34:18.12ID:haQBNDzzM
古い技術より新しい技術のほうが優れてるから最初からそっちだったらいいのに、なんて言うのは誰でもできるわな
それと非同期処理はasync/awaitが覇権を握ったけど並列処理でまだまだTaskが現役だぞ
2020/01/02(木) 19:52:10.23ID:9KDR5rd70
Taskイラネって、WaitAllみたいなユースケースは頭にないんだろうな
障害児はプログラミングなんかしなくていいんだぜ
迷惑だからな
新海面処分場に自主的に向かってくれや生ゴミ
2020/01/02(木) 20:25:41.97ID:HeIctSc70
>>560
ありがとう。いま帰省してて手元にコード書ける環境がないので、戻ったら再度やってみるよ
流石にアイフォーンでxaml書くのはしんどいす
567デフォルトの名無しさん (ﾜｯﾁｮｲ 06ad-IH4P)
垢版 |
2020/01/02(木) 20:32:51.61ID:cbHiY2pH0
プログラミングしてないから、Taskが必要なケースも知らないんじゃない？
2020/01/02(木) 20:58:20.51ID:FzsUW8F+0
>>563
そりゃお前のスタンスがおかしい。敵視とかそういう問題ではない。
俺はゴミをゴミだと言ってるだけ。いい仕様を制定出来てれば褒めてるよ。

逆にお前らはポジショントークしかしてないだろ。
つまりC#を使ってるから（どんな糞仕様であっても）C#は素晴らしい、でしかない。それを信者だと言ってるんだよ。
比較的C#はマシなのは事実だが、全部素晴らしいわけもない。



>>565
それもPromise擁護のお約束だが、
asyncで済む場合にほぼ全員がasyncを選択する時点でPromiseはゴミでしかないよ。
だからPromiseにはそれ以外の機能もあるもん！というわけだが、
実際Promiseが無くても書けるし、難しくもないし、必要な時もそうないだろ。
○と○をくっつけたらチョー便利！なんてのはよく初心者がやってるが、それと同レベルだよ。
2020/01/02(木) 20:58:47.18ID:FzsUW8F+0
>>564
その通りだ。だから俺の方がヘルスバーグより賢いなんて言う気もないし、実際言ってもないだろ。
ただ、だからといって、古い技術の方がよかった、なんて事にもならないんだよ。
ゴミはゴミだと正しく認識するべき。

> 並列処理
元々の問題はC#が即時関数（ラムダ）を軽視してたことだろう。
とはいえC#は対応も他言語(C++/Java)と比べて早かったのも事実だが。
確かに並列に関しては今後とも残るかもしれん。

ただC#がTaskを用意したのは「UIコンポーネントはUIスレッドで」という.NETフレームワークの思想の為であり、
俺はこれがそもそも疑問なんだがな。GUIはタスクランチャーだと割り切り、
・GUIからの呼び出しは「新規スレッド」か「UIスレッド」か選べるようにする。
・UIコンポーネントはどのスレッドからでもいじれるようにする。
・そこで競合するなら自前で同期化機構を書け
でよかったと思うし、実際これで当初「Task素晴らしい！」みたいなことを言われていたのは大体解決出来るだろ。
要は「重いジョブ」「そのGUI出力」を同じ関数内に記述したいけど、それは「.NETフレームワーク的には出来ない」だけであって、
自分でおかしな縛りを導入して、それに対する解を用意してって、マッチポンプでしかないだろ。

ただまあ、馬鹿が多いようなので無駄に噛みつかれないようにもう一度言っておくと、
確かに並列用途にはTaskは残るかもしれんね。
だからといってPromiseがいいって事にもならんが。
570デフォルトの名無しさん (ﾜｯﾁｮｲ e12d-XiJJ)
垢版 |
2020/01/02(木) 21:08:54.36ID:+muZM7K/0
高卒の天才みたいな人はいらないよ
2020/01/02(木) 21:28:42.78ID:eV/mpEQr0
C＃ならではのアプリよろしく。
2020/01/02(木) 21:31:55.72ID:qr+4fHWP0
もしかして「シンタックスシュガー」が理解できてないとか。
573デフォルトの名無しさん (ﾜｯﾁｮｲ 06ad-IH4P)
垢版 |
2020/01/02(木) 21:36:12.24ID:cbHiY2pH0
> ・UIコンポーネントはどのスレッドからでもいじれるようにする。
この時点でマルチスレッドプログラミングまともにしたことない感が…
2020/01/02(木) 21:47:43.46ID:VmmTWzwp0
>>569
＞・UIコンポーネントはどのスレッドからでもいじれるようにする。
それは土台無理というものですよ…
2020/01/02(木) 21:59:18.76ID:PZFQVuh5M
別にUIコンポーネントのためにTaskを用意したわけではないが
2020/01/02(木) 22:26:33.22ID:qsQZs66Y0
Task登場前に比べれば段違いで楽になったわけやしな

その後直ぐにasync出たのも時代的に仕方なかったわけで
2020/01/02(木) 23:06:36.82ID:ZgXvL7GY0
俺がasync/awaitを使うとだいたいハングアップするんだけど
みんなどういう場面で使ってるの？
2020/01/02(木) 23:07:01.36ID:FzsUW8F+0
>>573,574
だからそれが俺には謎なんだよ。やれば出来る範囲としか思えない。
実際、お前らが今バインディングしている先も、一々排他チェックなんてしてないだろ。
そもそもGUIではレーシング時には「前の値」でも「後の値」でもどっちでもいいケースでほぼ全部で、
問題のあるところだけmutex等の遅い同期化機構でも全く問題ないんだよ。

MSはGUIがプチフリするのが許せなくて、30秒以上（だったかな？）のジョブをUIスレッドでやったら警告を出し、
他スレに強制移転させたわけだが、その時に仕様的にはそのままGUI出力出来なかったというのが元の問題だろ。
しかし button_onClickに最初から他スレで問題ないし、
そもそもお前らみたいに「DIコンテナが正義」ならどうせStringBuilder/TextBox等に直書きなんてあり得ないのだから、
必要ならDIコンテナ先で排他/同期で全く問題ないし、これの方が実際生産性も高いだろ。

ただこれは俺にとってはかねてからの疑問で、これを5chで言うのも初めてではない。
他言語、例えばJavaScriptも形式は違うが一応「UIはシングルスレッド」になっているので、何かあったのだとは思う。
色々聞いた限り、Javaで昔マルチスレッドなGUIがあって、盛大にそこでやらかしたから、
それ以降はシングルスレッドなのだ、との説を聞いたのだけど、これについて知っている奴はいるか？
ただそれにしても、その時はマルチスレッドにみんな慣れていなかったからであって、今なら普通にこなせるとも思うが。

>>575
ではなんだよ？
並列処理、というのは後付だと思うが。
2020/01/02(木) 23:48:39.72ID:PZFQVuh5M
>>578
マルチスレッドとマルチスレッド以外のあらゆる非同期、並列処理を統一的に扱うための抽象化だよ
歴史的な経緯で非同期、並列処理のやり方がマチマチでわかりにくかったからTaskにまとめた
これにより雑魚プログラマでも簡単に安全にイイカンジに最適化された非同期、並列処理を実装できるようになった
さらに統一的な抽象を得たことによって言語レベルでasync awaitを導入する基礎ができた
UIスレッドなんてのはオマケもいいとこだ
580デフォルトの名無しさん (ﾜｯﾁｮｲ 06ad-IH4P)
垢版 |
2020/01/02(木) 23:59:29.88ID:cbHiY2pH0
>>578
mutexを緻密にやればrace conditionが発生するし、
雑にやればパフォーマンスの低下を引き起こすと思うけど
UIの実装なんてあんまり真剣に考えたくないところなんだから、
別スレッドからUIスレッドへ実行すべきブロックをキューに追加するぐらいが丁度いいと思うが。
逆に、「やれば出来る範囲」と言うけど、実際にUIスレッドをスレッドセーフにしてまともなGUIフレームワークになっているものってあるの？
581デフォルトの名無しさん (ﾜｯﾁｮｲ 06ad-IH4P)
垢版 |
2020/01/03(金) 00:04:21.64ID:jYqYJjY40
すまん、race conditionではなくデッドロックだ
2020/01/03(金) 00:13:26.64ID:hATKQL5q0
マルチスレッドに分散処理させてた結果を最終的に本体スレッドで受け取る時に、queueで待機させて結局同期的にDBに書き込んでるんだけど、意味あるのかな？
2020/01/03(金) 00:17:52.23ID:O846x913a
>>582
その分散処理とやらがボトルネックになっているなら意味があるかもしれない
多くの場合はDBの方がボトルネックになるから、DBへの書き込みをバッチ化するとかの方が遥かに効果がある
2020/01/03(金) 00:48:08.71ID:fU3ErGER0
>>579
俺はそうは思わんね。

> あらゆる非同期、並列処理を統一的に扱うための抽象化
これは単なる「関数」で超大昔に終わってる。
つまり、非同期でも、並列でも、エントリポイントは「関数」であり、つまり渡す物も「関数」であり、
その上の階層で非同期か並列かを選べるのだから、「関数」で抽象化は完成してる。
実際、ちゃんと組んであれば、内部の関数はマルチスレッド/シングルスレッド/同期/非同期のどれで用いるにしても、
一字も変更する必要がなく、変更されるのは最上位での呼び出し方だけだろ。
これが「抽象化」が「関数」で完全に済んでいる証拠。
（というよりは、こうなる為のお作法として「グローバル禁止」等があるわけだが）

async/Taskがいいのは「その場に書ける」「戻り値を取れる」からであり、
抽象化してるとするなら、「同期」と「非同期」を抽象化してる。
（ただしキーワードが必要なので厳密には抽象化出来ているわけではないが）
だから、簡単で直感的な「同期」記述とほぼ同じ記述で「非同期」が出来るから美味しいだけであって、
それ以上でもそれ以下でもない。
そしてC#に非同期が必須みたいになったのはフレームワークの仕様の問題であり、これは回避出来たと思ってる。
585デフォルトの名無しさん (ﾜｯﾁｮｲ 06ad-IH4P)
垢版 |
2020/01/03(金) 00:57:27.50ID:jYqYJjY40
>>584
GUIなんて「グローバル変数」の典型例だと思うけど、
設計モチベーションの一つとして、GUIを便利に書く言語となってほしいってのがおそらく合ったと思うけおd、
それでも「回避できた」可能性はあるの？
2020/01/03(金) 01:06:44.31ID:fU3ErGER0
>>580
> UIの実装なんてあんまり真剣に考えたくないところなんだから、
これはその通りだ。

> 別スレッドからUIスレッドへ実行すべきブロックをキューに追加するぐらいが丁度いいと思うが。
そしてこれがInvokeというわけか？
まあ.NET的にはそうなのかもしれん。

> 実際にUIスレッドをスレッドセーフにしてまともなGUIフレームワークになっているものってあるの？
知らん。だから聞いている。
無いのは、無い理由があるとは思うのだけど。(そしてそれが、昔Javaで…だと聞いているだけ)
2020/01/03(金) 01:12:48.79ID:T8mFSGHc0
JavaScriptのPromiseが難しいのは、then のブロック内の最後の行で実行した関数の戻り値が勝手に次のプロミスにチェーンしていくみたいなところ。
ここが難しいのは、JavaScriptには明確な型が無いので公式サイトのサンプルを見ても、関数の戻り値がどんな内容（型）のデータを返しているのか分かりにくいところ。
それぞれの関数のドキュメントを調べてもそれが結局分からない。
同じ関数でも時と場合によって返すデータの型(?)が変わってしまうようなケースすらあるかも知れないし。
いまのところまだ理解できないのは、fetch でResponseオブジェクトを返すような処理。
ドキュメントの説明で、関数のプロトタイプ宣言の様な部分でも型がちゃんと書いてないので理解が難しい。
2020/01/03(金) 01:16:10.63ID:T8mFSGHc0
>>587
みなさん、これをすらすらと理解できますでしょうか？
自分はなかなか理解できません。
https://developer.mozilla.org/ja/docs/Web/API/Fetch_API/Using_Fetch#Response_objects
2020/01/03(金) 01:34:14.56ID:fU3ErGER0
>>585
回避出来たも何も、それ以前にする必要がないんだよ、割と。

例えば>>253,259、画面のGUIコンポーネントを直接参照して動作時は画面ロックの方がよかった、というわけだが、
実際これでも「自家用アプリに簡単にGUIを付けたいだけ」なら全く問題ない。
そして、演算実行中は放置だから、他スレッドとも競合なんてしないんだよ。

格好良くいえば、「運用で回避する」ということになる。
勿論プログラムとしては色々ヤバイが、必要なら真面目に同期取ればいいだけ。
手抜きなら「動作中は触るな」で十分、というわけだ。
クラッシュするのは例えばログ出力用TextBoxに複数から同時に書き込まれた時だが、
そもそもそれは複数出力元がある=複数の計算ルーチンが同時に起動する事が必要で、
全くのGUI初心者が最初に組むアプリではないんだよ。

それを非同期で別スレ起動してInvokeしろとか、かなり敷居を上げてしまってるだろ。
（もっとも、警告を無視してUIスレッドで計算して、当然GUIはフリーズ、みたいなことも出来たが）
2020/01/03(金) 01:47:00.56ID:VBfxgT36M
>>584
超大昔に終わってないから出来損ないのインターフェイスや実装がポンポン出てきて混乱したんだよ
でマイクロソフトが主導してC#における標準的な抽象としてTaskを導入した
プログラマはみんなそれを受け入れてTaskを使うようになった
2020/01/03(金) 01:53:44.42ID:T8mFSGHc0
>>588
追記：
thenブロック内部の関数の戻り値が Response「型」の場合でも、
直後のthenブロック内部の関数の引数が必ずしもResponse「型」ではないこともあるようで、その場合は、型の「自動変換」が行われているのではないかと思えるんです。
C++の場合だとプロトタイプ宣言などの関数宣言があるのでそれが分かり易いのですが、JavaScriptだと本当に型変換が行われているかどうかも不明確で理解が難しくなっています。
仮引数の型に可能性の幅が出てくる可能性があり、結局どのような「型」になっているか分からないので、どのクラス(?)のドキュメントを読んでいいのかも分からないので理解に時間が掛かります。
候補となりそうなクラスや関数の解説文を手当たり次第に読んでみて辻褄の合うようなものを自分なりに見つけてこないといけないようです。
C/C++ではなかった苦労がそこにあります。
2020/01/03(金) 02:26:10.78ID:cSDCrnP10
>>588
https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/fetch#Return_value
↑fetchの仕様を見れば戻り値は
「A Promise that resolves to a Response object」と明記されてるよ
MDNも日本語訳は内容が古いからまずは英語で見たほうがいい

const response = await fetch(…);
2020/01/03(金) 02:31:11.54ID:cSDCrnP10
>>591
>直後のthenブロック内部の関数の引数が必ずしもResponse「型」ではないこともあるようで
んんん？？

thenは2つコールバック関数を引数にとって
一つはresolveした場合、もう一つはrejectされた場合。
fetchが返すpromiseがresolveした場合は必ずResponseオブジェクトじゃないの？

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/then
2020/01/03(金) 03:19:39.56ID:RUwUdhzc0
>>578
＞Javaで昔マルチスレッドなGUIがあって、盛大にそこでやらかしたから、
Java ライブラリの GUI（基本は awt） ってそんなんだったかな…近々 awt を頭から見直そうと思っていますのでそのときに考えて見ます
2020/01/03(金) 10:59:52.40ID:3J/SmROP0
javaのフィールドに倣ってプロパティの接頭語にアンダースコアを付けるべきか悩んでいるのですがベテランの皆様はどう思われますか？
2020/01/03(金) 11:03:04.63ID:VBfxgT36M
好きにすればいいよ
どっちでも文法的に正しいし、どっちがより良いかは証明不可能
2020/01/03(金) 12:23:01.84ID:RUwUdhzc0
>>595
それはハンガリアン（の一種）といって悪い作法だと思います
2020/01/03(金) 14:09:52.04ID:T8mFSGHc0
>>592
A Promise that resolves to a Response object.
この言い回しが分かりにくて
「Responseオブジェクトを解決するところの1つのPromise」
とはコードで書くとどういうPromiseの事を言っているのか分かりません。
2020/01/03(金) 14:15:20.54ID:T8mFSGHc0
>>598
リンク先にあった、以下のコードを見ればどういうことなのかは大体理解はできそうですが。
「Xを解決するところの1つのPromise」
というものの正確な定義はどこにあるのでしょうか。

let myRequest = new Request('flowers.jpg');
fetch(myRequest)
.then(function(response) {
if (!response.ok) {
throw new Error('HTTP error, status = ' + response.status);
}
return response.blob();
})
2020/01/03(金) 15:32:49.36ID:fU3ErGER0
>>590
FrameworkOnFrameworkが日常的になっている時点で、
機能的に足りない＝そのFrameworkが糞、なのは明らかだろ。


>>594
AWS等について確認したが、どうやら
> スレッドとAWT/Swing
> https://www.ibm.com/developerworks/jp/java/library/j-thread/index.html
> https://www.ibm.com/developerworks/jp/java/library/j-king/
・AWSは多分何のプロテクションもない
・SwingはinvokeLater()とinvokeAndWait()(多分BeginInvokeとInvoke相当）が用意されている
・これらで手こずったので、.NETは最初から「UIスレッド縛り」を付けた
ように見える。結果的には妥当な判断なのかもしれん。
(AWSやSwingは俺が569で言った構成に《.NETよりは》近い）
2020/01/03(金) 15:33:08.37ID:fU3ErGER0
これらやその他の記事を読む限り、
Javaはどうもマルチスレッド周りの問題をまともに解決しに行ったように見える。
時代的に「最先端言語」としての矜持があったのかもしれん。
結果、爆死して今に至るのかも。
例によってデッドロック周りがやたら記述されているが、これに関しては、
折角ポインタを廃止して消し去った、「悪いプログラム片が少し混入しただけでアプリ全体がアウト」
になるCの問題点がそのまま復活してしまうから、Javaとしては絶対に許せない。
かといって、上手い解決策も見つけられてない。

ただ、デッドロックは多分今の若者が教育されているほどには驚異にはならない。
あれはアホみたいに「一つ確保して、その場ですぐ返す」構造にすればそもそも回避出来る。
つまりロック周り自体ではなくて、その上位構造から単純化してしまって解決する方がいいのだけど、
それをしようとはしていない。
逆にそれをしたのが.NETで、言うなれば全部のUIコンポーネントで一つのmutex、
それをUIスレッドが握りつぶす（他に渡さない）から他が触れず、Invokeするしかなくなる。
OOP初心者が訳の分からないクラス構成にすることはよくあるが、同様に、
Javaでマルチスレッド初心者が訳の分からないロック機構（しかもバグってる）を作りまくったのかもしれん。
.NETはそれよりは、仕様的に回りくどい構造になるがアホでも組める方を選んだのだろう。
とはいえそれもFrameworkOnFrameworkしたくなってしまうほど糞で、実際それをやらかし、
Task/asyncで収まった、というのが現在か。(話を総合すると）

歴史の流れとしては極めて妥当なのかもしれん。
2020/01/03(金) 15:58:36.89ID:NacIP61HM
>>600
君いわく超大昔にとっくに解決したはずのものが現実には多くの糞を生んだ
しかし新たに設けた抽象化であるTaskがそれれらの大部分を解決したということだな
君の言う関数という抽象化は非同期処理の現実には大して役に立たなかった
事実は事実として受け止めたほうがいいよ
2020/01/03(金) 17:14:48.26ID:fU3ErGER0
>>602
まあ俺のスタンスは変わらんけどな。一応纏めておくと、以下。
・Taskはゴミ。今となっては（非同期には）要らない。
・asyncは「抽象化」ではなく非同期の「記法」。
・asyncにより非同期の煩雑さは解決された。

簡単に記述出来る「記法」が足りなかったのに、非同期強制部分が.NETにあった為に多くの糞を生んだ。
元々はラムダや匿名関数周りが弱かったからであり、これらが最初からあればもうだいぶましだった。
実際、JavaScriptのイベントモデルだと、Taskなんて無くてもC#程酷いことにはならない。
そう出来なかったのはC#の問題であり、（といっても既に解決済みだが）
逆にWeb系は馬鹿でも出来るようになっているからこそ馬鹿が調子こいてる。（簡単なこと自体は素晴らしいことだが）

君がこれらを認めないのは君の自由。
2020/01/03(金) 17:23:20.75ID:RiNqytdzM
多くのケースでasyncawaitでコーディングしたほうが簡単だがTaskが要らないわけではない
並列処理では相変わらずTaskが活躍している
またasyncawaitを実装するためにはTaskという抽象が必要だった
関数で抽象は完結してるなどとトンチンカンなことを主張して思考停止していたらasyncawaitの発明には到達できなかった
2020/01/03(金) 17:35:57.54ID:VSKvK8ih0
並列処理はうまく書けないからasync/awaitは中途半端な糞！にならないのが不思議だなあ
てかこのひと年末からずっと何かにつけて「ほにゃららは糞！おまえらは信者！」から入るのに
ひたすら教えられてるだけなのが面白いね
2020/01/03(金) 17:56:04.43ID:cSDCrnP10
>>598
スレチな気もするが一応回答しとく

Promiseってのは処理が終わってるかもしれないし
まだ終わってないかもしれないという文脈付きで値を運ぶ入れ物
処理が終わってる場合は、成功してるケースもあれば失敗してるケースもある

つまり下記3つのうちいずれか1つの状態にある
1. Pending:まだ終わってない/結果待ち
2. Fulfilled: 成功で処理完了済み(=Resolved)
3. Rejected: 失敗で処理完了済み

「戻り値が A Promise that resolves to a Response object」というのは
戻り値はPromise(=文脈付きで値を運ぶ入れ物)で
成功で処理が完了済みの状態になった場合
入れ物の中身は「a Response object」になるPromiseですよって意味
2020/01/03(金) 18:03:40.42ID:cSDCrnP10
>>599
>.then(function(response) {

.thenの第一引数はresolveした場合のコールバック関数で
そのコールバック関数に渡される引数が
Promiseが成功で処理完了済み状態になった場合に入れ物の中に格納してる値

fetchの場合はそれが「a Response object」
function(response){…}というコールバック関数の引数(response)に
Promiseという入れ物に格納されたa Response objectが入る

https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Promise/then
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況