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/27(金) 11:56:34.65

信者的信者的ってなんのこと言ってんだコイツ？
ファイナライザ持ちがDispose呼ばないと昇格オブジェクトが増えてやばいって警告に
誇大広告だのほざいてるのは自分じゃねえか
自分のコードでDispose呼ばずにフルコレクトかましてガクガクさせながら「自分はそれほどでもないと思う」とかなんのギャグだよ

2019/12/27(金) 11:59:55.99

>>401
JITだからできることでコンパイラじゃできなくない？
何が気になるかって言うと、コールスタックの解析とかをコンパイル時点でやり始めるってのは停止性問題を取り扱うみたいなむりがあるんじゃないのかってこと。
ごく簡単な例だったら問題ないだろうけど、そのごく簡単な例ってわずかじゃないのかな。

2019/12/27(金) 12:08:44.93

それをコンパイラ(というか型システム)でやろうとした結果がRustだね。
ちなみに彼は知らないようだが、Rustのメモリ管理がスマートであると言われる所以は、
エスケープしていないオブジェクトの生存管理などではなく(そんなものはC++でとっくの昔に実現されている)、
エスケープした「ヒープ上の」オブジェクトも正しく追跡して破棄できること。
それがプログラマにどれだけの負担を強いているかは>>390の通り。

2019/12/27(金) 12:34:15.59

>>402
Formsが過去の遺産で糞で既にVSからデフォで除外済みなのは知ってる。
ただし俺は移行するよりはそのままメンテする方を選んでいるだけ。

usingについては、C#8.0(2019/09リリース）で改訂されているのだからobsoleteとは言わんだろ。

まあそれはさておき、Web開発ってのは以下で、現状のC#の主力はWPFではなくこれだって事か？
https://docs.microsoft.com/ja-jp/visualstudio/ide/quickstart-aspnet-core?view=vs-2019
見た目サーバーアプリで、つまりPHPの代替のように見える。
なら実際の描画はやる必要がないから、そりゃGDI+オブジェクトを掴むことはあり得ないわな。

> Webのパフォーマンス改善の観点で言えば、(君の愛する)スタックにしか置けない特殊な構造体の導入等により、
> C#のGCに極力頼らない高度なメモリ管理は実は一部では既に実現されている。
調べてみたが、Span<T>, stackalloc, ref struct 等か。確かにこれらは悪くない。
こういう小回りも利くところがMS主導言語のいいところではある。
実際にコードを書く奴らが主導している匂いがする。
ただな、こういうマニュアル調整は本来C#が目指しているものではないだろ。

GCを使う＝変数等の寿命について一々考えたくない、であって、
実際、C++だと考えることが多すぎて、開発に手間がかかる＝開発効率が悪くなる。
だからそこをランタイムに丸投げして、ユーザーは本来書くべきコードだけに集中出来るのがよいのであって、
あれこれ弄れば速くなります、なら、最初からC++等使え、でしかない。
とはいえ、折衷策として出してきたのは悪くないが。

JavsScriptの良い点は、「何も考えなくてもJITが勝手に速くしてくれる」事であって、
俺はこの点が最高に気に入ってる。
ちゃんと弄れば速くなります、なんてのは、面倒＝開発効率が下がる。
ただしC#はスクリプト言語レベルの手抜きを目指しているわけでもないから、割と妥当なラインなのかもしれんが。

2019/12/27(金) 12:41:35.60

えらい散らかった論調だな。もう少し端的に話せんか？

2019/12/27(金) 13:00:43.57

>>404
JITで出来ることとコンパイラで出来ることは違うが、今回に関しては同じだよ。
（関数単位でJITしてる限り同じ）

普通に考えれば分かると思うが、関数内の変数なんてその関数出たら破棄される物が大半で、
仮に内部でさらなる関数呼び出しに関連している物が全部追跡不可能だったとしても、十分効くんだよ。

完全にやり切ろうとするのはそりゃかなり無理だよ。でもそれは必要ないんだ。

2019/12/27(金) 13:13:01.35

極論 vs. 極論でなんともw

2019/12/27(金) 13:18:13.87

>>405
> ちなみに彼は知らないようだが
実際知らんからRustの話は君に任せる。

俺はRustはどういうコンセプトでどういう状況かを遠くから眺めているだけで、
「このコードが動かないんです！」みたいな悲鳴をチラ見してるだけだからな。
ただ、その中に「ヒープ上のオブジェクトすらも勝手に解放されるのかー！！！」みたいな話もあった気がするが。
スマポ限定なだけだというのなら、あれは関数呼び出しによる所有権移転で解放されただけの話か。
まあそうかもしれん。
いずれにしても俺はRustのコードは書いてないし、直近で書く予定もないので、Rustについては君に任せる。

2019/12/27(金) 13:29:20.92

どうせ過疎スレだし、BGMこれでガンガンやって欲しいw
https://youtu.be/BvmqYM1xpZA?t=28

2019/12/27(金) 16:53:56.60

トヨタの車をブレーキを踏まずに運転できる人なら、usingはいらないよ

2019/12/27(金) 20:05:38.60

うぜーから個人ブログでやれよ

2019/12/27(金) 21:26:25.65

正直半分ぐらいしかわからないけど、たまには盛り上がるのもいいよ

2019/12/27(金) 23:28:54.87

2週間に1度ぐらいのペースで、わけのわからん話題で盛り上がってる気はする

2019/12/27(金) 23:31:26.75

ふらっとじゃなくこっちで暴れる分には好きにしたらいい
こっちでNGしとけばふらっとで見なくて済むし

2019/12/27(金) 23:40:23.09

>>414
半分しか分からないのは、オブジェクトの寿命を考えずにコーディングしているからだ。
ただしこれがGC言語の魅力でもあり、一々グダグダ考えていると魅力半減ではあるが、
そうは言っても、上達したいのなら、考える癖は付けた方がいい。

これについては、禿(ストロウストラップ＝C++創始者）の
「ドキュメントを作成すべきコードのサイズには下限があるが、
コーディングする前に考えるべきコードのサイズには下限がない」
が当たってる。なまじ出来るようになるとどうとでも組めるようになるが、それがいけない。
本来このコードはここにあるべきか？というのを考えながらコーディングした方がいい。

usingに関しては、そもそもGDI+オブジェクトが永続化されるのが間違いで、
それはVに状態を持つということだから、MVCから見てもアウトだとすぐ分かるだろ。
本来は、GDI+オブジェクトに関しては、
・usingの中でしか使えない
・スタック上にしか置けない
（まあこの2つは等価だが)みたいな制限を課されたとしても、まともな設計なら制限にすらならないんだよ。

で、戻るが、これが分からないのなら、それはオブジェクトの寿命を考えてないからだ、となる。

といっても分からないだろうから、具体的に説明すると、
例えばドベタな将棋ソフトを作るとしよう。
CPUと対戦するだけの将棋ソフトで、ドベタに、
ユーザーが入力（指す）→画面の更新→CPUは考える→指す(画面の更新)→アイドル（ユーザー入力待ち）、の無限ループだとしよう。
これでMVCなら、
M：盤面と持ち駒情報
V：画面表示
C：それらのグルー
であって、画面はその都度最新状態に更新されているのだから、
アイドル状態で残っているオブジェクトはどう考えてもMの「盤面と持ち駒情報」だけでいいだろ。
だからアイドル状態にてV用のGDI+オブジェクトが捕まれたままになっている時点で設計がおかしいんだよ。
この点、Janeは再起動してみたが相変わらずGDI+は8,657なので、明らかに糞設計だと断言出来る。

2019/12/27(金) 23:41:02.61

画面の更新は、当然関数であり、
画面の更新はこの中でしか行われないのだから、当然、この関数を出ればGDI+オブジェクトは破棄していい。
だから、全てのGDI+オブジェクトは、どこかで
void some_funciton_0(){
using (var someGDIobject = ... ){
some_function_1();
}
}
みたいにusingで囲めるポイントが必ず存在する。例えば、ど頭でCreateGraphicsするなら以下となる。
void redraw_board(){
using (var gr = someControl.CreateGraphics()) {
some_function();
}
}
これは寿命という意味では、関数の一番頭でCreateGraphics＝この関数と変数grの寿命を同期させているわけだが、
この関数以外に画面更新関数がなく、常に全面更新完了して抜けるのだから、
grはどう考えてもこの関数の外で使われることが無く、これで問題になりようがないだろ。
だから変数を寿命順に入れ子にし、結果的に関数コールも同様に並び、変数の寿命とスタックの動作が完全に一致する、というのがC流で、
動作としてはこれが一番無駄がないから、この設計で組まれた場合に速度ではどうやっても勝てない、ということになる。
別にこれが難しいとか制限が厳しいとかいうわけでもなく、要するに無駄なく普通に組めばこうなる。
だからまともな設計に於いて、GDI+オブジェクトに
・usingの中でしか使えない(＝スタック上にしか置けない)
という制限を課すのは、制限にすらならない。
これが問題になるようならそもそも設計がおかしい。

ただ、現実論として、度重なる仕様変更によりプログラムの設計というのはおかしくなって行くもので、
多少設計がおかしくてもなんとでもなる言語じゃないと困るのだが、
それにしてもGDI+オブジェクトは上記制限を課されても全く問題ないと思う。回避手段もあるし。
というかマジな話、MVCにしてればV用オブジェクト掴みっぱなしなんてあり得ないし。

2019/12/28(土) 04:09:04.41

GDI+だけがアンマネージドリソースではないんだが
そんな狭い前提で話されてもなぁ

2019/12/28(土) 09:58:00.22

ちょっと言い方が本質的でなかったから言い直すと、

ある関数内で必要とされるリソースに対して、
・その関数突入時には掴んでおらず、
・その関数脱出時にはリリースしててよい（＝その関数の中でしか使わない）
場合は、必ずブロックスコープの入れ子で対応出来る。(A)

となる。Cはある意味これしか無く、これを「不自由だ」とする人達はGCに向かったが、
結局C的上記手法に回帰してる。これはC++もそうだし、C#もそうだ。
C#8.0のusing、何度も言っているが書く場合は完成型だが、意味的にはC++のデストラクタと同じでしかない。
なら36年前に開発済みの手法であり、C#1.0からこれでよかった。
それを19年かけて再開発して、何も知らない若者がありがたがるという、間抜けなことをやっている。

ここら辺がLinusがC++を嫌う理由で、C++も同様に仕様を引っかき回した挙げ句、C的手法に回帰してる。
なら最初からCで書け、Cで出来る範囲しかC++は認めない、というのも、酷い言い方だが確かにそうでもある。
同様に、C#も、usingの間抜けさに気づくのに8.0までかかったんだから、
C#12.0位で上記縛りを付けて廃止する方向になるのではないかな。
MとVを分離するのは現在既に常識だし、Vを分離している場合にはGDI+リソースについては上記(A)は必ず成立する。
ファイル等のその他アンマネージドリソースについては後回しになるだろう。
言語/プラットフォームとしての整合性/統一性が取れないが、C#は整合性より実質的利益を選択するはず。

2019/12/28(土) 09:59:17.52

お前らは多分気づいていないんだろうけど、C系言語は「関数を抜けたらローカル変数は全て破棄される」為、
動作効率はいいが、関数を頻繁に抜ける＝GUIとは絶望的に相性が悪い。
GUIの場合は各イベント関数がトップレベル関数(C#コンソールアプリでいうmain)になるから、
上記「入れ子」での変数処理にかなり無理が発生してしまう。（アーキテクチャ的に無理）
ここら辺は最初からGUI用に設計されているJavaScript等をやってみれば分かる。
JavsScriptの場合は全部の関数がクロージャ付きだから、クラスと関数の区別もなく、関数に変数が紐ついてる。
だから、C系言語だとグダグダになるGUIも、JavaScriptなら比較的綺麗に書ける。
C#はいい言語だし、1つ学ぶならC#という選択も悪くはないが、他言語をやりさえすればあっさり見えることはある。

JavaScriptは糞だ糞だと言われて久しく、AltJSもやたら作られたが、いまだに殺しきれないのは、
結局のところ根幹のアーキテクチャ「全関数がレキシカルスコープのクロージャ付き」がGUI向けに圧倒的にフィットするからだ。
同様に、C#含めてC系言語がやたらあるのに、Cを殺しきれないのは、結局のところ、Cの根幹のアーキテクチャ
「変数の寿命とスタックの動作を一致させ、最速を得る」が圧倒的に素晴らしいからだ。
「変数の寿命を考えて設計しろ」なんてのは今も昔もそう言われてないが、（ただCにはそれしかないから言わずもがなだったが）
C#もC系ではあるのでC的手法で設計した方がフィットするのは事実。
寿命なんて考えたこと無かった奴は考える癖を付けた方がいい。
そして可能であればJavaScript等の「コンセプトがそもそも違う」言語を触ってみた方がいい。
そうすれば、C系言語が何を捨てて何を取ったかも分かるようになる。
具体的には（歴史的にはおかしい言い方だが）、GUI対応を捨てて速度を取っている。

2019/12/28(土) 09:59:55.78

なお余談だが、そのGUIをグダグダにならないように設計として対処しよう、というのがMVCであり、
これはやった方がいいのは事実だが、酷い話、
JavaScriptほどGUIと相性がいいとMとVが混ざっていようがなんとでもなってしまうのも事実で、
これの最たる物がjQueryであり、jQuery自体ではなく使う奴の使い方の問題なのだが、レッテル貼られて丸ごと廃棄されようとしている。
ただここら辺も、やれば、C#なんてGUIにはまるで向いて無く、
だからMVCだバインディングだと手の込んだ仕掛けを作って誤魔化さないと駄目なのだ、というのが分かるようになる。
だからまあ、設計の善し悪しが分かるようになってきたら、他言語を触ってみればいい。
（分からないうちに触っても文法コレクターにしかなれず、意味無いから止めとけ）

2019/12/28(土) 10:32:20.67

FormがBackgroundプロパティを持たないでどうやって背景色を指定するのかな？
再描画の際にしかBrushのGDI+オブジェクトは使用されないのだから常にBrushがGDI+リソースを持ち続ける必要がないという主張であるなら、パフォーマンスを度外視すればその通りかもしれん。
しかしBrushがGDI+リソースと一対一対応するのではなく必要なときにだけ内部的にGDI+リソースを作るような設計思想なら、
そもそもBrushのusingが一切必要ないようなアーキテクチャが十分に実現可能なんだよ。
言語をいじるまでもない簡単な話。

2019/12/28(土) 11:00:39.51

今日も知ったか君が暴れてるw

2019/12/28(土) 11:09:23.84

予防線張ることに必死過ぎて何言ってんのかわからなくなってる典型だなこりゃ
自分の発言を自分で否定しながらお花畑垂れ流してる底抜けのアホ

2019/12/28(土) 11:11:57.13

オブジェクト指向ではリソースは依存性として分離して注入するのが良い習慣とされる
なのでローカルスコープでいきなりリソース確保みたいなコードを書くことは稀だ
C#やJavaの世界ではリソースのライフタイムはDIコンテナが管理するものであってスタックに同期させるものではない

2019/12/28(土) 11:16:46.70

>>426
彼の主張は置いといて、生成タイミングの制御のためにDIでファクトリーオブジェクトを注入するのはよくあるパターンだぞ

2019/12/28(土) 11:45:36.16

cでもmallocしてりゃどこかで開放は要るだろ。
理屈すり替えて楽しいか？

2019/12/28(土) 13:24:27.10

>>423
> パフォーマンスを度外視すれば
GDI+オブジェクトの生成ってそんなに重いのか？

> そもそもBrushのusingが一切必要ないようなアーキテクチャが十分に実現可能なんだよ。
その通りだ。だから.NET自体がボロいんだよ。

元々はGDI+オブジェクトのリソースが限られていたから、win98までは文句を言わず俺が言っている
「使うときだけ生成、使い終わったらすぐ解放」
しかなかった。これを「面倒」と思ったのか単にボケているだけなのか、
リソースが大幅に増えたこともあって問題にもならなくなった為、掴みっぱなしも出来るようになった。

.NET自体はWin32APIを隠蔽する為の物で、これ自体は良く出来ている。
ただ、俺は、君の言うとおり、もう一枚多く隠蔽して、usingが一切不要のフレームワークにした方がいいと思うけど。
もしGDI+オブジェクト生成が問題になるほど重く、キャッシュしたいというのなら、直接自前でGDI+オブジェクトを掴む必要がある。
だから.NETは今のアーキテクチャなのだ、と捕らえることも出来るが、
実際はそうではなく、単に皮を被せただけで、その皮の厚さが不適当だっただけだと思うよ。
まあこれはすぐに修正出来る話でもあるけど。

2019/12/28(土) 13:31:51.66

>>426
> オブジェクト指向ではリソースは依存性として分離して注入するのが良い習慣とされる
そうだ。ただ、これがGUIとは絶望的に相性が悪いんだよ。
実際、Formsはこれで、各コントロールが値を保持してそれを参照する、というアーキテクチャだが、
事実としてこれは使いにくくて、WPFでばっさり修正されてるだろ。
(例としてはまんま>>253で、彼が253の時点でいいと思っているアーキテクチャがFormsのものだ。
だから俺は253はFormsしか知らない老害に文句を言われたのだと思っている）

一応Webは当初は（というか一応今も）Javaでもクライアントコードを書けることになっている。
ただ、JavaとJavaScriptだと書きやすさのイージーさの次元が違っていて、喧嘩にならないんだよ。
一応アプレットが遅いだの色々理由が付けられてるけど、
俺はJavaScriptの方が圧倒的に楽に書ける、というのが本質だと思うよ。
(仮に速くてもJavaは駆逐されてたと思う）

不幸なのはGUIが出てきた時の覇権言語がCであった為、
有無をいわさずGUIもCでやり、そしてそれを今でも引きずっている点だ。
そしてその後はOOPが覇権を取ったから、GUIもOOPだという事になるのだが、これがまた間違いで、
これを盛大にやらかしたのがFormsだ。
MVCのMなんて、OOP（特にJava)で禁忌とされるグローバルそのものだろ。
C系言語の変数管理そのものがGUI向きではないんだよ。
そしてOOPの変数局在化思想もOOP向きではない。結果、Formsは二重に間違いを犯してる。

2019/12/28(土) 13:34:55.12

>>430
最後訂正
x そしてOOPの変数局在化思想もOOP向きではない。
o そしてOOPの変数局在化思想もGUI向きではない。

まあ分かると思うけど紛らわしいので一応。

2019/12/28(土) 14:09:15.47

うーん、なんかさすがに「アインシュタインは間違っている！」と主張するトンデモ本作者的な主張は草不可避w

2019/12/28(土) 14:31:37.94

>>432
それが信者的態度だよ。
お前はC#以外の言語をいくつも知っていて、C#/.NETの良さ/悪さをちゃんと識別出来るのか？

ただしこれはC#だけではなく、どの言語スレも割とこの傾向の奴が多いのも事実だが。
ただその態度は目を曇らせるから止めた方がいい。

C#が覇権を取れておらず、今後とも取れそうにもないのにも理由があるし、
JavaScriptが糞糞言われてもやたら蔓延っているのにも理由がある。
お前が何を好きかはお前の自由だが、何故そうなっているのかが分からないようなら単なる馬鹿でしかない。
勿論馬鹿であり続けるのも君の自由だが。
> https://www.youtube.com/watch?v=Og847HVwRSI
> https://mevius.5ch.net/test/read.cgi/tech/1571315884/69

2019/12/28(土) 14:54:05.52

そんなに良いものなら実装してC#チームにマージリクエスト出したら？
ここで演説しても全く時間の無駄だよ？
実装するのにスキル不足なら機能リクエストでもいい
C#はオープンソースなんだからさ

2019/12/28(土) 15:20:44.51

今でもJavaでもクライアントコードを書けることになっている、とか、どの世界の話だろう？
あと、自分は432じゃないけど、
> それが信者的態度だよ。
> お前はC#以外の言語をいくつも知っていて、C#/.NETの良さ/悪さをちゃんと識別出来るのか？
というぐらいなら、C#以外の言語使えばいいんじゃない？って思ってしまう。
実際自分はプラットフォームに合わせて、アプリケーションの使いかたに合わせて8言語ぐらいから選んで使ってるけど。

あと、C#が覇権を取れていないとは全く思わないけどな。Windowsで適当なアプリ作るなら普通みんなC#で書くんじゃないの？
UnityだってC#だし。

2019/12/28(土) 16:14:20.14

>>434
俺は.NETを使っているのであって、C#は使ってない。

ただ、usingをどうするかは思想の問題であって、技術的に不足しているわけではないので、提案しても通らないとは思う。
（作ってる側も知っててそうしているはず）

>>435
そう思うならそれでよし。
C#は良い言語だし健闘している方だが、Javaと食い合うなら死ぬのはC#だ。(俺はJavaが死んで欲しいのだが)
OracleはJavaを技術的に成長させることは出来なかったが、ある意味余計なこともしなかった為、
プラットフォームとしては既に膨れあがってしまった。
後はC#で成果が出た仕様を順に取り入れていけば、「C#には負けない」言語にはなる。（勝てもしないが）
同じような仕様で並立すると、死ぬのは小さい側のC#なので、当然C#は新規機能を追加して逃げ続けるしかない。
これはこれで恩恵はあり、そうこうしているうちに勢力逆転出来ればいいが、今のところその芽もないだろ。
(Unityがそうだというのならそれでいいが）

> Windowsで適当なアプリ作るなら普通みんなC#で書くんじゃないの？
俺は知らんが多分Python。大体ネット上ではブッ叩かれているが。
その動画見ても一応トップだし。

2019/12/28(土) 16:38:51.11

ずーっと勝ちだの負けだのふわっふわなことこだわってるのなこのド近眼馬鹿
手前で他の言語持ち出してきて突っ込まれたら知らんから解説譲るとか逃げてるし
まさに無意味な頭でっかち文法コレクター（笑）を自ら体現してる
クスリでもキめてんのか？

2019/12/28(土) 22:03:53.41

>>436
> 俺は知らんが多分Python。大体ネット上ではブッ叩かれているが。
いやいや…
実情を知らなすぎだろう？C#なら実行ファイルの入ったフォルダごと渡したら実行できるようになるけど、
Pythonだと環境を作ったりとか結構めんどくさいぞ。大体GUIを考えたらPythonとか最悪でしょ。
「お前はC#以外の言語をいくつも知っていて、C#/.NETの良さ/悪さをちゃんと識別出来るのか？」とか言ってる割にはトンチンカンすぎる。

一応言っとくと、C#しか書けないからこう言ってるわけじゃなくて、Pythonもガンガン使って仕事してるからね。

あと、JavaはもうほとんどSIer専用言語みたいになってるから、C#と直接比較するのもナンセンスでしょ。
スーパーコンピュータで科学技術計算する分野では今でもFORTRANが主役だけど、そこ以外で使わないだろ。それと一緒。
最強言語なんてのはない。色々なニーズに合わせて言語（プラットフォーム）を選んで何でも書けばいいんだよ。
手続き型言語だったら考え方は大して変わらないからね。

2019/12/28(土) 22:29:59.46

>>438
そりゃお前の現状認識がおかしいと思うぞ。

インストールすら大変なら、Pythonがここまで蔓延ることはない。
何故かよく出てくるFORTRANガーってのも、FORTRANなんて実際もう誰も使ってない（と聞いている）し、
今のFORTRANは昔のFORTRANとは別物（と聞いている）ので、FORTRANを持ち出すのもおかしい。
それはVBを持ち出してBASICがまだ使われている、と言っているに近い。（はず）
多分お前もFORTRAN信者に嘘を吹き込まれているだけだと思うが、
冷静に考えれば見抜けるはずだが、FOTRAN全盛時代の連中はもうリタイヤかその辺であって、コードなんて書いてない。
あれはスパコンのCOBOL扱いになってるはずだが。
（もしかしてベクトルはFORTRANしか受け付けないのかな？これはあり得るが）

まあいいが。
いずれにしてもお前らが何故そんなに信者化するのかはいつも疑問だ。

2019/12/28(土) 22:34:45.14

自分が作ったものだけ動かすなら楽だもの。Python。
envで環境作らないといかんくなったらめんどくさい。

お前あんまり知らねえだろ。

2019/12/28(土) 23:12:31.42

>>439
開発用PCでプログラミングするだけで十分な場合と、デプロイが必要なアプリケーションを作るのは違うんだよ。
Pythonが流行ってるのはデプロイが必要なアプリケーションでなければ、かなり楽できるから。
デプロイするのは結構大変だよ。インターネット接続不可の環境でpipを使うのはめちゃくちゃ難しいし。

仕事でプログラム作ってアプリ納品したことないでしょ。その経験がなければプログラミングを語るなとは思わないけど、
納品という観点でみたらナンセンスすぎるんだよ。よくも上から目線で「お前の現状認識がおかしい」と言えるね。

あと、PythonでGUIアプリケーションを書くことに関してはスルーかな？

FORTRANの下りも、聞きかじった知識だけじゃん。
科学技術計算でよく使われるBLASっていう線形代数のライブラリがあるんだけど、githubで見る限り半分はFORTRANで書かれてるよ。
https://github.com/xianyi/OpenBLAS/
4,033 commitsとか書かれてるところの下の棒押してみ。

Fortran 49.3% Assembly 26.7% C 21.2% C++ 1.4% Makefile 0.8% CMake 0.4% Other 0.2%
って出てくるから。

あと、書かれてるコードも昔のFORTRANそのものでしかないコードだよ。
https://github.com/xianyi/OpenBLAS/blob/ce3651516f12079f3ca2418aa85b9ad571c3a391/lapack-netlib/SRC/dgebd2.f

これを今でも皆コンパイルして使ってるわけ。スパコンだけじゃなくて、PCでもね。

んで、プログラマーじゃなくて、研究者はいちいち他の言語とか覚えたくないから、今でもこういう乗りのFORTRANを使ってるわけ。
http://www.chem.konan-u.ac.jp/PCSI/DL_POLY/still_FORTRAN.pdf

どうしてろくに自分で調べもせずに聞きかじったそれっぽい言葉を信じちゃうのか。
「いずれにしてもお前が何故そんなに知ったかするのかはいつも疑問だ。」

2019/12/28(土) 23:13:03.41

自分とは違う意見=信者、と言うレッテル張り

2019/12/29(日) 00:26:30.89

>>441
もう意味がないから終わりでいいが。

> インターネット接続不可の環境
今更ねえし。それがC#なら楽チン！（とも思えないが、仮にそうでも）それが売りになるとでも？

> あと、PythonでGUIアプリケーションを書くことに関してはスルーかな？
当たり前だがGUI用のツールキットも死ぬほどあったはずだよ。ググればいくらでも出てくるでしょ。

> 4,033 commitsとか書かれてるところの下の棒押してみ。
それで飛んでいった先が
> C 3950
> Fotrran 3720
なんだが。コミットが多いだけでコードの数はCの方が上だし。
それ以前に今時のML向けのCUDAやOpenCLじゃFOTRAN使えねえだろ、と思ったが、
CUDAにはFortran出てるのな。ちょっとびっくりだわ。

> これを今でも皆コンパイルして使ってるわけ。スパコンだけじゃなくて、PCでもね。
君本人がFORTRAN書いているのか？それならまあそれでいいが。
そのスライドなかなか面白かったけど、2010年代がねえだろ。そういうもんだよ。
京がCとFORTRANのユーザー割合を公開していた気がしたが、出てこないんだな。

> 研究者はいちいち他の言語とか覚えたくないから
これはその通りだけど、だからこそ、年代的にFOTRANはほぼ絶滅してて、
今時はPythonで書かせろゴラアで、NumPyだCythonだが出てきてるわけだろ。

もし君がFORTRANを実際に書いているのなら、それだから君の周りにFORTRAN使いが多いだけであって、
やっぱり君の現状認識は間違ってると思うぜ。

2019/12/29(日) 00:34:45.31

結局このスレで長文垂れ流して何がしたかったのかは永遠の謎だった

2019/12/29(日) 00:36:25.95

>>441
すまん、名前(TensorFlow)が出てこなかったので分かれてしまったがついでに。

GoogleのTensorFlowもPython,/C/Java,/Goであって、FORTRANは動かない。
CUDAは既に書いたようにFortranも出ているようだが、
元々はそもそも出す気もなく、ユーザーも「C++のサポートを」とは言っていたけどFORTRANについては言ってなかったと思うけど。

BLASのFORTRANをUpdateしている連中は、どこで何向けを流しているんだ？
現在のHPCはFORTRANなんて見てないと思うのだが。（上記CUDAやTensorFlowしかり）

2019/12/29(日) 00:40:06.58

GUI Programming in Python
https://wiki.python.org/moin/GuiProgramming

2019/12/29(日) 00:58:10.27

python製のwindowsアプリって何かある？

2019/12/29(日) 01:04:54.28

凄えなGitHubの見方もまともにわからねえのかコイツ…
ここまで全方位に雑な上から目線キャラ初めて見たｗ

2019/12/29(日) 01:13:01.51

現時点でwinアプリ開発で採用される言語のトップにpythonなんか入るわけ無いと思うけど
普通にC++/C#/VB辺りじゃない？
VBは国内だけかな？

この次あたりはどれも似たようなもんでそこにpythonが入るとかならまぁわかる。
javaはwinアプリなんかで使われてるのかはわからんけど

2019/12/29(日) 01:17:48.90

ある程度の知識が広く浅くあるタイプの人間で技術屋以外に対して上手く話をして言いくるめるのが得意そうな感じ
あんま知らんけどSIerってこんな感じの人間なのかな？って見える

2019/12/29(日) 01:55:47.41

言い訳と反論が得意なイメージ有るけど。

2019/12/29(日) 11:03:14.73

>>443
> 今更ねえし。それがC#なら楽チン！（とも思えないが、仮にそうでも）それが売りになるとでも？
いくらでもある。当然売りになる。というかセキュリティ要件で満たさなきゃいけない。

> 当たり前だがGUI用のツールキットも死ぬほどあったはずだよ。ググればいくらでも出てくるでしょ。
で、使おうとしてみたことあるの？Pythonしか書けないってんじゃなければWinFormsの方がましとすぐに気がつく。

あとgithubのグラフの読み方は間違ってる。コミット数じゃなくて、コードの総量。

> 京がCとFORTRANのユーザー割合を公開していた気がしたが、出てこないんだな。
さっきのPDFに書いてあるとおり、FORTRANが1位だよ。

2019/12/29(日) 11:04:58.14

>>443
> 今時はPythonで書かせろゴラアで、NumPyだCythonだが出てきてるわけだろ。
その辺は科学数値計算よりデータサイエンス系で盛り上がってるだけで、
色々余計なレイヤーがかぶさってるPythonが数値計算でnumpy、Cythonがあったとしても採用されにくいと
思うけどな。それこそメモリまわりの挙動とかで。

あと、tensorflowを例に挙げてHPCがどうこうと言ってたけど、ディープラーニングとかHPCの1ジャンルでしかないし、
ディープラーニングの分野ではFORTRANが使われてない、以上のことを示してないよ。

で、なんでそんなに他人の違う意見に対して「自分は正しい。お前の現状認識は間違ってる」と自信満々に言えるの？根拠は？
聞いてる限り聞きかじりの知識ばかりで実際に作らずに良し悪しを決めつけてるようにしか思えないんだが。

2019/12/29(日) 11:46:41.74

ここはC#スレだぞ

2019/12/29(日) 13:00:01.09

ワッチョイスレなんだから各自NGすればよろし

2019/12/29(日) 13:26:29.34

日経Linux 2020/1月号に、
米田聡の記事「AI で鳩を自動認識、ラズパイ4 で3倍速」が載っている

TensorFlow Lite を使う、Google のEdge TPU の2製品、
Coral USB Accelerator, Coral Dev Board

CUDA なら、CPU の1/50 ぐらいの時間になる

ここは、C# のスレなので、以降は他のスレで議論してください！

2019/12/29(日) 14:36:52.40

>>452
概ね全面的に水掛け論だからまあもういいが、一応反論だけはしておく。

> いくらでもある。当然売りになる。というかセキュリティ要件で満たさなきゃいけない。
いや逆じゃね？ローカルにUSBメモリ刺してexe/dllを直インストールなんてセキュリティが厳しい要件で許可されるのか？
まあいいが。

> Pythonしか書けないってんじゃなければWinFormsの方がましとすぐに気がつく。
だから言ったとおり俺はPythonを使ってない。
> WinFormsの方がまし
ただ、これはない。Formsは壮絶にゴミだ。それはHTML/CSS/JavaScriptを使えばすぐ分かる。
同様にWPFもゴミだが、Formsよりは数倍ましだ。
そしてWPFがHTMLに寄せたのはMSもそっちの方が断然いいと判断したからだ。
ただ、まだCSSが当てられないのが相当痛い。だから次は丸々HTML/CSSに寄せるはず。
（というかWeb開発では事実上そうでしかないが)

そもそもPythonもそっちに動いているっぽいだろ。>>446の頭の2つ、
> Cross-Browser Frameworks
は多分それだよ。Pythonでローカルに鯖を立てて、それをブラウザで見るんだよ。(かそれに近い形式）
というか俺なら最初からそうする。
つまり計算用PythonはJSONインタフェースだけ付けて終わりで、後は全面的にHTMLの恩恵を受けられる。

HTMLの良さが分からないのは、君が知らないからでしかない。といっても別に難しいものではないから、やってみればいいんだよ。
やれば、悲しいくらいに簡単にGUIを作れて、Formsとか本当にゴミだと実感出来るようになる。

2019/12/29(日) 14:37:27.40

> あとgithubのグラフの読み方は間違ってる。コミット数じゃなくて、コードの総量。
間違いは認めるとして、いずれにしてもナンセンスだからこれは止めよう。
BLASはAPIであって、当たり前だがOpenBLASは一つの実装でしかなく、
Cにもポートされているのだから当たり前のように同量のソースはあるし、
そもそもcommit回数を競ったところで意味がない。
BLASが使われるのがFORTRAN経由かC経由か、他の実装も含めての割合が問題であって、それはGitHub見てても分かりようがない。
君が示したのは、「今でもFORTRAN向けBLASの一つの実装がアップデートされている」という事実だけでしかない。
（それでも俺にとっては十分驚愕だが）

> さっきのPDFに書いてあるとおり、FORTRANが1位だよ。
本当にそうだったら「うええ、老害め」みたいに記憶に残ってるはずなんだがなあ。
と言っていても本当に水掛け論だから、こちらも調べたが出てこない。
ちなみに文部科学省のアンケートは出てきたが、これにはユーザー割合は載ってない。（ただし2006年の資料であり、相当古い）
https://www.mext.go.jp/b_menu/shingi/gijyutu/gijyutu2/022/shiryo/__icsFiles/afieldfile/2012/06/11/1321896_7.pdf
インストールされているのはFORTRAN100%、C92%なので、その当時はCが使えないスパコンってのも存在したのも事実のようだ。(P19)
> その他、スーパーコンピュータセンターからのコメントから、ＦＯＲＴＲＡＮ７７からＦｏｒｔｒａｎ９０への移行、
> あるいはＣ＋＋
への移行等、より記述性や生産性の高い言語への移行が進んできている印象を受けた。
君は移行すらしてない、という見解なんだろ。なんだかなあ。

> それこそメモリまわりの挙動とかで。
何が言いたいのか分からん。
Cのdllを呼んでるだけだぞ。C#でならunsafeでCのdllを呼んでるのと同じ。
全く問題ないし、関係ないよ。だからこれについてはC#でも何でもいいわけだが。

2019/12/29(日) 14:38:02.85

> ディープラーニングとかHPCの1ジャンルでしかないし、
> ディープラーニングの分野ではFORTRANが使われてない、以上のことを示してないよ。
今寄ってたかってホットなのは明らかにここだし、これを外して何を言うんだ？
問題は、こういった新しい環境ではFORTRAN向けの環境整備なんてされてない、ってことなんだよ。
だから正確には、「新しいHPC環境ではFORTRANは使えない」だよ。

俺は君が
> スーパーコンピュータで科学技術計算する分野では今でもFORTRANが主役だけど(>>438)
という明らかな嘘を言ったことを咎めている。
「環境自体がない」んだからそんなわけがないだろ。
何も知らない若い奴らが信じてしまう可能性もあるのだから、明らかな嘘をついてミスリードするようなことはするな。
色々見解が違うのはいいとしても、これはねえよマジで。

2019/12/29(日) 14:51:21.50

WPFはHTMLに寄せたんじゃねえよ。
XMLとしてvalidだろ。

2019/12/29(日) 15:06:33.85

>>460
C#er的公式見解がそうなのは知ってる。
ただ、機構は丸パクしてるだろ。

HTML/CSS/sjavaScriptのよい点は
A. テキストで書くだけ。ボタンなら"<button>Click Me</button>"だけ。
B. CSSが当てられる。
C. イベントがバブルする。
D. JavaScriptから値を弄ってもイベントは発生しない。
E. イベントは非同期、つまり必ずキューイングされる。

で、WPFは（といっても俺は使ってないが）
A. はまあ許容範囲（もうちょっと簡単に書かせろよとは思うが）
B. 出来ないのが悲しい
C. 問題なし
D. E. 知らない。Formsはイベントが発生してしかも同期イベントなので地味にこれがものすごく使いにくくて糞。
　直っていることを期待するが、そもそも俺はWPFを結果的にスキップしそうになってる。

だろ。AはXMLからとしても、Cはパクったろ。
そしてCは地味に素晴らしい。
といってもFormsから移行した奴らは活用してないかもしれんが。

**456** (ﾜｯﾁｮｲ ae2c-fJ/L) · 2019/12/29(日) 15:10:58.86

VSCode で良い。
markdown も表示できるし

Python は、Jupyter Notebook でも良い。
Julia, Ruby でも使えるし

VSCodeは、Electron だから、Node.js + Chromium だろ。
Ruby の標準サーバーを立ててもよいし

2019/12/29(日) 15:26:07.21

>>462
ルビ糞は教祖様推奨のEmacsを使えカス

**デフォルトの名無しさん** (ｽﾌｯ Sd94-hoej) · 2019/12/29(日) 15:26:34.81

コントロールに適用したいStyleがあるので、Generic.xaml を作成して、
App.xaml で ResourceDictionary.Merge Dictionaryしました。その中で自作のコンバータークラスを使いたくて定義したのですが、どうしても認識してくれません。ビルドは通るのですが、実行時に見つからないエラーがでます(xaml parse exeption)
同じ定義を App.xaml の中で、Generic.xamlをマージする前に書くと、何故か実行時にエラーも出ませんし、ちゃんと動きます。
Generic.xaml の中でコンバーターを定義することは出来ないのでしょうか

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を使い、
え？この関数しかないの？こんなんで出来るの？スゲー、みたいな構造になってたりする。
そういうところは勿論馬鹿にしてないし、するはずもない。

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