アカウント名:
パスワード:
「使って『楽しい』言語」という結論が安易というのには同意。
でも違いは「おもちゃ」云々でなくプロジェクト/ターゲットの規模と質の違いではないかと私には思われる。ターゲットが違えば適する言語も違うだろうから。
…あとはテスト容易性、さらにそこから出来上がったプログラムの堅牢性かなー。個人の趣味プロジェクトは出来上がったものの信頼性へのプレッシャーが少ないと予想される。
…という話とは別に、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ライブラリが呼ばれている状況というのは、可能だとしてもあまり精神衛生上よろしくはない。
全体のコントロールを高レベルな言語で行い、パフォーマンスを要求する各処理を C++で行うというのは真っ当な考え方だし、「Rubyでは間に合わない部分をC++でDLL 作りまくられ」というのもごく真っ当な手法ですよね。
プロジェクト開始時は 100% Ruby だったのが、進行するにつれて 20% が C++ に置き換わった、 というのなら真っ当な発展と呼べたと思います。80% が C++ になってしまったのでは、 元々 Ruby で始めたことの意味がなんだったのか分かりません。いっそ 100% C++ で作り直す ことを目指した方が健全だったのではないかと思います。
そのツールの開発が始まった頃には私はプロジェクトにまだいなかったので聞いた話からの推測ですが、作っていたのはCコードに対するある種の最適化を行うツールで、最初はパターンマッチングでちょいちょいとCのコードを書き換えるつもりで始めたが段々本格的なコンパイラ風最適化を始めていつしか抽象構文木やデータフローグラフ相当の主要なデータ構造と最適化アルゴリズムはほとんどC++になってしまったということのようです。
そこいら辺で全体をC++に変えておけばよかったんだろうけど、その辺について開発者に意見する人が周囲に誰もいなかったこと、及び、開発者当人はさっさとやっつけツールで実験やってデータだけ取れればいいつもりでいたのに対し周囲は本格的な最適化ツールと期待していたので認識にかなり齟齬があったことなどからそのままになってしまった。
結果としてパース部分とコンパイラフレームワーク的な部分(C++で書かれた最適化モジュール間のデータのやり取り)はRubyに上書かれた凝ったコードのままとなった。例えば:
…という、RubyとC++のオブジェクトやコードが入り混じるハイブリッド・スパゲティ・モンスターに成長を遂げてしまったと。
で、その過程でLinux上のGCC&Rubyの仕様に依存した仮定に基づいたロジックやバグがRuby部分とC++部分とその結合部分に満遍なくちりばめられていったところへ私が採用されてそのツールをWindowsに移植してねと言われてギャー。
>抽象構文木やデータフローグラフ相当の主要なデータ構造
そういうのこそC++よりRubyで書いたほうがラクだと思うんだが…?
正確なところは聞いてみないとわからない話ですが、辿る部分をC++で書いて高速にする必要があって生のC++オブジェクトが使いたかったんではないかと想像しています。データ構造を組み立てる部分はRubyで書かれていたと思いました。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
一つのことを行い、またそれをうまくやるプログラムを書け -- Malcolm Douglas McIlroy
どいつもこいつも安易な結論を出したがるのかね (スコア: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はサポートしてたけど、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)
> そういうのこそC++よりRubyで書いたほうがラクだと思うんだが…?
なぜ?
こういうところはすでにあるコードの再利用がしやすい箇所ではないし(しかしパターンの恩恵にはあずかれる)
型チェックの恩恵を一番受けるところだし、
RubyやPythonの豊富な組み込み操作はあんまり出番ないし、
不動点計算するから遅いと困るし、
むしろRubyやPythonのメリットがわからん。
Re: (スコア:0)
タレコミ文の、個人~多い<->仕事~少ない、楽しい<->おもちゃ、と形式的に入れかえただけです:)
(おもちゃは楽しいもんね)
言語やそれでのプログラミングが楽しい、という感覚はいまいち理解しかねるけどね。
掃除と同じで、上手くいった一瞬だけなら楽しいと言えないこともない、という感じ。