C# vs Java どっちが好き? その4©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
例えばさ、VSがPythonをサポートしましたよとか、WindowsがLinuxをサポートしましたよとか、これ結局、PythonユーザーやLinuxユーザーをWindowsに取り込みたいからやってるわけで、その逆になっちゃダメなわけよ。
使いやすくなるわけがない。 >>130
俺は古くからのVS、Windows、Linuxユーザーなので本当はOSXの台頭を好ましく思っていないんだよ。
ところがその俺でさえOSXを使うしかなくなってきてる。
ホント苦々しい思いだわ。 VSがより便利になって嬉しいだけだけど
開発環境は全部統合して一つにして欲しい
その可能性があるのは今のところVSって事
資金力も開発力も交渉力もダントツ 俺が最初に買ったOSはPC-DOSだし、その上にWindows3.1入れてたんだよ。
その当時友人が80万出してMac一式そろえたんだけど、俺のDOS/Vは全部で20万もしなかった。
それにLinuxはELF移行を進めてた頃に使い始めた。
1996年くらいだな。
その位昔から使ってるから、今更Macなんてちゃんちゃらおかしいけど、それしか選択肢がない。 >>133
OSX使ってみれば考え変わるよ。
結局、MSの流儀に従って改変されたOSS使うより、端からUNIXのOSXのほうが楽ちんすぎる。
Windowsでの苦労は何だったんだって思うはず。
Microsoftは考え変えてほしいわ。
変えなければ10年後にはシェアが逆転してるだろう。 そもそもム板でOSXをOSの一つとして認める奴がいることのほうが驚き。
普通にBSDの括りだろ。 VS使ってる皆さん、上手くいかないのはあなたのせいではありません、Windowsのせいです。
OSXお試しあれ。
僕の言ってることがわかるはず。 もしBSDが楽チンならLinuxより普及してる。そもそもハナからUNIXというのが詐欺。
BSDカーネル開発本家がUNIX取得してないのに、自分だけUNIX取得して名乗ってんだから。Appleって根っからの詐欺師。 >>139
そんな銭ゲバのApple製品が一番ユーザーの方を向いてるのが問題なんだよ。 なんかメリットを明確にせずに
本物はHaskellを使う
みたいなこと言われても
ふーん、死ねば？
としか >>140
まさかム板の住人がAppleのユーザー切捨ての歴史を知らないとでも思ってるのか。
マカーってほんと馬鹿だよなぁ。 >>143
そんなAppleのほうが楽ちんな現状。 >>144
お前、詳細な具体例挙げないとNG入れるぞ >>144
AppleにMSのプレミアムサポートレベルのものを用意できるというのか？ 自社でOS開発してないのに。 iOS開発とハードウェアのクォリティを除くとMacもWindowsも大差ないよ
>>131
時代遅れの発想
MicrosoftはWindowsなんかどうでも良くて、開発者にAzureを使わせたい
AppleもOSXはどうでも良くて、iOS端末を買ってほしい UTF-8のBOMも随分長い間ユーザーを困らせてきたよな。
頑なにUTF-8を認めず、手動で設定したとしても保存するたびにせめてBOMだけはつけようとするVSと、UTF-8のBOMは絶対認めないGCC。
そんな時AppleのCLangは光って見えた。
そしてCLangがLinuxユーザーにも光って見えだした時、とうとうGNUが折れた。
マンセーし続けてたらGNUは折れなかっただろう。
なんせMS憎しという宗教なんだから。
そしてVSはいまだに折れません。 そもそもLinuxは文字コードなんていくらでも変えられる。
過去の資産なんてないんだから。
あったっていつでも捨てられるゴミみたいなもんだ。
TeXやroffの問題さえ誰も提起しない。
過去の文書が読めなくても困っていないんだ。
Linuxで作った文書なんてゴミだから。
ゴミだからLinuxで作ったのだろう。
これがExcelだったら大問題だっただろな。
いや実際、環境によって開けたり開けなかったりする文書が作れるんだから文句は言われてる。
同じ事情のTeXに誰も文句を言わないのはゴミすぎて誰も使っていないからだろ。 スタイル警察入れて大文字小文字ルールと、スペーシングルールをチェックさせるようにしたわ >>150
UTF-8 にどうして BOM(ByteOrderMark) が必要なのですか？ >>155
それって BOM(ByteOrderMark＝バイトオーダー判定用マーク) が本来持っているべき役割でしょうか？ ではBOM以外の方法でUTF-8かどうかを判定する方法を提案してください
もちろん誤認識や互換性などの問題が発生してはいけません >>157
BOM って UTF-8 というよりは UTF-16, UTF-32 に使われるマークですよね
BOM ですら UTF-8 と UTF-16LE/BE とかとを区別できないのに、それ以上の方法が他にあるわけないでしょう？ 判定以前に、指定できるようにしたら良いだけなのだが。 FSFとMSは相互運用性を無くせば相手が困るだろうと考えた。
そして執拗に相手が悪いのだと言い張りながら互換性の問題を取り込んでいった。
困ったユーザーたちは、OSXに移行するという解決策を見出した。
これはうまくいった。
OSXなら問題が起こらないのだ。
2000年代のサーバーサイド開発者はDebianを使っていた。
2010年代はOSXを使っている。
その結果、FSFが折れた。 2つ質問がある：
1. FSFが無くそうとした相互運用性、とは具体的には何？
2. 「FSFが折れた」とは具体的にどのような事で「折れた」？ Appleの方が遥かに全方位排除仕掛けてると思うけどな
仮想マシンのゲストで使えないし
iOSアプリはMacないと作れないし youtubeにしても著作権違反した動画が溢れかえっている。 >>169
いや、おまえの頭の中にお花畑があるのが問題。先日、アメリカで銃規制の大規模デモが行われた。
犯罪に使う奴が悪いというおまえのような論理では、世界はAppleやGoogleのようなパクり屋の世の中になってしまう。 YouTubeの話が何で銃規制の事になるの？
何の関係があるの？ youtubeも著作権違法動画を持っていれば防げた話 >>170
この方は何をしてる人なんだろ
それなりに詳しそうだし
歳は行ってそうだけど >>171
そうか。春休みだからそこから説明しなきゃいけないのか。では分かりやすく説明しよう。
ゆとりは馬鹿だと言われるだろう？ なぜだと思う？簡単な話だ。勉強してないからだ。
では勉強しなかったゆとりが悪いのか？ そうじゃない。教師が楽をするためのゆとり教育システムを官僚と一緒に構築したからだ。
軍事産業は銃を売り、ジョブスは電話タダ掛けハッキングツールを売り、Appleは著作権保護システムのない音楽プレイヤーを販売し、
Googleは違法動画Upサイトで広告収入を得、公務員教師は仕事せずボーナスをゲット。すべて本質は同じなのだ。
悪用させる道具やフレームワーク、システムが一番お金になるのだ。
そいつらが本当の悪人なのだ。 話が脱線し過ぎだって
YouTubeの事なのに教育問題までになっちやったよ いやはや皮肉すら受け取れなかったか。頭の悪さはホンモノのようだ。 根本原因と称しておおよそ関係ないところに問題をなすりつけるＳＥの鏡 >>174
貴方のオススメの言語や開発環境は何でしょうか？
今後の自分の勉強の為にも興味あるので教えてもらえますか？ 今のVBやRubyがそうであるように、数年後、「C#なんて使うのは馬鹿」と言われる気が
する。誰でも使えるが効率が悪いイメージが付いて。 Python, PHP, HSP なんかも馬鹿にされてる。
それは、誰でも使えてしまうから。 誰でも使えるのがC#の良い所てしょ
難解なのが良いの？ 一説によると、誰でも使える言語は低レベルな人が流れ込んでくるから
成果物も低レベルになり、それが言語自体の印象になってしまうらしい。
それと、他人の作った成果物る今まで見てきた限り、C#は遅い。 誰でも使いやすいってのは貴方が推奨しているオープンな技術に繋がると思うんだけど >>187
C++ はひどい言語だ。これは、多くの平均以下のプログラマーが使ってるために
さらに輪をかけてゲロゲロになっていて、どうしようもないゴミが
簡単に生産されるようになってる。正直いって、C を選ぶ理由が C++ プログラマーを
追っぱらうため *だけ* だったとしても、それ自体、C を使う強力な理由になりうる。
C++ はトンでもなく悪い設計の元になりうる。どうせこの言語ではいつも STL やら
Boost やら、その他ゲロゲロベロベロの「素敵な」ライブラリの機能を使って、
それがあんたのプログラムに「役立つ」んだろうが、以下のことが起きる:
- うまく動かないときにもたらされる際限のない苦痛 (あと STL とか、特に Boost が
安定してるとか移植性があるとかいう奴は、どいつもこいつも大ウソつきで、
もはや笑えるレベルを超えている)
- 非効率な抽象プログラミングモデルで、2年たった後にこれらが実はそんなに
効率的じゃなかったことに気づくケース。でもそのときにはすでに全部の
コードがその素晴らしいオブジェクトモデルに依存していて、直すためには
アプリ全体を書き直さなきゃなんない。
言いかえれば、唯一まともで、効率がよくて、システムレベルで使えて、移植性がある
C++ ってのは、基本的に C で使える機能だけに限ったときなんだ。そして C だけに
限定するってことは、他の人がそれをめちゃくちゃにしないってことで、
ついでに沢山のプログラマが実際に低水準の問題を理解することができて、アホらしい
「オブジェクト・モデル」のたわごとを持ちこまないってことだ。 >>189
ちなみに、C++暦は長いが、STL や boostを 一回も使った事がない。 >>189
オブジェクトモデルなんてたわごとを持ち込んでもらっても一向にかまわないが、テンプレートは煮ても焼いても食えないな。
と、beast使い始めて思いました。 そういえば、boost やらは、変な感じだったな。
特に、リストのイテレータが、C/C++の設計思想と合わない気がした。
本来は、もっと単純に出来る。あれだったら、イテレータを使った方が
コード全体としては開発効率が下がるかも。 >>188
2つ間違いがある。
1. 誰でも使いやすい事と、オープンな技術である事には、特に相関はない。
2. 「オープンな技術」を推奨しているわけでもない。 >>189
1. 個人的には、リスト・テンプレートなんかは自作したものを使ってる。
2. 個人的には、文字列は、MFCのCString を使ってる。
3. 確か、boostの作者は、SmallTalkか何かに傾倒していたらしい。その結果、C/C++の本来
想定していたやり方とは大幅に異なる習慣を無理やり使うような設計となっており、
C/C++の良さが生かせず、変に悪い面ばかりが目立つようになっている。
4. 新しく登場してきた概念やライブラリ、言語などは、良いことばかりが語られる事が多い。
そして実際に使い込んでみてから、デメリットが見つけられて、クソ扱いされる事がある。
5. そして、長い時間が経った後でも良いと語られているものコソが真の良いものである。
6. 現在、C#は良いことばかりが語られているステージ。後からクソ扱いされるようになるだろう。 C#がクソ扱いされるにはC#を明らかに超える言語が出てこないとね。
現状ある？ リストテンプレート自作するのも結構楽しいよねｗ
メモリ周り高速化してみたり プロパティツリーも何とかしてほしいな。
属性の扱いが無理やりすぎだろ。
こういう時こそテンプレートの黒魔術の出番じゃないのか。
あと、黒魔術はライブラリのユーザーに見せなくていいから。
外出するときはパンティー履くだろ。 みんな参考にしてるサイトは何？
カッコつけて海外のとか要らんから普段から使ってる奴で boost.jp
lets boost
でも結局boost.org
そして見てもわからない。
※英語の国の人が見てもわからないはず。 >>202
MSDNとdobon.net
他、検索して当った皆様 MSDNの日本語訳とか最悪じゃね？
英語のほう見てんの？ ちなみに俺はstack over flow に丸投げｗ >>202
圧倒的にqiitaが多い
それ以外だと個人ブログかmsdnあたり C#使ってると、「see sharp」、つまり、SHARPの二の舞を見る事になる。
つまり、あなたの人生が倒産する。 カッコつけるもクソもあるか。
Googleの設定で英語の結果もチェック付けとけよ。情報量・質が段違いだぞ。
検索は英語ですれば英語のページも日本語のページも引っ掛かるぞ。
日本語混ぜると日本語のページしか出ないからダメ。
日本語のページでもいいのあることももちろんあるけど運だからな。マイナーなの調べなきゃならん時、情報の分母は大きい方がいい。 英語の情報なんて大したこと書いてないだろ。今の技術系情報の発信は中国サイト。 202です
なんつーの
やりたい事というか解決したい事が確実に分かってたり決まってたり検索ワードもバッチリ分かってる場合は英語サイトでも検索出来るけどもう少し手前のぼんやりな場合は日本語で検索しまくって調べるしかない訳なのでやっぱり日本語のサイトが知りたいです。
検索してるとQiiteが良く出てくるので参考にさせて貰ってます
msdnで解決したことは少ない >>210
無能経営者が置き換わってシャープ今大成功してるやん C++とC#の速度差については、FrontPageとExpressionWeb 4
を比べてみると良い。両者ともMS純正だが、後者は起動が非常に
遅い。これが、C++とC#の実力差なのではないか。 C#で書かれているとは公言されてないが、公言すると何か困るのだろうか。
察しよう。 C#はC++より遅い。当たり前だ。だがJavaよりは断然速いのだ。 マルチコア処理の場合最適化の関係でネイティブよりも.NETの方が速くなるっていう場合があるとかどうとか あんまりよく分からんのだが
C++ってMacで動くアプリケーション作れるの？ >>226
C++で、同じソースでWinとMacで共通に動くアプリという意味では、マルチ
プラットフォームのツールキットを使えば作れなくもないが、IDEの出来も良
くないし、険しい道を歩むことになる。Webアプリでよければ、Emscripten
を使って、C++をwasmに変換すれば、作れる。ただ、ビジネスアプリを作る
というなら、Widgetやツールキットに使いやすいものがまだ出てないと思う
ので険しい。一方、ゲームを作りたいというのであれば、今の段階でも
単一のC++のソースで、Emscripten、WebGL、Canvas、SVGで
Webアプリとしては、大体書ける。
この場合、C#の.Net Runtime(Frameworkと仮想マシン、JITコンパイラ)に
相当するのが、WebAssemblyを動かすブラウザ(Chrome、FireFox、Safari)
のエンジンということになる。
C#もWebAssemnly(wasm)もJavaもFlash(CrossBridg)も、VMか、
または、JITコンパイラでnativeに直して実行する仕組み大体は同じ。
このうち、wasmは、C++で書ける。 結論を言ってしまえば、C#と.Netの関係と、C++とWebAssembly
エンジン(?)の関係がほぼ同じ。
同じ仮想コードとしてVM上で動く共通点があるが、C++で
書けば、GCによる制御しにくい突発的な速度低下が起きない
メリットがある。
とこれ以上、詳細を語るとMSに伝わって、WebAssemblyのアド
バンテージが失われてしまうので書きたくない。 【訂正】
誤：C++で、同じソースでWinとMacで共通に動くアプリという意味では、マルチ
プラットフォームのツールキットを使えば作れなくもないが、IDEの出来も良
くないし、険しい道を歩むことになる。
正：共通のC++ソースでWinとMacで動くnativeアプリという意味では、マルチ
プラットフォームのツールキットを使えば作れなくもないが、IDEの出来も良
くないし、険しい道を歩むことになる。 ■ このスレッドは過去ログ倉庫に格納されています
