.net - ムーアの法則が成立したことで、フレームワークからの移行があると思いますか?

Question

フレームワークは、OS の速度と難読化を犠牲にしてコーディングを簡素化します。ムーアの法則が成立したことで、フレームワークからの移行があると思いますか?

Vista が目立った成功を収められなかった理由の 1 つは、XP よりも実行速度がはるかに遅かったことであり、コンピューターの速度が過去ほど大幅に向上していなかったため、この変更は一歩後退したように見えた.

何年もの間、CPU の速度はソフトウェアの速度を上回っていたため、OS の難読化と肥大化の層を追加した新しいフレームワークはほとんど害を及ぼしませんでした。Windows 95 が今日のハードウェアでどれほど高速に動作するか想像してみてください (メモリを少し調整した場合)。Win2K と WinXP は大きな改善点であり、コンピューターが高速になったために速度が遅くなっても問題はありませんでした。

しかし、何年も前に、MS ファウンデーションクラスで記述されたプログラムは、API に直接記述された同じことを行うコードほど鮮明に見えないことに気付きました。.Net などのこれらのフレームワークの急増は、この状況を悪化させるだけなので、「C」で直接 Win32 API (または他の OS の同等のもの) にコードを記述できることを発見する可能性はありますか?書くのに時間がかかったとしても、強力な競争上の優位性になりますか? それとも、開発期間が長くなるというトレードオフは、それだけの価値がないのでしょうか?

score 2 · Accepted Answer

アプリを高速化するための選択的圧力があれば、システムの速度をあまり低下させずに機能をカプセル化するフレームワークをより上手に作成できるようになると思います。

ピクセルを処理する Boost::Gil フレームワークは、多くのインライン化された関数に要約される優れたテンプレートベースのシステムです。コンパイラは、ピクセルのラッパーがなく、値に直接アクセスした場合と同じ出力を作成します。

つまり、あなたの質問に関しては、フレームワークが高速で無駄のないものであることを保証するために、ボールはフレームワーク作成者の法廷にあると思います。これは、使用中の機能を検出し、未使用の機能に関連するコードを削除することを意味する場合があります。

score 1 · Accepted Answer

多くのソフトウェアのパフォーマンスは問題ではありませんが、市場に出す時が来ました。これは多くの場合、「社内」で、チームがアプリの初期バージョンをユーザーの前に表示することを、アプリの速度（または安定性）よりもはるかに重視する場合があります。これに加えて、適切に記述されたフレームワークは、フレームワークの設計の対象となるアプリケーションの開発を簡素化し、フレームワークが利用可能な場合は使用しないことに腹を立てることがよくあります。もちろん、あなたはフレームワークがあなたの目標への道の80％を達成し、それからあなたを高く乾燥させておくことができるというリスクを冒していますが、まあ、あなたは通常、その最後のためにフレームワークの外で働くことによってそれを軽減することができます20％。ソフトウェアのすべての優れた点と同様に、多くの場合、それはすべて階層化に関するものです。最初に「フレームワーク」として.Netを選択します次に、アプリの一部に特定の.Net GUIの「フレームワーク」を使用し、他の部分には別のソケットの「フレームワーク」を使用することにします。または、C ++で作業し、フレームワークとしてboostを使用するか、より抽象化され、（うまくいけば）コーディング速度が向上する、より焦点を絞ったフレームワークを選択することもできます。

問題は、多くの場合、適切なフレームワークを選択し、開発を容易にするためにどれだけのパフォーマンスを犠牲にするかを決定することです。

score 1 · Accepted Answer

フレームワークは、共通の機能をカプセル化するために存在します。これは決して変わらない

ムーアの法則は死んだと思う理由は何ですか? MIT の学生がナノワイヤー回路を自己組織化するバクテリアを育てているが、ムーアはまだ死んでいない...

score 1 · Accepted Answer

これが実現するための課題は、現在存在する多くのフレームワークの「松葉杖」を使わずに自信を持ってコードを記述できる十分な数の開発者を見つけることだと思います。ますます多くのコンピュータサイエンス/ソフトウェアエンジニアリングのアカデミックコースが、世界の C を無視して Java と .NET を支持しています (私が Java や .NET に反対しているわけではありません。、他の多くの人がそうしています) それが今日の業界が要求していることだからです。

その結果、最近の卒業生は、多くのフレームワークを当然のことと考えています (「ボンネットの下で」何が起こっているかを自分で調べることに十分な関心を持っている場合を除きます)。独学の開発者は、習得しやすく、使いやすいものを求める傾向があります。繰り返しになりますが、これは、使用するフレームワークの舞台裏で何が起こっているのかを熱心に学び、苦労している人々にもかかわらずです。

したがって、以前の投稿に同意します。おそらく、フレームワークの作成者が、効率的に動作することを保証するための創造的な方法を考え出す必要があります。私の印象では、かなりの数の開発者が、フレームワークがどのように X を実行するかにあまり関心がなく、自分たちの作業をより迅速に行うのに役立つように、フレームワークに X を実行してもらいたいだけです。私の意見では、フレームワークから離れなければならないことは、多くの人にとって簡単なことではありません。

score 0 · Accepted Answer

「この言葉は私たちの業界では非常に過負荷になっています。MFCや.Netのようなものを意味する場合、それらはここにとどまると思います。実行時のパフォーマンスとは何の関係もありません。コードの再利用、保守性、関心事の分離。"

多くの場合、実行時のパフォーマンスと多くの関係があると言わざるを得ません。フレームワークを呼び出し、それがAPI呼び出しを直接呼び出した場合でも（この場合、意味はありませんが、これが速度の最良のケースです）、追加の関数呼び出しのパフォーマンスが低下します。時々重要になります。

また、私は認めなければなりません、元のポスターを尊重したいのですが、Vistaは一歩後戻りです。「機能」ではないDRMのようなもののためにそれは遅いです。Windows XPは、多くの点でWindows2000よりも実際に高速でした。Vistaは確かにそうではありません。

score 0 · Accepted Answer

WinRTは、まさにこれに対処すること、つまり私たちのケーキを持ってそれを食べる試みではありませんか？WinRTは、追加のレイヤーではなく、.NETで直接使用するC / C++ベースレベルのOSAPIの代わりになるため、速度を維持しながら、より高いレベルの対話を提供することになっていると私は理解しています。

score 0 · Accepted Answer

「フレームワーク」とは正確には何を意味しますか。この言葉は、私たちの業界では過負荷になっています。MFC や .Net のようなものを意味する場合、それらは定着すると思います。実行時のパフォーマンスとは何の関係もありません。それらは、コードの再利用、保守性、および関心の分離と関係があります。

ちなみに、Vista はフレームワークを使用しているため遅くはありません。DRM のような役に立たないフレームワークをたくさん使っているので遅いです。MS はゆっくりとより官僚的な企業になりつつあるため、低品質に悩まされる可能性もあります (私の認識です) 。Vista は目的の欠如にも悩まされています。アップグレードする価値のあるものは何もありません。GUI のフロスティングで補正しようとしました。

score 0 · Accepted Answer

フレームワークから離れることは後退であり、そうならないことを願っています。

.net - ムーアの法則が成立したことで、フレームワークからの移行があると思いますか?

8 に答える 8

Related

Reference