アカウント名:
パスワード:
たいして普及しなかった.NETはもう捨てていいので、AppleみたいにネイティブのObjective-C一本でOSXからiOSまで書けちゃう統合されたAPI&フレームワークを作ってほしいけどね。WinRT、WinPhoneでその方向に進みつつあるのは歓迎だが歩みが遅すぎるしMSは迷走が多いのでもうね。
AppleこそOSX&iOSでしか使えないObjCという言語を捨てて欲しい。
Cocoaのクロスプラットフォームはほぼ死亡しているし(CocotronもOpenStepも…)、せめてC++からCocoaを使えるようにして欲しい…
現代のクロスプラットフォーム性は、C/C++を呼べるかで決まるんだよ。その点でboost, sqlite, OpenCV...C/C++のライブラリが「そのまま」使えるObjectiveCのアドバンテージは大きいんだよ。C#だとそうはいかないね。
C# で C/C++ な DLL とかが直接呼べなかったら、そもそも .NET Framework が Windows (Win32 API) の上に構成できる訳がないんですが、何言ってるんですか?
すべてのコードを純粋なマネージドコードのみで完結した場合の最大のメリットはどのようなアーキテクチャーやエンディアンになっているかを問わない事。 アンマネージドの世界に足突っ込むなら C/C++ で書かれたコードをアーキテクチャーやエンディアンに縛られながら、システムコールをダイレクトに叩くコードとか普通に書けますよ。
保守性の面などからも、普段はあまり好まれるような記述方法ではありませんし、クロスプラットフォームと言う点では「当たり前だけど、アーキテクチャーやエンディアンの違いですべてライブラリーを作り直す必要がある」ネイティブコードを「現代のクロスプラットフォーム」と評価する発想は、ちょっと良く分かりませんけど。
結局実行環境ごとに作り直すのなら、アーキテクチャやエンディアンに依存させても問題ないというのが現実では?デスクトップパソコンにライブラリと実行バイナリを別々に配布するという形式ではそうはいかないかもしれないけど。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
最初のバージョンは常に打ち捨てられる。
10年遅かったかな (スコア:-1)
たいして普及しなかった.NETはもう捨てていいので、AppleみたいにネイティブのObjective-C一本でOSXからiOSまで
書けちゃう統合されたAPI&フレームワークを作ってほしいけどね。
WinRT、WinPhoneでその方向に進みつつあるのは歓迎だが歩みが遅すぎるしMSは迷走が多いのでもうね。
Re: (スコア:0)
AppleこそOSX&iOSでしか使えないObjCという言語を捨てて欲しい。
Cocoaのクロスプラットフォームはほぼ死亡しているし(CocotronもOpenStepも…)、せめてC++からCocoaを使えるようにして欲しい…
Re: (スコア:0)
現代のクロスプラットフォーム性は、C/C++を呼べるかで決まるんだよ。
その点でboost, sqlite, OpenCV...C/C++のライブラリが「そのまま」使えるObjectiveCのアドバンテージは大きいんだよ。
C#だとそうはいかないね。
Re: (スコア:1)
C# で C/C++ な DLL とかが直接呼べなかったら、そもそも .NET Framework が Windows (Win32 API) の上に構成できる訳がないんですが、何言ってるんですか?
すべてのコードを純粋なマネージドコードのみで完結した場合の最大のメリットはどのようなアーキテクチャーやエンディアンになっているかを問わない事。
アンマネージドの世界に足突っ込むなら C/C++ で書かれたコードをアーキテクチャーやエンディアンに縛られながら、システムコールをダイレクトに叩くコードとか普通に書けますよ。
保守性の面などからも、普段はあまり好まれるような記述方法ではありませんし、クロスプラットフォームと言う点では「当たり前だけど、アーキテクチャーやエンディアンの違いですべてライブラリーを作り直す必要がある」ネイティブコードを「現代のクロスプラットフォーム」と評価する発想は、ちょっと良く分かりませんけど。
Re:10年遅かったかな (スコア:0)
結局実行環境ごとに作り直すのなら、アーキテクチャやエンディアンに依存させても問題ない
というのが現実では?
デスクトップパソコンにライブラリと実行バイナリを別々に配布するという形式ではそうはいかないかもしれないけど。