プログラミング、平日にはC#とJava、週末にはPythonとRubyを使う? 54
ストーリー by makeplex
日曜大工ならぬ日曜LLでしょうか 部門より
日曜大工ならぬ日曜LLでしょうか 部門より
あるAnonymous Coward 曰く、
本家/.「C# and Java Weekday Languages, Python and Ruby For Weekends?」より。
StackOverflow.comのダンプを使い、週を通じた各プログラミングのアクティビティを測ってみたところ、Ruby及びPythonは週末に質問が増える傾向があり、逆にC#とJavaは週末にはアクティビティが低下する傾向があることが分かった。
RubyやPythonの方がオフの週末に手がけるような個人プロジェクトに使われることが多い、使って「楽しい」言語であるということを示しているようだ。
次の仕事のプロジェクトで使う言語を選ぶ際にはこのデータを参考に上司と掛け合ってみてはいかがだろうか?グラフを見てみると、週末には特にC#のアクティビティが低下しPythonが伸びている。しかしそれでもC#はPythonの2倍以上のアクティビティがみられるとのこと。またC#とJavaは月曜に質問が増えるとのことで、金曜に解決しなかった問題を週末を通して熟考した上で週明けに質問するということなのかもしれない。
肝心のグラフが載っている Dan Lorenc 氏のページはこちら (スコア:3, 興味深い)
http://danlorenc.blogspot.com/2009/08/stackoverflow-experiment-results.html [blogspot.com]
本家のタレコミからたどれるとは言え、このリンク位はこっちにも載せた方がよいのでは?
タレコミの「グラフを見てみると……」以降の内容はこのページの下の方(グラフ以降)の翻訳ですね。
で、このページを見るともう少し多くのことが分かります。
グラフを一見して分かることだけでも、
・増減はしていても順位の逆転はない
・2位の Java と比べても C# は断トツ1位
・Java の減少と Ruby の増加は僅か
・それと比べると C# の減少と Python の増加ははっきり分かる
などです。
コメントにも興味深い内容がいくつかあります。
利用者数じゃなくて質問数 (スコア:1)
そういや利用者数じゃなくて質問件数か。。
JavaとC#使ってるけど、確かにC#はgoogle回数が多い気がしないでもない…。
本とか少ないからなぁ。
「遊び」じゃないと楽しくない (スコア:2, 興味深い)
仕事でHSP [hsp.tv]を使えたら…
そう思っていた時期が私にもありました。
HSPでシューティングみたいなのを「本気で」作りかけて挫折するのを何度か繰り返した今では
「オフの日はプログラミングより酒を飲んでクダ巻いてる方が楽しい」と思っているおっさんです。
酒が飲めないのでw (スコア:2, おもしろおかしい)
酒が飲めないので、今でもたまーに細々とオフの日に趣味プログラムを書いていますw
20年のうちに言語はC++からJavaに移り、データ表現はマイ・カスタム・データ記述言語からXMLに移りましたが、完成を見ないことだけは変わりませんw
どういった言語だからどうこうっていうのは無い (スコア:2, 興味深い)
Re:どういった言語だからどうこうっていうのは無い (スコア:1)
似たような感じで格言っぽくもう一丁。
「大切なのは何で作るかじゃない。何を作るかだ」
Re: (スコア:0)
俺の経験からいうと、「何を作らないかが大事」
用途によるでしょう (スコア:2)
あくまで私の中では
ちょっとしたツールの作成:C#
仕事でよく使う(客の要望や環境):C・PHP・シェル
金融関係:Java
こんな感じで仕事でPythonとかRubyを使う場面に遭遇したことがないです。
個人的にも週末に触ってる言語と言えばお手軽(あくまで自分の中で)なC#とPHP。
でもまぁあくまで言語は道具なので、それぞれに得手不得手が一致すればPythonとかRubyも使うようになるのかな。
昼はCOBOL 夜はC# 休日はPerl ですが何か (スコア:2)
Perlやり始めたのは最近ですけどね。
ロジックが頭に浮かんでも、サクッっと書けるようになるまであと何年かかるんだろ...
すみません、すみません(CV:金田朋子) (スコア:1, おもしろおかしい)
ラビー「Visual Basic 6.0しか扱えなくてすみません、すみません」
どいつもこいつも安易な結論を出したがるのかね (スコア:1, 興味深い)
RubyやPythonのほうが仕事に使われることが少ない、「おもちゃ」言語であるということを示しているようだ、とも言えるわけだが。
個人的な印象では、PythonとJavaでは感じる苦痛の種類が違うし、Pythonのほうが苦痛が大きいが短くてすむ(と甘い見通しをたてがち)。
今の主流言語は一昔前のおもちゃ言語 (スコア:4, おもしろおかしい)
「ガベージコレクタなんか使った言語環境はおもちゃだ、
プロならメモリ管理まで自分でやって当然。」
そう思っていた時代が私にもありました。
今はGCは普通に使われています。
「強い型付けがされた言語はおもちゃだ、
プロなら変数を自由にキャストしてメモリを読み替えて当然。」
そう思っていた時代が私にもありました。
今は動的型でも静的型でもいいから強い型でないと信用できません。
「高級言語なんかおもちゃだ、
プロならアッセンブリ言語で十分。マクロがあれば大名だ。」
そう思っていた時代が私にもありました。
今はアッセンブリで書ける規模は知れてます。
Re:今の主流言語は一昔前のおもちゃ言語 (スコア:2, 興味深い)
とはいえ、その間にGC技術や型に関する最適化技術など、プログラミング言語の実装もずいぶん進歩しているので、おもちゃ呼ばわりされていたころの実装では本当におもちゃだった可能性もなくはない気もしますけどね。見かけは同じでも中身は違うというか、おもちゃも必要があれば進化するというか…。仕事で使う言語はその時点での完成度も考慮して選ぶわけで、仮に先進的なものであっても未完成だと怖くて選べないというのはあるでしょう。
Re:どいつもこいつも安易な結論を出したがるのかね (スコア:1)
「使って『楽しい』言語」という結論が安易というのには同意。
でも違いは「おもちゃ」云々でなくプロジェクト/ターゲットの規模と質の違いではないかと私には思われる。ターゲットが違えば適する言語も違うだろうから。
…あとはテスト容易性、さらにそこから出来上がったプログラムの堅牢性かなー。個人の趣味プロジェクトは出来上がったものの信頼性へのプレッシャーが少ないと予想される。
Re:どいつもこいつも安易な結論を出したがるのかね (スコア:1)
…という話とは別に、Rubyに関しては仕事で遣われてひどい目にあったという私怨があるので
個人的にはRubyを趣味で使うことは当分ないだろうなぁ。
(とはいえ、その件はRubyに向かない仕事をRubyで始めてしまい、作業が進むにつれてRubyでは間に合わない部分をC++でDLL作りまくられ (注) て、私が関わったときにはメインプログラムに近い部分はRubyコードだけど全体の8割はC++のDLL内というRubyの濫用が原因だったと思うので、必ずしもRubyの責任ではなく「私怨」なのはわかってるのだけどもねw)
(注)
Rubyは当時からCで書かれたDLLはサポートしてたけど、C++で書かれた上にコンサバティブGCを使っているDLLを(今は知らないけど少なくとも当時は)サポートしていなかった。C++はシンボル名がマングリングされているし、コンストラクタ関係とかソースに陽には現れない形でこっそり呼ばれる処理もあるので、それで作ったDLLをC/C++以外の他言語から呼ぶのは不可能ではないまでも相当の配慮が必要と思われ、あまり実際的とは思われない。ましてRuby自身のGCと共にC++内でコンサバティブGCライブラリが呼ばれている状況というのは、可能だとしてもあまり精神衛生上よろしくはない。
Re: (スコア:0)
全体のコントロールを高レベルな言語で行い、パフォーマンスを要求する各処理を
C++で行うというのは真っ当な考え方だし、「Rubyでは間に合わない部分をC++でDLL
作りまくられ」というのもごく真っ当な手法ですよね。
C++はwrap用のツール使えばいいだけだし、注記で書かれてるような所もちゃんと考えてれば
問題になるとこじゃないと思うけど、現場見てないんでわからないですが
Rubyの能力を過信して規模に対して必要な準備をしなかったのかなー。
Re:どいつもこいつも安易な結論を出したがるのかね (スコア:2, すばらしい洞察)
プロジェクト開始時は 100% Ruby だったのが、進行するにつれて 20% が C++ に置き換わった、
というのなら真っ当な発展と呼べたと思います。80% が C++ になってしまったのでは、
元々 Ruby で始めたことの意味がなんだったのか分かりません。いっそ 100% C++ で作り直す
ことを目指した方が健全だったのではないかと思います。
Re: (スコア:0)
> 元々 Ruby で始めたことの意味がなんだったのか分かりません。
親コメだけど、どうだろう?
80%がC++で20%が結合コードや拡張性の部分でもいい気がするけど。
ものによるからなんとも言えないけどね。
C++による置き換えを念頭に置いた上で最初は100%Rubyで書き、機能を確かめた上で
テストしながらC++に書き換えていくのは理想な気がするけど、そんなうまく行っていれば
元コメが恨み節言うはずがないからそんなんではなかったんだろうね。
Re:どいつもこいつも安易な結論を出したがるのかね (スコア:1)
そのツールの開発が始まった頃には私はプロジェクトにまだいなかったので聞いた話からの推測ですが、
作っていたのはCコードに対するある種の最適化を行うツールで、最初はパターンマッチングでちょいちょいとCのコードを書き換えるつもりで始めたが
段々本格的なコンパイラ風最適化を始めていつしか抽象構文木やデータフローグラフ相当の主要なデータ構造と
最適化アルゴリズムはほとんどC++になってしまったということのようです。
そこいら辺で全体をC++に変えておけばよかったんだろうけど、その辺について開発者に意見する人が周囲に誰もいなかったこと、
及び、開発者当人はさっさとやっつけツールで実験やってデータだけ取れればいいつもりでいたのに対し
周囲は本格的な最適化ツールと期待していたので認識にかなり齟齬があったことなどからそのままになってしまった。
結果としてパース部分とコンパイラフレームワーク的な部分(C++で書かれた最適化モジュール間のデータのやり取り)は
Rubyに上書かれた凝ったコードのままとなった。
例えば:
その部分がRubyからSQLのライブラリを呼び出すコードとして書かれていた。
…という、RubyとC++のオブジェクトやコードが入り混じるハイブリッド・スパゲティ・モンスターに成長を遂げてしまったと。
Re:どいつもこいつも安易な結論を出したがるのかね (スコア:1)
で、その過程でLinux上のGCC&Rubyの仕様に依存した仮定に基づいたロジックやバグがRuby部分とC++部分とその結合部分に満遍なくちりばめられていったところへ
私が採用されてそのツールをWindowsに移植してねと言われてギャー。
Re: (スコア:0)
>抽象構文木やデータフローグラフ相当の主要なデータ構造
そういうのこそC++よりRubyで書いたほうがラクだと思うんだが…?
Re:どいつもこいつも安易な結論を出したがるのかね (スコア:1)
正確なところは聞いてみないとわからない話ですが、辿る部分をC++で書いて高速にする必要があって生のC++オブジェクトが使いたかったんではないかと想像しています。データ構造を組み立てる部分はRubyで書かれていたと思いました。
Re: (スコア:0)
タレコミ文の、個人~多い<->仕事~少ない、楽しい<->おもちゃ、と形式的に入れかえただけです:)
(おもちゃは楽しいもんね)
言語やそれでのプログラミングが楽しい、という感覚はいまいち理解しかねるけどね。
掃除と同じで、上手くいった一瞬だけなら楽しいと言えないこともない、という感じ。
と、こうして (スコア:0)
タレコミとコメントの釣り合いがとれるのでした。
Re: (スコア:0)
別にRubyは楽しいというものではないし、むしろC#のほうが楽しいことは多い。
業務でWindows関連開発、趣味でLinuxという人が、平日は仕事でC#を使い、
週末は(Linuxなので)C#が使えず Rubyでというケースなのではないかと思う。
またはプログラミング好きな人は、C#を仕事でつかいつつ、他の言語も
使ってみる・勉強するものなので、仕事ではあまり使えないRubyを勉強
しているだけなのかもしれない。
JavaならWindows/Linuxで使えるわけだけど、Javaを使った開発者って
Javaしか使えない人が多い気がする。
プログラミング理論とかアルゴリズムみたいな勉強ではなく、
専門学校などでJavaプログラミングを習っただけとか。
そういう人は週末に趣味で何かをプログラミングすることも少ないわけで。
もちろん、他の言語を良く使っている人がJavaも使うパターンも多いですが。
Python派 (スコア:1)
lua,ruby,c#と仕事で、いろいろ使ってきました。
やっぱり、公私共に使いやすいのは、Pythonかな、ちなみに、私の場合、
週末、如何は、関係なし、年中仕事なので、、、、
Re:Python派 (スコア:3, おもしろおかしい)
私もいろいろ使ってきて Python にたどりついたので、このストーリーを読んで、
「毎日が日曜日」みたいだ
と思いましたが、仕事に使ってると聞いて安心しました。
#いや、そろそろ「毎日が日曜日」が近いですが。
休みの日ぐらいは日本語オンリーで (スコア:1)
Re:休みの日ぐらいは日本語オンリーで (スコア:1, おもしろおかしい)
# ぴゅうた世代なので AC
Re: (スコア:0)
外来語使用禁止遊戯?
昼はC、ASM、夜はHSP、Ruby(Cは少々)ですが何か? (スコア:1)
夜にするのは (スコア:2, 興味深い)
遺伝子プログラミングが良いなぁ。無論ペアで。
Re:夜にするのは (スコア:5, おもしろおかしい)
しばしば頭を抱えるのですよ。
Re: (スコア:0)
さあ、早くバージョン2をリリースする作業に戻るんだ・・・
#どうか、既存バージョンのサポートの怠りなく。;-)
Re:夜にするのは (スコア:2, 参考になる)
Re:夜にするのは (スコア:1)
彼女がオープンソースでした。
Re:夜にするのは (スコア:2, おもしろおかしい)
「一番コントリビュートしてくれた殿方の色に染まりますわ。」
週末しか趣味に使えないからでは (スコア:0)
ウィークデーを趣味の開発にあてて、週末だけ仕事の開発をするのなら逆になりそうな気もするのですが。
C#やJavaがそんなに楽しくない、ですか?
Re:週末しか趣味に使えないからでは (スコア:1)
何も仕事を片付けていないうちに行数だけはどんどん嵩んでいく、という徒労感があります。
恐らく LL に入れ込んでいる人のうちの相当数は Java が嫌いで、おおよそ僕と同じような
理由でそうなっているんじゃないかと思います。
Re:週末しか趣味に使えないからでは (スコア:2, すばらしい洞察)
そらまぁ、LLはワンライナーを書きやすくするとか行数減らすのが
設計目標の一部になってるのも多いだろうから…。
(LL、軽量言語は日本語的な解釈で。http://ja.wikipedia.org/wiki/%E8%BB%BD%E9%87%8F%E3%83%97%E3%83%AD%E3%8... [wikipedia.org])
そういう言語の場合、言語が提供してくれる機能を使う範囲では
書く量が少なくて楽なのは当然。
けど、情報量的に考えるとワンライナーを書きやすくするなど記述量の削減を目指す場合、言語の構文や機能がリッチになる傾向は(ある程度は抽象化や最適化技術でカバーできたとしても)避け難い。この場合、リッチにしたままだと言語仕様が肥大化し、肥大化を避けようとするとあまり使わない機能は削ることになる。
「あまり使われない機能」は「便利でないな機能」な可能性もあり、
そのような削減候補として汎用言語で組み込み型などになっているプリミティブなデータ構造が選ばれてしまう可能性がある。
たとえばJavaScriptでは配列もクラスも実態は連想配列になってしまうので、
基本データ構造として連想配列ベースのものしか選びようがない。
あるいはシェルスクリプトなどのように色々な型が
何か演算をするたびに文字列表現に落ちてしまうような場合もある。
そうなるとパフォーマンスなどの理由で言語に任せず自分で書かなきゃいけなくなった時
プリミティブが既に多機能&低パフォーマンスなため
どう頑張ってもその言語の上では書き直しようがなくなる可能性がある。
また、Perlなどのように言語の基本機能・構文が肥大化した場合、
自分で書くときは自分が使う機能・構文しか使わないのでそれほど気にならないが、
他人が書いたものを読むとき
自分が余り使ってこなかった機能・構文に驚かされる場合がしばしばあるように思われる。
さらにそれに近い話として、基本機能・構文が肥大化すると
IDE等プログラミング・ツールでサポートするコストも高くなる。
ツールのサポート・コストが高いといつまでたってもツールが充実しない。
IDEなら構文強調表示くらいはなんとかできてもリファクタリング・ツールとかまでは
中々手が回らなさそうに思われる。
(Eclipseでのプラグインの状況とか見ていてもそう感じる。)
LL言語をライトなプログラムにしか使わないならIDEなどのプログラミング・ツールの
サポートが貧弱でも気にはならないだろうけど、作るものがヘビーになると…。
Re:週末しか趣味に使えないからでは (スコア:1)
驚かされる場合がある、ということには同意する。
良い意味で驚かされる場合には、TIMTOWTDI と呪文を唱えて受入れることが出来る。
問題は悪い意味で驚かされた場合だけれども、次のように後悔することは滅多にない。即ち、
「この人に Java で書かせておけばまだマシだったろうに、Perl で書かせたからグチャグチャに
なってしまった」などと思うことは滅多にない。いくら機能や構文を少なくし貧しくしても、
駄目なプログラムを書くという才能に対する歯止めにはならない。
もうひとつの論点は、Perl のようにありったけの構文糖を振り掛けた言語というのは、
プログラマが簡潔な記述を目指して努力したときに、それに見合う構文が見つかる可能性が
高いことである。Java の構文糖は too little, too late であり、今までのプログラマが
簡潔な構文を見つけるために行った努力をにべもなく撥ね付けて来た割合が高かった。
そのために Java プログラマは、細い鎖で繋がれた象のように、貧弱な構文から逃げ出す
意欲を失っていると思う。
Re:週末しか趣味に使えないからでは (スコア:2, すばらしい洞察)
プログラミングを職人芸と見る、あるいは職人芸的に書ける範囲・規模・種類のプロジェクトを対象とする分にはそれでもいいと思うのです。
しかし、多人数で行う大規模なプロジェクトではどの道プログラマの職人芸だけには頼れないので
ツールのサポートが欲しい。
しかし構文・機能がリッチすぎて支援ツールが作り切れないとなると少々プログラマ向け"UI"技術に偏って突出し過ぎなのではないかなと。
そのあたり工学ってのは最先端まで突出してればいいってもんではなくて色々な技術の総合的なバランスも重要ではないかと思うのです。
Re:週末しか趣味に使えないからでは (スコア:2, すばらしい洞察)
>何も仕事を片付けていないうちに行数だけはどんどん嵩んでいく
DIフレームワークを使っているからでもありますが、こんな経験もありません。
Pythonほどではありませんが、結構楽しんで書いてますよ。
と、今更Java1.4を使うプロジェクトに放りこまれるまで、思っていました。
1.5以上での書き方(拡張forとかオートボクシングとか)に慣れきった後に、1.4に戻ると地獄です。
他のメンバーが、酷いコードを書いてくれたりして、地獄の面積が日々拡張されていきます。
知識のアップデートをしない人たちに、1.4も1.5も大して違わないとか言われると本当にぐったりします。
Re:週末しか趣味に使えないからでは (スコア:2, 興味深い)
Re: (スコア:0)
sun.io,なんたらを呼び出しているせいで、準拠レベル6でコンパイルするとdeprecatedなメソッド使用の警告でビルドが失敗したりします。勘弁してくれ。
Re: (スコア:0)
代わりにXMLの行数がどんどん嵩んでいくだけがw
(もういいかげん1.6の時代なのに)1.5に移行できないのは100%SUNが悪い。シンタックスシュガーだから後方互換性があるよってさんざん言われてたのに、いざリリースされたら古いVMでは動かないでやんの。
仕事と違うことをしたいだけ (スコア:0)
これは言い方を変えると (スコア:0)
これは言い方を変えると、「C#やJAVAの仕事は金にならんから、
土日のPythonやRubyの副業で脱出を謀っている」ということなのでしょうか?
規模の違い (スコア:0)
ちょんプロ書くならRubyとかの方が楽ってことじゃないの?
休日に業務用みたいにガチガチのプログラムなんて書きたくないし
とりあえず (スコア:0)
Objective Cがドマイナーであることは理解した。