「とおりすがり」さんとの議論の続き。長くなるのと、多少は価値のある議論かもしれないのでネタ化(^^;
けど事実誤認は勘弁。
事実誤認してる？(^^;。Anders氏が退社したのが「kylixが直接の原因」だとは知らなかったけど、この事がDelphi（というかIDE事業の）衰退の原因の全てではないでしょ。短期的にはともかく、中長期的にはkylixは継続すべきだった、今からでも復活すべきであるというのが俺の意見。逆に「Delphiの衰退=Anders氏の退社=kylixが原因」というのがあなたの意見。事実誤認というより見解の違いなのでは？
もっとも、Anders氏退社の件については良く知らないので詳しく知りたい気はする(^^;
CLX は QT 依存のライブラリです。CLX 自体はクロスプラットフォームではありません。
確かにCLXは「Qtのラッパー」だからね〜。「Qtがクロスプラットフォーム」なのであって「CLX自体はクロスプラットフォームではない」というのは正しい。ただし、ここで議論しているのは内部実装の話ではない。
しかし、Borlandにもっと開発力があって、Qtに依存しない独自のクラスプラットフォームライブラリが構築できたなら、そしてkylixの完成度が高かったなら、また違った展開になっていたかもね。
関係ないけど、SymantecもMacとWindowsの両方で使えるクラスライブラリを開発しているという話もあったな〜。日の目を見ないまま、Symantecは開発ツールからすっかり足を洗ってしまったけど(^^;
OSや.NET Frameworkと密に結合されているVisual Studio
してないですね。よく作り込まれているとは思いますが，それはプラットフォーム/フレームワークと結合されていることが「原因」ではないですね。作り込まれた「結果」を「原因」と勘違いされているのでしょう。
これは、昔の「Windows98とIEの関係」的な「結合」のイメージ？表現が悪かったかも。そーゆーイメージではない。「連携」とか「連動」と言い換えたほうが良いかな。
RADはライブラリとIDEの連携がキモなのは、C++BuilderやDelphiを見れば良く解る。C++Builder（Delphi for Win32）は、VLC for Win32とIDEを含めてRADツールとして全く良くできている。VCLによる新しいAPIのサポートは常に周回遅れではあるが、それを補うだけの魅力は十分にある。
しかし、「.NET Framework」をターゲットとしてRADを構築する場合、Microsoftが新しいFrameworkと平行してVisual Studioを開発にするのは当然で、Borlandは常に後れを取るのは当たり前。その上でフレームワークの魅力は「同じ」なのだから、余程の特長がなければ敵わない。「Delphi」という言語だけが特徴、という状況は厳しいでしょ。
Delphi for .NETが搭載しているVLC for .NETがどのようなものかまだ見ていないので「推測」だが、VLC for Win32とのソースコード互換性を維持するための薄いラッパーなのだとしたら、やはり勝負にならない気がする。
「もう遅い。今更何やったって間に合わないよ」
それは残念（苦笑）。現実問題として厳しい道のりだろうが、まだまだ事業を継続するという意思は伝わってくるし、俺は何らかの新機軸を打ち出して健闘して欲しいと思うが。個人的にはkylixの復活を期待したい。EclipseのCDTも良くできてるけど、RADではないし。もしくは、よりネイティブコードに特化したRADツール。ニッチではあるけれども、ネイティブにこだわる開発者は多い気がする。
http://d.hatena.ne.jp/yamagw/20060605/1149490313
ちなみに、以前コメントを頂いた「とおりすがり」さんと同じ人物だと思った理由だが、今回の「とおりすがり」さんと同様の、Delphiユーザーであると推測される発言、記事に対し事細かな反応する、という特徴が同じだから。まぁ、今回は「横柄な物の言い方」という点が確かに違うか。勘違い容赦を＞両方の「とおりすがり」さん
