kamuy 曰く、 "日経IT Pro US NEWS FLASHから。ちょっと前から気になってたんですが、「米マイクロソフトのC#が人気急増中，過去半年で使用開発者が7％から12％に」という記事があるのですが、コレって「人気急増」という話なのでしょうか? なんとなく偏った見方であるような気がするのですが… それとも、プログラミングの世界ではそういう判断をするモノなのでしょうか? (単に私が偏っているだけ?)"
「急増」は正しい。 (スコア:4, 参考になる)
でも「人気」急増って書いてあると変ですよね。考えれば分かることなんですが、「人気急増」と「人数急増」は全く違うわけです。実際、ZDNet Japanとかでもこの件は伝えられてましたが、使ったことのある人の数が倍増したのだということを冷静に伝えてたはずだし、とりあえず試しに使ってみてる人が多くてメインの開発言語にしている人はまだ少ない、ということが書いてあった。
Re:「急増」は正しい。 (スコア:1)
「使える」のと「使っている」のは違いますからね。
Re:「急増」は正しい。 (スコア:0)
そんな人が多いハズ・・・ですよね？。
それよりもVB.NETがすごくいいです。(←あくまで対VB6比ですが・・・）
#無茶苦茶なプログラムを組んでいた人間はふるい落とされそうな仕様変更がとても素敵です。
Re:「急増」は正しい。 (スコア:1)
それってDelphiと差が無くなったって事でしょうかね？
VBは適当にプログラムしても何故か動いてくれるってのが一番の魅力だと聞いたことがあるので・・・
Re:「急増」は正しい。 (スコア:0)
目前にあるのは、暗黙の仕様がいっぱい使われた VB6 による謎のコード。
wc かけたら 10万行もあるし。
結構使える (スコア:4, 参考になる)
言語としてもよく考えられていると思うし、開発効率もいいし。
自分はC, C++, DelphiといろいろとやったのですがDelphiがＲＡＤとして比重を置いていますがC#はC,C++の中間みたいな感じで非常にバランスよく感じます。
自分が公開しているソフトもC#で書かれたものがありますが……。
あまり見かけないですがどのくらいの人がC#で書かれたアプリ作っているのでしょうか？
C#…なんとかして欲しい点……
１．マルチメディア関係のクラス、関数がほぼない（音を鳴らす、というレベルのものもありません）
２．ユーザーに負担を強いる（へたれプログラムを使うのに２０メガのダウンロードはねぇ）
それ以外では気に入ってるのですが……。
Re:結構使える (スコア:2, 興味深い)
曖昧な記憶なんですが、C#を設計した人って、Delphiを設計した人と同じじゃありませんでしたっけ。言語としては非常に素晴らしい出来だ、とその方が自信を持っているという話を聞いたことがあります。
...そろそろ.NETもさわってみようかなぁ。
C# の言語 設計者は James Gosling なのでは... (スコア:3, 参考になる)
僕が検証したところ文法だけ見て C# が Java と根本的に違うのは 5点のみ。
多次元配列の存在、primitive 型(C# では predefind 型)の call by reference、unsafe 構文の存在、check/uncheck、goto 文。
あと小さな違いとしては decimal 型とか、文字列定数の書き方とか、文字列を case にした switch 構文の存在とか。
残りは糖衣構文(syntax suger) のある/なしだと思います。
＃ 糖衣構文というのは、同じ書き方がもっと基本的な構文の
＃ 組み合わせで書けるのだけど書きやすさのために導入された
＃ 文法のことです。
＃＃ Gosling は糖衣構文を嫌う人みたいで、オペレータのオーバーロード
＃＃ 等を頑として認めなかったようです。言語屋さんなのねぇ。
逆に、Java にあって C# にない機能はほとんどないのですが、transient フィールド修飾子ぐらいでしょうか？
p.s.
C# が Java の駄目な部分に引きずられてしまった所もあります。
例えば synchronized文由来の lock 文にタイムアウト値が設定できないとか。後発なのだから直せば良いのに。
あとせっかく struct まで入ったのですから、親子関係のあるオブジェクトを連結する機能が欲しかった。
p.p.s.
C# の機能のうち一番 Java に移植して欲しいのはプリプロセッサ機能。
コンタミは発見の母
Re:C# の言語 設計者は James Gosling なのでは... (スコア:1)
まったく新しい概念て訳でもないでしょうが、
あれってナニゲに一番大きな違いのような気が。
Attribute (スコア:1)
もちろん標準で持つ意味はあるんで、あくまで感覚の問題ですが。
Re:Attribute (スコア:1)
元が Java との違いだったので、大事なの忘れてますよー、って事です。
例えば ZLib（deflate） を使いたかった時に DllImporrtAttribute を使ったんですけど、
マーシャリング方法やら含めて単に Attribute で指定しただけでネイティブメソッド呼び出しが
できたのは、(JNIと比べたら)単純に「便利！」と思いました。
（Java なら inflate くらい標準で持ってるって突っ込みはしないで・・・）
これは単なる例なので、本当はネイティブメソッドなんて
使わないで済めばそれに越した事はないですが、言語の可能性としては
面白そうだな、と。
言語標準機能なのにヤケに Windows 寄りな名前なのもアレなんですけどね。
別に C# が Java より優れてるとか（その逆とか）、まして C# は最高なんて思ってる訳ではないので、念のため。
Re:Attribute (スコア:0)
そうなると、あなたのおっしゃるMetaobject Protocolというものとどう違うのかよくわかりません。
Re:Attribute (スコア:1)
Re:Attribute (スコア:1)
AttributeUsageAttribute 自体もそうですかね。この辺りはリンケージ時と言うにはちょっと違うと思います。
コンパイラの実装次第と言える気もしますが、一応この辺りは C# ドキュメントの言語仕様に入ってるものですし。
（C# の標準案として提出されたものに入っているかは知りませんが）
あと AC さん、メタデータの仕様だから言語仕様じゃないとか言い出したら、C# に残るものなんて・・・。
バイトコードレベルには (スコア:1)
詳しくはここ [sun.com]。
ただ Attribute がつけられるのはクラス、メソッド、フィールドぐらいで、どこにでも自由におけるというわけではないです。
後、Attribute を自由に取り出す API は存在しません。
Java が attribute のような機構を積極的に使わないのは やはり組み込みを第一に設計され、サイズを小さくすることに注力したからでしょうね。
コンタミは発見の母
Re:C# の言語 設計者は James Gosling なのでは... (スコア:1)
１．#region / #endregion （上に出てますが）
２．#line がある。（ドロ臭いけど、トランスレータなんかを書くのにはやっぱり欲しいですよね）
３．VisualStudio.Net のエディタでコピーして、リッチテキストなどを食うアプリにペーストすると、エディタ上の文字の書体・色が保存される。
だったりします。
３.の機能は、私は他で見たことがなかったし、貼り付けてから、あれ？って感じで気づいたので、うぉ！と思ってしまいました。
あんまり書くと MS シンパと思われるので、もうやめます。
Re:C# の言語 設計者は James Gosling なのでは... (スコア:0)
あと、理論的な根本的違いは多くないかもしれませんが、現実として大きく異なってくる部
Re:C# の言語 設計者は James Gosling なのでは... (スコア:1)
私自身が .NET framework については学習中なので何かを言えるレベルには達していません。
＃ でも デジャビューの連続なのですが...
> あと、大きく違う部分としてユーザ定義の値型struct(C++のそれとは全く異なる)、
> これを入れないでどうしますか
あ、struct を書き忘れていました。でも概念的には C++ の struct そのものですよ。ポインタが取れないことを除いては。
私自身、C# の仕様を一読したときに "struct" を見つけた時には感激したものです(*1)。ただ struct は参照がとれない制限や、固定長であっても配列状のデータを取り込めない制限などがあり仕様用途は限定されます。私が眺めた範囲でですが CLI のクラスライブラリ中でも struct は有効な使い方をされていないように見えます。
個人的には、むしろスタック割り付けを指示する特別な new 命令があった方が嬉しいです。
// MyObject obj = new MyObject(); // ヒープ割り付け。
MyObject obj = alloca MyObject(); // できるだけスタック割り付け。
(*1)
私自身の本職は C# の struct に関わるところにあります。
Java においてユーザーに "struct" を書かせずに "struct" を使ったのと同じ効果を出す方法を考えているのです。つまりインスタンスの stack allocation と object inling をやろうとしている人間です。
コンタミは発見の母
スタック割り付け (スコア:0)
escape analysis (スコア:1)
unsafe はユーザー責任とはいえ、GC のある言語で dangeling pointer なんぞ作られたらたまりません。デバッグ不能です。
＃ でも似たような機構を realtime Java の仕様で見たことがあるような、ないような。
セキュアなスタックアロケーションをやるためには C# の struct のように制限をもうけてやる方法以外に、コードを解析することによって安全に割り付けられることを検証したり、参照が外部に漏れてた場合をランタイムで補償する方法があります。
私の関心はこちらにあります。
ただ、すべての new に対してをスタック割り付けが可能かどうか解析していくのはコストが高いので、ユーザーに「ここを解析しろ」と指示を書いて欲しい。そのための修飾キーワードが(昔の C 言語の register のように)言語レベルで欲しいと思っているのですが、如何でしょう？
コンタミは発見の母
Re:escape analysis (スコア:0)
うーん，そこまで言われると困りますなぁ．
いまこの場での議論でC#の規格を決められたらいいのですが．
で，まずは「stack allocation によるパフォーマンスの改善（可能性）」から「デバッグコスト」へと話題が増えてますしね．
私から見れば「dangeling pointer なんぞ作られたらたまりません」な人も「stack allocation によるパフォーマンス改善」を望む人もわりと他人事なので，何書いてもそれなりに妥当な返答が返ってくる当事者の方か
Re:escape analysis (スコア:1)
> ではfloat×16の行列を多用するのですが，これはSSEへの最
> 適化のため16byteアライメントするように推奨されています．
> これをC#から使えるようにしたとき，Microsoftがライブラリ
> にどういう実装を行うかには結構興味がありますね．
> 個人的にはアライメント用の属性を作るんじゃないかと思って
> ます．
アライメントの指定すること自体は属性で簡単にできると思いますが、問題は仮想マシンをどうつくるかです。
ガーベージコレクションの対象となるヒープ空間上では、GC によってオブジェクトが度々 移動します。そのたびにアライメントを考えてデータの構造や大きさまでをも組み替える必要があります。これは骨ですよ。
特定のデータに特化する手法を用いる場合なら、float×16の行列を扱う専用のクラスを作ってやればよいと思います。ヘッダーが 8バイトだとすると、オブジェクトの大きさを32バイト固定にしてアライメントによって行列部を前に詰めたり、後ろに詰めたりすれば実装可能です。
＃ CLR も 8バイト境界を採用しているでしょうから、詰め方は 2パターンしかない。
任意のクラスに任意のアライメントを指定する場合は面倒になります。
私ならオブジェクト毎にアライメントに関する情報を持たせる方法か、オリジナルのクラスからアライメントを特化させたサブクラスを作成する方法のどちらかを取ると思います。
前者の場合、オブジェクト毎にアライメント用のフィールドを余分に持つ必要がありますしアライメント指定のない通常のオブジェクトのアクセスに余分なオーバーヘッドが掛かるので後者の方が効率はよいでしょう。
p.s.
まったくの余談ですが、float 型の配列の配列部は 8n + 4 となる境界に載るという、数値演算系の人からみると冗談としか思えないような JavaVM の実装があります。
＃ オブジェクトが 8 バイトアライメントに揃っていて、各オブ
＃ ジェクトは 8 バイトのヘッダー情報を持ち、配列の場合は配
＃ 列長をしめす領域が 1 ワード(4バイト)が余分についていて、
＃ その直後から行列のデータ部分がはじまる。
＃＃ ということは double 型の配列も 8n + 4 境界からはじまる？、
コンタミは発見の母
Re:escape analysis (スコア:1)
> のかですかねぇ．
> 私が配列ベースで作業する場合は，記述性から Fortran とか
> Mathematica 使いますから．
C# の場合、多次元配列がはじめからあるので FORTRAN のプログラムをそのまま MSIL に変換してしまっているのではないでしょうか？
プログラムを一つのクラスとして、共通ブロックはグローバルなクラス変数、プロシージャ・変数を static メソッドとして置換すればよいと思われます。
無論、問題は最適化。
ループ最適化など高レイヤーの最適化は中間言語レベルでもある程度有効だと思いますが、software pipeling 等の命令レベルの最適化はレジスタが見えないとほとんど無理です。
＃ 少なくとも私は書けない。手袋を着けた状態で盲牌するようなもの。
CLR 側の JIT コンパイラは、売り物のコンパイラと比べると簡単な最適化しか入っていないようです。また、FORTRAN が相手にするようなプログラムだと JIT のメリットはそんなにありません。AOT コンパイルをじっくりやった方が特です。
＃ FORTRAN77 は virtual function call 以前に recusive call すらないので、
＃ 静的にコントロールフローグラフがきっちり書ける。
＃ 条件分岐もループ由来のものが多いので分岐方向は予測可能。
実際に Lahey/Fujitsu Fortran for .NET [lahey.com]のパフォーマンスに関する問言は非常に控えめです。ただ、native code に変換してしまう機能があるようなので、そちらを使えば従来と同様のパフォーマンスが出るのではないでしょうか？
p.s.
余談ですが、FORTRAN はコンパイラに演算の実行順序を入れ替えるような最適化を認めているので、浮動小数点演算ユニットが IEEE754 に準拠していたとしてもコンパイラによって計算結果が異なることがあります。
一方、Java は "Write Once, Run Anywhere" を掲げて、浮動小数点が誤差のレベルまで一致させんという高邁な理想を持っています。多次元配列がないのも痛いのですが、コンパイラ最適化の多くが禁止されるのがさらに痛いです。
売り物の FORTRAN for JavaVM が出ない理由の一つですね。
コンタミは発見の母
Re:C# の言語 設計者は James Gosling なのでは... (スコア:0)
> 例えば synchronized文由来の lock 文にタイムアウト値が設定できないとか。
ってのは、Javaの別の仕組みで解決できないんでしょうか。
wait(), notify()とかでなんとかとか。
どうにもならんです。 (スコア:1)
synchronized ( obj, timeout ) {
//
} timeout-catch {
//
}
Java に関してはどうにもならんです。Java では wait/notify はモニタを獲得したオブジェクトに対して使うものなので。
仮にモニタロックなしで wait が使えるとしても、タイムアウト処理はロックの所有権を得た時と、タイムアウトで抜けた時を区別できないと意味がないですよね。
Java の wait() って戻り値が void です。そのため、notify されて戻ってきたのかタイムアウトが来て戻ってきたのか区別がないのです。
C# のクラスライブラリはさすがに戻り値を bool 型で返して区別しています。あと try-lock もあります。なのに lock 構文は synchronized 構文の引き写しなのです。せめて try-lock 型が構文で書ければ...
p.s.
IBM のこのページ [ibm.com]には、Java のスレッドの機能不足な点がいろいろ指摘されていています。
コンタミは発見の母
Re:結構使える (スコア:1)
んですね。
実装とかライブラリとかがどうなるか?という問題はさておき、
#なので、.NETとC#がどういう関係か?はあまり考えない、という立場だとしてですが…
言語仕様だけを取りだして評価するならば、C#は悪くないです。
少なくとも色々な面で微妙に意固地で古臭い(=C(++)に似せすぎてる)Javaよりは、少し良いです。
delphiのpropertyって概念(とその実装)は、なかなか良いのですが、
いかんせん構文が繁雑でうんざり。かといってjava(のBeans)みたいに
文法によるサポート義務(笑)を怠った言語もうんざり。
そこへくるとC#は、まぁ年の功(普通と逆の意味です。キカイダーと同じで、弟ほど強い)を感じますね。
構文はすっきりしてる。
.NETに興味があるかどうかは別として、C#は触って(それでアプリやライブラリを作って)みたいですぅ。
Delphi.NET (スコア:1)
これが出たら本命だと思いつつ、VB.NET も ＶＣＬみたいでおもしろそう。
Re:結構使える (スコア:0)
GUI回りのボタンの配置とかが面倒なのでVS買っちゃったけど。
もうMFCには戻りたくない感じ(^^;
使ってて思うのはクラスライブラリの解説本が欲しいな～と思うこと。
もちろんヘルプにもビッシリ書いてあるんだけど、
ちょっと表現が抽象化され過ぎていて分からないところがあるし。
言語仕様に関して書いた本は結構あるんだけどなぁ。
でも言語仕様はNET上でも公開されてるし。↓
http://black.sakura.ne.jp/~third/cs.html
>マルチメディア関係のクラス、関数がほぼない
正直残念。DllImp
人気があるというよりも・・・ (スコア:3, すばらしい洞察)
半年間で使用開発者が５％から１２％に増えたということは、開発者の４割がC#経験半年未満のスキルしかもっていないということの裏返しだったりします。
注目を浴びた技術が一度は経験しなくてはならない、注目度と成熟度のアンバランスという試練を、C#（と、.NETは）はそろそろ迎えるんではないかと思っています。
（いい意味で）面白くなりますよ。
Terrarium (スコア:2, 参考になる)
# C#もちょっとはいいじゃん。
Re:Terrarium (スコア:1)
テラリウム徹底攻略ガイド [atmarkit.co.jp]
カルネージハート世界版ですね(うっとり)
作りも良くできていて２度うっとりです。
悲しむべくは、僕にプログラミングの素養が全くないという事ですかね(涙)
Re:Terrarium (スコア:0)
ちっと興味あるので
Re:Terrarium (スコア:2, 参考になる)
ここを見るとなんとなく雰囲気わかるかなぁ。
VisualStudioがなくても.net frameworkだけで参加できます。
DNAとして親が情報を子に渡すことができるところとか、テレポータを探す方法あたりが面白いですよ。
Re:Terrarium (スコア:0)
でも家debianとmacしかないじゃん！
またてっきり (スコア:1)
ＭＳ社内の組織票が入って急増かと思いましたが、
そうとばかりはいえない部分もあるみたいですね。
私はまだ触ってないのですが、記事を読む範囲では
「にんき」が増えたというより、「ひとけ」が増えた
という印象ですが、誰も触っていないよりはマシだと
思います。
どうなの？7％→12％ (スコア:1)
「じわりと増加」とか「健闘」が妥当では。
でもまあ、言っても差し支えない範囲。
.Net の SDK って (スコア:0)
特に何か買わなくても普通に開発が開始できちゃうのか…
MS が Windows の汎用言語の開発環境を大々的に
フリーで流したってのはもしかして初？
Re:.Net の SDK って (スコア:1)
でも商業用途に使っちゃダメとは書いていない……。うーん太っ腹（笑）
ビジュアルな開発、というかＧＵＩを使ったプログラムの開発もちょっと面倒ですができますし……。
Re:.Net の SDK って (スコア:1)
＃コントロールだけでEXEは作れませんけど
Re:.Net の SDK って (スコア:1)
DDK [microsoft.com]の中に masm.exeが入ってますが... アセンブラは汎用言語ではない?
Re:.Net の SDK って初ではない (スコア:0)