パスワードを忘れた? アカウント作成
132889 story

プログラミング、平日にはC#とJava、週末にはPythonとRubyを使う? 54

ストーリー by makeplex
日曜大工ならぬ日曜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は月曜に質問が増えるとのことで、金曜に解決しなかった問題を週末を通して熟考した上で週明けに質問するということなのかもしれない。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2009年08月18日 10時38分 (#1624599)

    http://danlorenc.blogspot.com/2009/08/stackoverflow-experiment-results.html [blogspot.com]

    本家のタレコミからたどれるとは言え、このリンク位はこっちにも載せた方がよいのでは?
    タレコミの「グラフを見てみると……」以降の内容はこのページの下の方(グラフ以降)の翻訳ですね。

    で、このページを見るともう少し多くのことが分かります。
    グラフを一見して分かることだけでも、
    ・増減はしていても順位の逆転はない
    ・2位の Java と比べても C# は断トツ1位
    ・Java の減少と Ruby の増加は僅か
    ・それと比べると C# の減少と Python の増加ははっきり分かる
    などです。
    コメントにも興味深い内容がいくつかあります。

  • by ymitsu (31883) on 2009年08月18日 4時00分 (#1624480)

    仕事でHSP [hsp.tv]を使えたら…
    そう思っていた時期が私にもありました。

    HSPでシューティングみたいなのを「本気で」作りかけて挫折するのを何度か繰り返した今では
    「オフの日はプログラミングより酒を飲んでクダ巻いてる方が楽しい」と思っているおっさんです。

  • by Anonymous Coward on 2009年08月18日 9時12分 (#1624544)
    単に自分の時間は会社ごときの為に使わずに好きなことをするというだけだ
  • by iwakuralain (33086) on 2009年08月18日 10時04分 (#1624578)

    あくまで私の中では
    ちょっとしたツールの作成:C#
    仕事でよく使う(客の要望や環境):C・PHP・シェル
    金融関係:Java
    こんな感じで仕事でPythonとかRubyを使う場面に遭遇したことがないです。
    個人的にも週末に触ってる言語と言えばお手軽(あくまで自分の中で)なC#とPHP。
    でもまぁあくまで言語は道具なので、それぞれに得手不得手が一致すればPythonとかRubyも使うようになるのかな。

  • Perlやり始めたのは最近ですけどね。
    ロジックが頭に浮かんでも、サクッっと書けるようになるまであと何年かかるんだろ...

  • by Anonymous Coward on 2009年08月18日 1時41分 (#1624454)

    ラビー「Visual Basic 6.0しか扱えなくてすみません、すみません」

  • by Anonymous Coward on 2009年08月18日 2時03分 (#1624459)
    > RubyやPythonの方がオフの週末に手がけるような個人プロジェクトに使われることが多い、使って「楽しい」言語であるということを示しているようだ。

    RubyやPythonのほうが仕事に使われることが少ない、「おもちゃ」言語であるということを示しているようだ、とも言えるわけだが。

    個人的な印象では、PythonとJavaでは感じる苦痛の種類が違うし、Pythonのほうが苦痛が大きいが短くてすむ(と甘い見通しをたてがち)。
    • by ttm (8278) on 2009年08月18日 4時52分 (#1624488)

      「ガベージコレクタなんか使った言語環境はおもちゃだ、
      プロならメモリ管理まで自分でやって当然。」
      そう思っていた時代が私にもありました。
      今はGCは普通に使われています。

      「強い型付けがされた言語はおもちゃだ、
      プロなら変数を自由にキャストしてメモリを読み替えて当然。」
      そう思っていた時代が私にもありました。
      今は動的型でも静的型でもいいから強い型でないと信用できません。

      「高級言語なんかおもちゃだ、
      プロならアッセンブリ言語で十分。マクロがあれば大名だ。」
      そう思っていた時代が私にもありました。
      今はアッセンブリで書ける規模は知れてます。

      親コメント
      • とはいえ、その間にGC技術や型に関する最適化技術など、プログラミング言語の実装もずいぶん進歩しているので、おもちゃ呼ばわりされていたころの実装では本当におもちゃだった可能性もなくはない気もしますけどね。見かけは同じでも中身は違うというか、おもちゃも必要があれば進化するというか…。仕事で使う言語はその時点での完成度も考慮して選ぶわけで、仮に先進的なものであっても未完成だと怖くて選べないというのはあるでしょう。

        親コメント
    • 「使って『楽しい』言語」という結論が安易というのには同意。

      でも違いは「おもちゃ」云々でなくプロジェクト/ターゲットの規模と質の違いではないかと私には思われる。ターゲットが違えば適する言語も違うだろうから。

      …あとはテスト容易性、さらにそこから出来上がったプログラムの堅牢性かなー。個人の趣味プロジェクトは出来上がったものの信頼性へのプレッシャーが少ないと予想される。

      親コメント
      • …という話とは別に、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ライブラリが呼ばれている状況というのは、可能だとしてもあまり精神衛生上よろしくはない。

        親コメント
        • by Anonymous Coward
          > メインプログラムに近い部分はRubyコードだけど全体の8割はC++のDLL内

          全体のコントロールを高レベルな言語で行い、パフォーマンスを要求する各処理を
          C++で行うというのは真っ当な考え方だし、「Rubyでは間に合わない部分をC++でDLL
          作りまくられ」というのもごく真っ当な手法ですよね。

          C++はwrap用のツール使えばいいだけだし、注記で書かれてるような所もちゃんと考えてれば
          問題になるとこじゃないと思うけど、現場見てないんでわからないですが
          Rubyの能力を過信して規模に対して必要な準備をしなかったのかなー。
          • 全体のコントロールを高レベルな言語で行い、パフォーマンスを要求する各処理を
            C++で行うというのは真っ当な考え方だし、「Rubyでは間に合わない部分をC++でDLL
            作りまくられ」というのもごく真っ当な手法ですよね。

            プロジェクト開始時は 100% Ruby だったのが、進行するにつれて 20% が C++ に置き換わった、
            というのなら真っ当な発展と呼べたと思います。80% が C++ になってしまったのでは、
            元々 Ruby で始めたことの意味がなんだったのか分かりません。いっそ 100% C++ で作り直す
            ことを目指した方が健全だったのではないかと思います。

            親コメント
            • by Anonymous Coward
              > 80% が C++ になってしまったのでは、
              > 元々 Ruby で始めたことの意味がなんだったのか分かりません。

              親コメだけど、どうだろう?
              80%がC++で20%が結合コードや拡張性の部分でもいい気がするけど。
              ものによるからなんとも言えないけどね。

              C++による置き換えを念頭に置いた上で最初は100%Rubyで書き、機能を確かめた上で
              テストしながらC++に書き換えていくのは理想な気がするけど、そんなうまく行っていれば
              元コメが恨み節言うはずがないからそんなんではなかったんだろうね。
              • そのツールの開発が始まった頃には私はプロジェクトにまだいなかったので聞いた話からの推測ですが、
                作っていたのはCコードに対するある種の最適化を行うツールで、最初はパターンマッチングでちょいちょいとCのコードを書き換えるつもりで始めたが
                段々本格的なコンパイラ風最適化を始めていつしか抽象構文木やデータフローグラフ相当の主要なデータ構造と
                最適化アルゴリズムはほとんどC++になってしまったということのようです。

                そこいら辺で全体をC++に変えておけばよかったんだろうけど、その辺について開発者に意見する人が周囲に誰もいなかったこと、
                及び、開発者当人はさっさとやっつけツールで実験やってデータだけ取れればいいつもりでいたのに対し
                周囲は本格的な最適化ツールと期待していたので認識にかなり齟齬があったことなどからそのままになってしまった。

                結果としてパース部分とコンパイラフレームワーク的な部分(C++で書かれた最適化モジュール間のデータのやり取り)は
                Rubyに上書かれた凝ったコードのままとなった。
                例えば:

                • RubyのパターンマッチでパースしてC++のデータ構造抽象構文木を作る。
                • それをRubyを介してC++で書かれた最適化モジュールを動的リンクして渡す。
                • C++で書かれた各最適化モジュールにはRubyのデータ構造とRubyのデータ構造でラップされたC++のデータ構造が渡される。
                • Rubyのデータ構造はRubyのGC、C++のデータ構造はコンサバティブGCライブラリが管理するが、相互に参照があったし、かなり強引なキャストもあった。
                • 最適化に必要なC++のDLLはSQLサーバで管理され、設定ファイルに書かれたSQL記述によって読み込む最適化モジュールDLLをSQLサーバから取得するようになっており、
                  その部分がRubyからSQLのライブラリを呼び出すコードとして書かれていた。

                …という、RubyとC++のオブジェクトやコードが入り混じるハイブリッド・スパゲティ・モンスターに成長を遂げてしまったと。

                親コメント
              • で、その過程でLinux上のGCC&Rubyの仕様に依存した仮定に基づいたロジックやバグがRuby部分とC++部分とその結合部分に満遍なくちりばめられていったところへ
                私が採用されてそのツールをWindowsに移植してねと言われてギャー

                親コメント
              • by Anonymous Coward

                >抽象構文木やデータフローグラフ相当の主要なデータ構造

                そういうのこそC++よりRubyで書いたほうがラクだと思うんだが…?

              • 正確なところは聞いてみないとわからない話ですが、辿る部分をC++で書いて高速にする必要があって生のC++オブジェクトが使いたかったんではないかと想像しています。データ構造を組み立てる部分はRubyで書かれていたと思いました。

                親コメント
      • by Anonymous Coward
        > でも違いは「おもちゃ」云々でなく

        タレコミ文の、個人~多い<->仕事~少ない、楽しい<->おもちゃ、と形式的に入れかえただけです:)
        (おもちゃは楽しいもんね)

        言語やそれでのプログラミングが楽しい、という感覚はいまいち理解しかねるけどね。
        掃除と同じで、上手くいった一瞬だけなら楽しいと言えないこともない、という感じ。
    • by Anonymous Coward

      タレコミとコメントの釣り合いがとれるのでした。

    • by Anonymous Coward
      全く同意。

      別にRubyは楽しいというものではないし、むしろC#のほうが楽しいことは多い。

      業務でWindows関連開発、趣味でLinuxという人が、平日は仕事でC#を使い、
      週末は(Linuxなので)C#が使えず Rubyでというケースなのではないかと思う。
      またはプログラミング好きな人は、C#を仕事でつかいつつ、他の言語も
      使ってみる・勉強するものなので、仕事ではあまり使えないRubyを勉強
      しているだけなのかもしれない。

      JavaならWindows/Linuxで使えるわけだけど、Javaを使った開発者って
      Javaしか使えない人が多い気がする。
      プログラミング理論とかアルゴリズムみたいな勉強ではなく、
      専門学校などでJavaプログラミングを習っただけとか。

      そういう人は週末に趣味で何かをプログラミングすることも少ないわけで。

      もちろん、他の言語を良く使っている人がJavaも使うパターンも多いですが。
  • by jelkawasaki (35181) on 2009年08月18日 5時18分 (#1624491)
    状況が特殊かもしれないけど、c,c++,pascal,cobol,perl,python,
    lua,ruby,c#と仕事で、いろいろ使ってきました。
    やっぱり、公私共に使いやすいのは、Pythonかな、ちなみに、私の場合、
    週末、如何は、関係なし、年中仕事なので、、、、
    • Re:Python派 (スコア:3, おもしろおかしい)

      by elderwand (34630) on 2009年08月18日 7時52分 (#1624517) 日記

      私もいろいろ使ってきて Python にたどりついたので、このストーリーを読んで、

      「毎日が日曜日」みたいだ

      と思いましたが、仕事に使ってると聞いて安心しました。

      #いや、そろそろ「毎日が日曜日」が近いですが。

      親コメント
  • by Anonymous Coward on 2009年08月18日 5時43分 (#1624496)

    ウィークデーを趣味の開発にあてて、週末だけ仕事の開発をするのなら逆になりそうな気もするのですが。
    C#やJavaがそんなに楽しくない、ですか?

    • C# は触ったことがありませんが、Java に関しては全然楽しくないと思います。
      何も仕事を片付けていないうちに行数だけはどんどん嵩んでいく、という徒労感があります。
      恐らく LL に入れ込んでいる人のうちの相当数は Java が嫌いで、おおよそ僕と同じような
      理由でそうなっているんじゃないかと思います。
      親コメント
      • そらまぁ、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などのプログラミング・ツールの
        サポートが貧弱でも気にはならないだろうけど、作るものがヘビーになると…。

        親コメント
        • また、Perlなどのように言語の基本機能・構文が肥大化した場合、
          自分で書くときは自分が使う機能・構文しか使わないのでそれほど気にならないが、
          他人が書いたものを読むとき
          自分が余り使ってこなかった機能・構文に驚かされる場合がしばしばあるように思われる。

          驚かされる場合がある、ということには同意する。
          良い意味で驚かされる場合には、TIMTOWTDI と呪文を唱えて受入れることが出来る。
          問題は悪い意味で驚かされた場合だけれども、次のように後悔することは滅多にない。即ち、
          「この人に Java で書かせておけばまだマシだったろうに、Perl で書かせたからグチャグチャに
          なってしまった」などと思うことは滅多にない。いくら機能や構文を少なくし貧しくしても、
          駄目なプログラムを書くという才能に対する歯止めにはならない。

          もうひとつの論点は、Perl のようにありったけの構文糖を振り掛けた言語というのは、
          プログラマが簡潔な記述を目指して努力したときに、それに見合う構文が見つかる可能性が
          高いことである。Java の構文糖は too little, too late であり、今までのプログラマが
          簡潔な構文を見つけるために行った努力をにべもなく撥ね付けて来た割合が高かった。
          そのために Java プログラマは、細い鎖で繋がれた象のように、貧弱な構文から逃げ出す
          意欲を失っていると思う。

          親コメント
          • プログラミングを職人芸と見る、あるいは職人芸的に書ける範囲・規模・種類のプロジェクトを対象とする分にはそれでもいいと思うのです。

            しかし、多人数で行う大規模なプロジェクトではどの道プログラマの職人芸だけには頼れないので
            ツールのサポートが欲しい。
            しかし構文・機能がリッチすぎて支援ツールが作り切れないとなると少々プログラマ向け"UI"技術に偏って突出し過ぎなのではないかなと。
            そのあたり工学ってのは最先端まで突出してればいいってもんではなくて色々な技術の総合的なバランスも重要ではないかと思うのです。

            親コメント
      • by Anonymous Coward on 2009年08月18日 7時00分 (#1624509)
        Python大好きですが、Javaも結構好きです。

        >何も仕事を片付けていないうちに行数だけはどんどん嵩んでいく

        DIフレームワークを使っているからでもありますが、こんな経験もありません。
        Pythonほどではありませんが、結構楽しんで書いてますよ。

        と、今更Java1.4を使うプロジェクトに放りこまれるまで、思っていました。

        1.5以上での書き方(拡張forとかオートボクシングとか)に慣れきった後に、1.4に戻ると地獄です。
        他のメンバーが、酷いコードを書いてくれたりして、地獄の面積が日々拡張されていきます。
        知識のアップデートをしない人たちに、1.4も1.5も大して違わないとか言われると本当にぐったりします。
        親コメント
        • Javaの案件もらってくると、必ず1.4仕様なんだよなぁ。ターゲットのJREは6なのに。ぐったり。
          親コメント
          • by Anonymous Coward

            sun.io,なんたらを呼び出しているせいで、準拠レベル6でコンパイルするとdeprecatedなメソッド使用の警告でビルドが失敗したりします。勘弁してくれ。

        • by Anonymous Coward
          > DIフレームワークを使っているからでもありますが、こんな経験もありません。
          代わりにXMLの行数がどんどん嵩んでいくだけがw
          (もういいかげん1.6の時代なのに)1.5に移行できないのは100%SUNが悪い。シンタックスシュガーだから後方互換性があるよってさんざん言われてたのに、いざリリースされたら古いVMでは動かないでやんの。
    • 仕事がPython、Ruby中心になったら、週末にC#とJavaが増える予感。
  • by Anonymous Coward on 2009年08月18日 8時00分 (#1624518)

    これは言い方を変えると、「C#やJAVAの仕事は金にならんから、
    土日のPythonやRubyの副業で脱出を謀っている」ということなのでしょうか?

  • by Anonymous Coward on 2009年08月18日 9時12分 (#1624546)

    ちょんプロ書くならRubyとかの方が楽ってことじゃないの?
    休日に業務用みたいにガチガチのプログラムなんて書きたくないし

  • by Anonymous Coward on 2009年08月18日 12時56分 (#1624731)

    Objective Cがドマイナーであることは理解した。

typodupeerror

日々是ハック也 -- あるハードコアバイナリアン

読み込み中...