Мнение редакции может не совпадать с мнением автора оригинала. По мнению многих, ООП является жемчужиной информатики. Идеальное решение для организации кода. Конец всем проблемам. Единственный верный способ написания программ. Дарован нам самим истинным Богом программирования. Но это не так. Люди начинают уступать под тяжестью абстракций и...
ここに詳しい統計があるのですがhttps://githut.info/、14年のことです。
githubの新鮮な統計情報https://madnight.github.io/githut/#/pull_requests/2019/2
この記事に あるプロの意見を読むことは、誰にとっても有益なことだと思います。
グッドラック
この記事に あるプロの意見を読むことは、誰にとっても有益なことだと思います。
この記事のすべての（完全に偏った）結論は、一つの単純な質問によって相殺されます。
FPは昔から存在するものですが、こんなにすごいのに、なぜいまだにこんなにニッチが狭いのでしょうか？
決して、OOPが最高のコンセプトだとか、OPがクソだとかいうことではありません。
この記事のすべての（完全に偏った）結論は、一つの単純な質問によって平準化されます。
FPは昔からあるものですが、こんなにすごいのに、なぜいまだにこんなにニッチが狭いのでしょうか？
その答えが載っているのが、この記事です。よく読んでないんだろう。
その答えが載っているのが、この記事です。
完全に偏った、何の意味もないもの。
実際にコードを書いている開発者がいる。プログラミングをまったく知らないマネージャーもいるかもしれません。
ですから、テクノロジースタックは必ずしも開発者が選ぶわけではありません。また、あるスタックによってチームがより効率的に問題を解決できるのであれば、その技術を知り、所有していなくても理解することができます。
それでもこの記事が質問の答えになると思いますか？
この記事に あるプロの意見を読むことは、誰にとっても有益なことだと思います。
グッドラック
ここで、いつものように極端な言い方をすればハンマーとスレッジハンマー、どちらが優れているかという議論と同じです。
C#では良いツールは書けませんが、ピュアCでは真面目なアプリケーションで突っ込んだ論理チェーンの記述やデバッグに疲れます。
だから、この記事は何の役にも立たない。
いつもそうなんです。極端な言い方をすればハンマーとスレッジハンマー、どちらが優れているかという議論と同じです。
C#では良いツールは書けませんが、ピュアCでは真面目なアプリケーションで突っ込んだ論理チェーンの記述やデバッグに疲れます。
だから、この記事は何の意味もない。
もちろん、この記事には真実があるのだが...。少なくとも、その継承は本当に必要とされていないメソッドやフィールドを "プル "しますが、残念ながら、あなたはすべてのために支払わなければならない - それは時間を節約しますが、それはメモリ使用量やソリューションの全体的なパフォーマンスを増加させるかもしれませんが、5すべてではないそう悲しい、コンパイラとコードの最適化のレベルは非常に急である、だから短い開発時間のために良いソリューションで頻繁に出力されます。
C＃については、よく、それが他の目的を持っているかのように、それはすぐに特定のPCまたはPCの限られたグループでの結果を得るために純粋に "Windows言語 "であり、更新プログラムをインストールしていない場合でも、.Netは、アクセス権を持っていないPC上で重大なエラーを引き起こす可能性があり、これは非常に高価ですキャッチ - C＃での取引のためのパネルを書いたすでに仮想マシン 上でそれをチェック、更新のすべての "パッチ "をインストールしていない場合は、プロジェクトが予測できない跳ね上がり;)ができないもちろん、.Netの最も新しいバージョン向けに書くこともできますが、問題があります。GitHub上のすべてのニュースは、新しい.Netビルドの下に投稿され、つまり、その開発だけに制限されます。
一般的に、他の場所として - 技術革新は "痛いと長いと悲しい "であり、あなたはITの巨人によって設定されたトレンドに従う必要があり、その後すべてが迅速かつ問題なく書かれている、よくマイクロソフトは、彼らがOOPスタイルでできたすべてを書いた、あなたはそれをすべて使用する必要がありますか、すべてのWinFormなどトンやWin-95以来書かれてコードの数千人をゼロから書くことになります））））。
確かに、この記事には少し真実味がありますね......。
少し？) 実際、その通りなんです。しかし、著者は真相を明らかにせず、（少なくとも私にとっては）当たり前のことを述べています。 状態変化の問題点については、経験を積んだプログラマなら誰でも同じように気づくことだと思いました。ちなみに、最近、よく似た記事を見かけましたが、もっと短いものです。しかし、おそらくそれは、機能主義者とオープンソースプログラマーの永遠の論争なのでしょう )。
しかし、実際には、OOPを 正しく使うことを妨げる人はいません。 著者でさえ、イミュータブルなオブジェクトを使うことができると述べています。 そして、説明されている問題の99％はすぐに解決します。 つまり、すべては、使用するパラダイムではなく、手をまっすぐ伸ばし、肩に頭を置くかどうかにかかっているだけなのです。
もちろん、一般的なOOP言語がオブジェクトの可変性を制御する手段を提供しないことが、このプロセスを複雑にしていますが。 そこで、const/readonlyの代わりにimmutableという キーワードがあれば、本当にクールだと思います。
関数型言語が 不人気な理由については、筆者は同意できません。 まず、そのようなコードに対する認識がより複雑であるように思います。 これは、単にOOPとFPの対立ではなく、命令型と関数型の対立です。 前者は、多くの人にとってより身近で直感的に理解しやすいと私は考えています。私は関数型言語を通信で知っているだけなので、客観的に判断することはできませんが、例えば、ラムダを多用したコードを見ると、認知的不協和を起こします。 複雑で入り組んでいる。 おそらく、ほとんどの人もそう思っているでしょう )
また、関数型言語は外部環境とのインタラクションに関わる多くのタスクを想定していません。 たとえば、GUIです。何らかの方法で、イベントとイベントの間にグローバルに変化した状態を保存する必要がある場合。
少し？) 実は、その通りなんです。しかし、著者はAmericasを明らかにしているわけではなく、これらのことは（少なくとも私には）明白なことです。 経験を積んだプログラマなら、状態が変化することの問題点を同じように認識するのではないかと思いました。ちなみに、最近、よく似た記事を見かけましたが、もっと短いものです。まあ、機能主義者とオープンソースプログラマーの永遠の論争なんでしょうけど......。）
しかし、実際には、OOPを 正しく使うことを妨げる人はいません。 著者でさえ、イミュータブルなオブジェクトを使うことができると述べています。 そして、説明されている問題の99%はすぐに解決します。 つまり、すべては、まっすぐな手と肩に頭を置くかどうかにかかっており、使用するパラダイムには関係ないのです。
もちろん、一般的なOOP言語がオブジェクトの可変性を制御する手段を提供しないことが、このプロセスを複雑にしているが。 const/readonlyの代わりにimmutableという キーワードがあれば、クールだろうなあと思う。
いずれにせよ、近い将来には何も変わらないだろう、ITジャイアントはこのパラダイムをサポートし、それはソフトウェア開発者が動作するように、より強力なハードウェアを必要とする複雑な実装を行うだけでなく、OSまたはOOPの形で既製のライブラリとのコンパイラのための彼らの文書を提示するために強制的に開発者に有益であるかもしれません... ...。などなど、無限大に広がります;)
このOOPの話は、医学者がラテン語の知識を義務付けられたと考えることができます。必要ではありませんでしたが、専門家レベルのコミュニケーション手段として、使う必要がありました ;)