アカウント名:
パスワード:
「使って『楽しい』言語」という結論が安易というのには同意。
でも違いは「おもちゃ」云々でなくプロジェクト/ターゲットの規模と質の違いではないかと私には思われる。ターゲットが違えば適する言語も違うだろうから。
…あとはテスト容易性、さらにそこから出来上がったプログラムの堅牢性かなー。個人の趣味プロジェクトは出来上がったものの信頼性へのプレッシャーが少ないと予想される。
…という話とは別に、Rubyに関しては仕事で遣われてひどい目にあったという私怨があるので個人的にはRubyを趣味で使うことは当分ないだろうなぁ。
(とはいえ、その件はRubyに向かない仕事をRubyで始めてしまい、作業が進むにつれてRubyでは間に合わない部分をC++でDLL作りまくられ (注) て、私が関わったときにはメインプログラムに近い部分はRubyコードだけど全体の8割はC++のDLL内というRubyの濫用が原因だったと思うので、必ずしもRubyの責任ではなく「私怨」なのはわかってるのだけどもねw)
(注) Rubyは当時からCで書かれたDLLはサポートし
全体のコントロールを高レベルな言語で行い、パフォーマンスを要求する各処理を C++で行うというのは真っ当な考え方だし、「Rubyでは間に合わない部分をC++でDLL 作りまくられ」というのもごく真っ当な手法ですよね。
プロジェクト開始時は 100% Ruby だったのが、進行するにつれて 20% が C++ に置き換わった、 というのなら真っ当な発展と呼べたと思います。80% が C++ になってしまったのでは、 元々 Ruby で始めたことの意味がなんだったのか分かりません。いっそ 100% C++ で作り直す ことを目指した方が健全だったのではないかと思います。
そのツールの開発が始まった頃には私はプロジェクトにまだいなかったので聞いた話からの推測ですが、作っていたのはCコードに対するある種の最適化を行うツールで、最初はパターンマッチングでちょいちょいとCのコードを書き換えるつもりで始めたが段々本格的なコンパイラ風最適化を始めていつしか抽象構文木やデータフローグラフ相当の主要なデータ構造と最適化アルゴリズムはほとんどC++になってしまったということのようです。
そこいら辺で全体をC++に変えておけばよかったんだろうけど、その辺について開発者に意見する人が周囲に誰もいなかったこと、及び、開発者当人はさっさとやっつけ
で、その過程でLinux上のGCC&Rubyの仕様に依存した仮定に基づいたロジックやバグがRuby部分とC++部分とその結合部分に満遍なくちりばめられていったところへ私が採用されてそのツールをWindowsに移植してねと言われてギャー。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー
どいつもこいつも安易な結論を出したがるのかね (スコア:1, 興味深い)
RubyやPythonのほうが仕事に使われることが少ない、「おもちゃ」言語であるということを示しているようだ、とも言えるわけだが。
個人的な印象では、PythonとJavaでは感じる苦痛の種類が違うし、Pythonのほうが苦痛が大きいが短くてすむ(と甘い見通しをたてがち)。
Re: (スコア:1)
「使って『楽しい』言語」という結論が安易というのには同意。
でも違いは「おもちゃ」云々でなくプロジェクト/ターゲットの規模と質の違いではないかと私には思われる。ターゲットが違えば適する言語も違うだろうから。
…あとはテスト容易性、さらにそこから出来上がったプログラムの堅牢性かなー。個人の趣味プロジェクトは出来上がったものの信頼性へのプレッシャーが少ないと予想される。
Re: (スコア:1)
…という話とは別に、Rubyに関しては仕事で遣われてひどい目にあったという私怨があるので
個人的にはRubyを趣味で使うことは当分ないだろうなぁ。
(とはいえ、その件はRubyに向かない仕事をRubyで始めてしまい、作業が進むにつれてRubyでは間に合わない部分をC++でDLL作りまくられ (注) て、私が関わったときにはメインプログラムに近い部分はRubyコードだけど全体の8割はC++のDLL内というRubyの濫用が原因だったと思うので、必ずしもRubyの責任ではなく「私怨」なのはわかってるのだけどもねw)
(注)
Rubyは当時からCで書かれたDLLはサポートし
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++に変えておけばよかったんだろうけど、その辺について開発者に意見する人が周囲に誰もいなかったこと、
及び、開発者当人はさっさとやっつけ
Re:どいつもこいつも安易な結論を出したがるのかね (スコア:1)
で、その過程でLinux上のGCC&Rubyの仕様に依存した仮定に基づいたロジックやバグがRuby部分とC++部分とその結合部分に満遍なくちりばめられていったところへ
私が採用されてそのツールをWindowsに移植してねと言われてギャー。