X

C#は糞2.0

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
垢版 |
2010/04/30(金) 15:25:27
前スレ
C#は糞
ttp://pc12.2ch.net/test/read.cgi/tech/1246520657/
0271デフォルトの名無しさん
垢版 |
2010/05/18(火) 21:18:35
たとえばJUnitの@Testはどうやって処理されるかわかってる?
まさかソースコード解析してるわけないよね
アノテーションが無かったころはメソッドにプレフィックス付けてたんだよ?
0274デフォルトの名無しさん
垢版 |
2010/05/19(水) 07:35:12
WPFは高速でもなんでもないし。
むしろ普通のWindows Forms使うよりメモリいっぱい食って遅いし。
0275デフォルトの名無しさん
垢版 |
2010/05/19(水) 09:47:57
C#はメモリくいすぎ
所詮、近々のハードの性能に頼っているだけにすぎない
逆にハードが優秀な近々ではC#を使う必要もない

C#は糞ってか、糞の糞だね
0278デフォルトの名無しさん
垢版 |
2010/05/19(水) 10:27:43
低能の叫びが聞こえるなｗ
0279デフォルトの名無しさん
垢版 |
2010/05/19(水) 10:47:57
近頃の4GBなどの大容量メモリとか高速のCPUとか
ハードウエア性能に頼って
C言語のようなポインタなど低Lvな処理を隠蔽し
バカでも作れるようにしたのがC#
0280デフォルトの名無しさん
垢版 |
2010/05/19(水) 10:53:24
>>279
いいこと言った
0281デフォルトの名無しさん
垢版 |
2010/05/19(水) 10:53:50
C#だからメモリを食うなんてことはないけどな。間抜けなコード書いてるか、仕組みを理解していないんだろ。
0284デフォルトの名無しさん
垢版 |
2010/05/19(水) 11:56:29
>>279
ポインタは問題無く使えると自信満々に言ってた中途採用の社員がポインタ関連でバグ多発。
そんな彼を救うツールとしてC#役に立ってる。
0285デフォルトの名無しさん
垢版 |
2010/05/19(水) 12:06:24
>>284
そもそもポインタを指標にしている時点で無能なのが伺えるな
あんなん誰でもできるし、目安にもならない
ただ、無能は君には難しかったようだね
俺らはポインタなんぞ、例えるならinclude1文程度の労力もかからないのだよ
無能な君には理解は早すぎたかね
0287デフォルトの名無しさん
垢版 |
2010/05/19(水) 12:28:40
>>285
日本語でおｋ
0288デフォルトの名無しさん
垢版 |
2010/05/19(水) 14:58:22
すげー
マイクロソフトのアプリケーションとかでも
たまにポインタ関連と思われるバグがあるのに
それを「誰でもできる」って・・・

ドンだけ上級基準だよｗｗｗ
0291デフォルトの名無しさん
垢版 |
2010/05/19(水) 18:22:52
>>259
制限っていうのは、まさかMVMやVisual J++の裁判の話か？
だとしたら>>260とは話が噛み合ってないと思うんだが。

あれが制限だというなら、あれは正しい選択だったと思うがね。
JavaScriptのように、MSが独自のJScriptという似て非なる仕様を乱立させたり、
C++のように多機能で仕様が乱立して悲惨な目にあったらJavaのWrite Once, Run Anywhereが完全に失われていただろうし。
今でもその思想は完璧ではないにしても、ポリシーとしてずっと持っているわけだし。


できるかぎりWrite Once, Run Anywhereを守ることでJavaの価値は守られていると思うわけだ。
0292デフォルトの名無しさん
垢版 |
2010/05/19(水) 18:25:08
>>266
Javadoc依存はなにかと問題あるだろ。
コンパイラはコメントを無視できる上
実行時に守らせたいことをコメントだけで補うことはできないから。
あと、Docletの仕様が中途半端だったこともあげられるかと。
0293デフォルトの名無しさん
垢版 |
2010/05/19(水) 23:40:52
アノテーションやカスタム属性って極端に言えば勝手な言語拡張を合法化する機能だよ
0295デフォルトの名無しさん
垢版 |
2010/05/20(木) 00:37:45
>>293
言語の拡張はできない。
命名規則をつくることによるソーシャルな方法や static method でも実現できること。
0297デフォルトの名無しさん
垢版 |
2010/05/21(金) 11:01:17
そりゃ、有名会社でバリバリ開発して忙しい人は
こんなところに悠長にくだらんこと書いてる暇ないだろｗｗｗ
0298デフォルトの名無しさん
垢版 |
2010/05/21(金) 11:07:48
有能なほど、さぼりや時間の使い方も巧く、残業もしない
低能ほど、小休憩さえも取れず缶詰、残業の嵐
0299デフォルトの名無しさん
垢版 |
2010/05/21(金) 11:13:29
で、そのさぼってる時間や残業の無い時間で
趣味でコード書きまくってるから有能なやつは忙しくて時間ない。
0304デフォルトの名無しさん
垢版 |
2010/05/21(金) 16:05:48
>>303
そうです、私が変な厨です
0305デフォルトの名無しさん
垢版 |
2010/05/21(金) 16:26:46
>>291
MSがJava言語を拡張したところはネイティブとのインターフェースだけ。
もとからJNI使ったら、Write Once, Run Anywhere は失われるんだから、
MSのWrite Once, Run Anywhere にはなにも影響しないという考えも変ではない。
まあ、標準ではないライブラリが広く使われるようになると、
将来MSのVMがSUNのVMを駆逐していく可能性もあるし、SUNも嫌だっただろうな。
0309デフォルトの名無しさん
垢版 |
2010/05/22(土) 16:09:11
>>305
Visual J++はJavaをあたかもActive Xの一部とみなして
初心者や技術素人を騙すために使われたものだぞ
ネィティブで動かすこと前提に作られているからな
「Javaはネイティブで動かした方がよい」と勘違いするヴァカを量産する
恐れがあったからSunは裁判を起こした。

MSのVMがSunのVMを駆逐？　ありえないなあ
セキュリティの件で終わってるから
VM自体はかなり乱立しているが
0313デフォルトの名無しさん
垢版 |
2010/05/22(土) 22:35:29
Javaはもうただの劣化C#になり下がっちゃったからな。
仕様も後追いでパクリまくってるだけだし。
その上、素性が悪いからパクリ切れてないし。
完全に限界にぶち当たってるよ。
0314デフォルトの名無しさん
垢版 |
2010/05/22(土) 22:41:33
なんでJavaってenumに対するswitchといい、interfaceといい、static importといい、
定数をクラス名で修飾するのを嫌うんだろう
その割にはインポートするクラスを全部明示的に書いたりするわけのわからない文化があるし
0315デフォルトの名無しさん
垢版 |
2010/05/22(土) 22:59:56
JavaにはLINQやラムダ式を導入してほしい
この二つめっちゃ書くのが楽だし、集合脳や遅延評価の使い勝手がよく分かる
0317デフォルトの名無しさん
垢版 |
2010/05/23(日) 15:07:52
>お前が低能なのも、書き込"む"でよく分かるけどな
それはひょっとしてギャグで言っているのか。
0322デフォルトの名無しさん
垢版 |
2010/05/24(月) 01:13:16
>>313
パクリ切ったらただのパクリだろう
Javaに新機能を追加するまで検証に多大な時間を費やしていることはご存知かな

C#ではそういう検証をろくにやっていない結果が今の状況だ

>>314
文化は言語とは直接関係ない話だな。
明示的に各理由はjava.sql.Dateとjava.util.Dateのように同名のクラスを
使った場合の対処などだろう

定数をクラス名で修飾するのを嫌う仕様にはなっていないはずだが
Math.sqrt(1)とかきたければ従来通りそう書くこともできる。
static importによってsqrt(1)と短縮することもできる。
Checkstyleを使ってstatic importを禁止することもできるが。
0324デフォルトの名無しさん
垢版 |
2010/05/24(月) 01:35:39
>>315
C#のLINQのサンプルをみたが
http://www.atmarkit.co.jp/fdotnet/special/cslinq01/cslinq01_01.html
必要性を感じないなあ

O/Rマッピングフレームワークには不満？

C#のラムダ式のサンプルもみたが
http://www.atmarkit.co.jp/fdotnet/csharp30/csharp30_01/csharp30_01_02.html
かえってソースコードを読みにくくする要素が多いなあ
匿名メソッドの処理が複雑化してくるとラムダ式には限界があるしなあ
単純な処理しかしない匿名メソッド以外にメリットを感じないなあ

ビーデー川俣はYAGNIYAGNIいってるけど

こういうサンプル見ると「if文は冗長だから三項演算子を徹底的に使え」といってる人を思い出すんだよなあ
0325デフォルトの名無しさん
垢版 |
2010/05/24(月) 01:37:34
>>323
Java Community Processのような組織がC#にはないことと
Javaではよろしくないとされていた仕様がC#にはたっぷりあるわけだけど
たとえば構造体やunsafeとか
0326デフォルトの名無しさん
垢版 |
2010/05/24(月) 02:11:27
>>324
お前はJava7のクロージャには文句言わないのか？
迷走して未だに入るのか入らないのかハッキリしないとこなんか実にJavaらしいな。
0327デフォルトの名無しさん
垢版 |
2010/05/24(月) 08:54:43
>>324
if文と三項演算子は等価じゃないし、三項演算子でスマートに書けるものを
ifでだらだら書くのはよろしくないぞ。
0328デフォルトの名無しさん
垢版 |
2010/05/24(月) 08:55:22
>>325
> 構造体やunsafe
それらは、中途半端なGenerics同様JavaのVMの仕様が時代遅れなので導入できなかっただけ。
0329デフォルトの名無しさん
垢版 |
2010/05/24(月) 15:56:51
>>324
それは貴方がラムダ式とLinqの使用経験が浅いか、全く無いからです
ラムダ式とLinqを使ってプログラムを組んでいると、同じプログラムを簡素に
短く書ける事に必ず気が付きます
0330デフォルトの名無しさん
垢版 |
2010/05/24(月) 16:14:15
>>310
VJ++が糞って使ったこともなく言っているだろ。
当時の同類の製品の中で飛びぬけてよくできていた。
0332デフォルトの名無しさん
垢版 |
2010/05/24(月) 18:58:30
そして返り討ちに遭った
0333デフォルトの名無しさん
垢版 |
2010/05/24(月) 19:13:26
>>324
LINQはSQLの代用じゃなくて、集合として扱える点が利点。
RDB、XML、オブジェクト等、同じLINQで取得したい集合値を加工できる。

ラムダは関数型言語に少し嗜めばメリットが分かるよ。
端的にかけることも利点だが、遅延評価で必要な時に処理が行われることがメリット。
0334デフォルトの名無しさん
垢版 |
2010/05/24(月) 19:33:54
メモリ内に集合ぶち込めていじくれる所がLINQのいい所じゃね？

LINQ to SQLだったら、SQLインジェクション対策に内部的なSQLを吐いてくれる
が速度は遅めだからあんまオススメしないけど、データ量少ない中小規模なシステムだったらスピィーディーに作れる
0337デフォルトの名無しさん
垢版 |
2010/05/25(火) 08:57:17
>>327
Checkstyleのデフォルトでは三項演算子は紛らわしくミスを誘発しやすいので
使うなって警告がでるぞ。

0338デフォルトの名無しさん
垢版 |
2010/05/25(火) 09:02:19
>>328
Genericsはよくできているが
qJavaのVMをどんなに進化させてもC#の構造体とunsafeをそっくりそのまま導入する
のは無駄だと思うけど。無理にunsafeを導入するほうが時代遅れな発想にみえるけど。

JNIでできるのに無理にunsafeを導入する必要性を感じないなあ。
それこそC#はそういうところが中途半端。

0339デフォルトの名無しさん
垢版 |
2010/05/25(火) 09:03:29
>>329
>>324のサンプルは確かに短いけど
大して短くなっていないんだよね
もっと説得力あるサンプルもってこないと
タダの煽りでしかないよ
0340デフォルトの名無しさん
垢版 |
2010/05/25(火) 09:06:34
今ない機能は全否定
今ある機能は全肯定

〜信者同士の罵り合いで定番のパターンですね
0342デフォルトの名無しさん
垢版 |
2010/05/25(火) 12:29:40
>>326 >>333
RDBの処理はO/Rマッピングフレームワークで解決
XMLの処理はデータバインディングフレームワークで解決

あまり魅力を感じない

サンプルを見たところ
自分でコードを書く分にはプラス要素はそれなりにあると思えど
他人がこういうコードを量産したら解読にいつもより時間がかかって手間がかかりそう

ソースコードがますます汚くなる危険性を孕み
導入したら導入したでかなりのリスクを背負い込むと見た
enumやGenericsのようにC#のLINQをそっくりそのまま導入することはないのではと見た

0343デフォルトの名無しさん
垢版 |
2010/05/25(火) 12:32:35
>>340
言っておくけど、俺はC#のenumがでたときに
C#とC++にはenumがあるのにJavaはenumがないから糞という意見に対して
C++やC#とまったく同じ仕様のenumは否定したけどJavaのenumは否定してないよ
Javaのenumと全然仕様が違うからね

Javaでもクロージャが導入されてもLINQとまったく同じ仕様にはならないと思うよ
むしろなったらとんでもないことになる

0344デフォルトの名無しさん
垢版 |
2010/05/25(火) 13:04:37
>>342
サンプルコードを見たところって言っている時点で、使ったことないじゃん
自分で使って有用性・不便性を感じ取って、業務レベルで使いこなしてからじゃないと
0345デフォルトの名無しさん
垢版 |
2010/05/25(火) 14:30:44
業務レベルｗ
業務レベル基準が各々脳内だからなあｗ
C#の仕事を引き受けるまで無理って言いたいのかねｗ

有用性はともかく不便性なんかすぐにわかるわな


C#の??演算子とか
必要性ないのばっか

そういう低レベル機能を追加すればするほどC#も徐々にC++化してくる罠
0346デフォルトの名無しさん
垢版 |
2010/05/25(火) 14:53:18
C#のGenericsとは全然仕様が違うからね。

JavaのGenericsは単なる糖衣構文でしかない。
値型のパフォーマンスは大きく劣り、実行時に型パラメータを参照しリフレクションで利用することも出来ない欠陥品。
0347デフォルトの名無しさん
垢版 |
2010/05/25(火) 15:03:29
>C#の??演算子とか
>必要性ないのばっか
>
>そういう低レベル機能を追加すればするほどC#も徐々にC++化してくる罠
??演算子と低レベル機能って何一つ関係してないな。
0352デフォルトの名無しさん
垢版 |
2010/05/25(火) 15:24:35
業務レベルを卑下して、サンプルコード見ただけで分かった気のいる人って、品質管理のレビュアーとしては天才やで
0360デフォルトの名無しさん
垢版 |
2010/05/25(火) 23:12:15
クラスライブラリや言語の設計上、構造体のコピーが発生して効率が悪くなりやすかったり
クラスのオブジェクトの生成や短寿命オブジェクトのGCが非常に高速だったりしてあまりメリットがない場合が多かったりするけど
構造体自体のパフォーマンスは悪くない
0364デフォルトの名無しさん
垢版 |
2010/05/26(水) 00:49:40
値型と参照型、値渡しと参照渡しを直交した形で書き分けられて、
必要に応じて自動ボクシング、キャストによるアンボクシングができる
って言語は実は少ないのではないだろうか。
0365デフォルトの名無しさん
垢版 |
2010/05/26(水) 01:30:06
構造体はスタックに確保されスタックポインタでアクセスできるためクラスより僅かに速く、大量に使い捨ててもGCに影響しない。
そうは言っても、クラスが十分に速いので速度面の理由で構造体にするのは稀。ネイティブとの相互運用のために使う事が多いだろうか。
誤用するのは何も知らない初心者ぐらいだろ。

>>355
C#のGenericsは値型を入れてもボクシングされないので高速。
Javaではintなどのプリミティブ型であっても強制的にボクシングされるため低速。（参照型しか扱えない）
これもJavaのGenericsが欠陥品だって言った理由の一つな。
0367デフォルトの名無しさん
垢版 |
2010/05/26(水) 19:05:54
JavaのGenericsは、妥協の産物としてはよくできているし、オブジェクトを入れる分には効率はC#方式と変わらない。
もちろん、どちらが優れているかといえば、C#。
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況