科学プログラミング：パート1

プログラミングの科学-本当ですか？ 言語にはいくつありますか？なぜ、ホリバーは、ある言語が他の言語よりも優れているのでしょうか？ 興味があれば-猫の下でお願いします。



むかしむかし、プログラムを書くためのさまざまなアプローチやプログラミング自体が議論され批判される「聖戦」があり、主にオブジェクト指向プログラミング（1、2、3）が批判されています。



エゴール・ブガエンコは、デビッド・ウェストのアイデアを使用して、実際の例（ 1、2 、 ビデオ ）でPLOを批判し、私が理解しているように、最近理論の方向に進んだ。 これらの紛争の有効性はゼロになる傾向があります。 なんで？ これらの紛争はすべて、理論的研究に基づいてではなく、個人のいくつかの思考、慣行、意見の実施に基づいてすでに実施されているためです。 これらの論争や言葉からの「戦争」には、その理論、仮説、公理、実験、証拠、事実に関する科学的な方法やアプローチは最近ありませんでした！



数学では、他の科学と同様に、定理や理論には証明が必要です。 例： ピタゴラスの定理 。 最初に理論、次に実践が続きます。 プログラミングでは、このアプローチは数十年にわたって守られていません。 すべてが「伝道者」または「預言者」と呼ばれることもある個人の教義と意見に置き換えられます。 彼らは、その言葉遣いで、必要なアイデアだけを大衆に促進し、理論や証拠を気にかけません（ITカンファレンスとプレゼンテーションを参照）。 科学はここにあり、宗教はどこにありますか？ そして、私たちは遠い昔に書かれた言葉に対する不明瞭さや信仰に陥らず、証拠を必要としませんか？ 平らな地球の支持者について聞いたことがありますか？ それは説得と粘り強さのアプローチの点で何かに似ていますか？



そして、過去30-40年のそのような勇気で、OOPまたはFP説教者からの宗教的信念に盲目にされたプログラマーは、他の抽象化の上に抽象化を構築し、他の言語の上に新しい言語、古いものの上に新しいフレームワークとライブラリーを作りました。 そして、なぜこれがすべて必要なのですか？ プログラムの作成に関する私の作業の簡素化と生産性のため。 この道だけが行き止まりに至りました。 単純化するのではなく、アルゴリズムではなく、次のファッショナブルなフレームワークのAPIとドキュメント、またはいくつかのドキュメントがより複雑になって研究されたためです。 今、彼らは自分のコードだけでなく、他の誰かのバグも探し始めました。 コードのデバッグは、大量のプロキシ、アーキテクチャパターンとデザインパターン、ヘルパー、フレームワーク、およびライブラリを介して実行する必要があります。 そして、研究が示すように、OOPの使用によるコードの記述速度の向上はまったくありません。



少し歴史。 どのようにすべてが始まりましたか？ 最初は手続き 型プログラミングがあり、次に構造 的プログラミングと命令型プログラミングが登場しました。 一部の人々は、オブジェクトの概念を導入することを考えました-それがオブジェクト指向プログラミングがどのように生まれたかです。 そしてその瞬間、急激な変化があり、業界全体が現在の状態に変わりました。



オブジェクトの導入は理論的に正当化されるべきでした。 しかし、これは起こりませんでした。 代わりに、各言語は独自の方法でオブジェクトの概念を導入しました。 また、各言語開発者は、OOP仮説を好みと色に解釈しました。 特に頑固な原理主義者は、数学、リスト、 高階 関数に基づいた関数型プログラミングを思いつきました。 数学は必要かつ有用なものであるため、それは深刻で、少し科学的にさえ聞こえますが、現実世界に関連するリストと機能は何ですか？



純粋なAFが状態を使用せずに解決するタスクは何ですか？また、人間にとって最適で便利で正しい方法があります。そのような質問はAFの「預言者」に尋ねられるべきです。 そして、彼らは彼に尋ねます（ 1、2 ）。



関数型言語の開発者は、応用数学の分野から現実の世界に移行するために、OOPパラダイムのいくつかを適用し始めました。 これに対して、一部のOOP言語はFPからのパラダイムを実装しました。 そして「たくさんの人に混じった馬」（c）



その結果、歌のように現在の言語で純粋なOOPとFPパラダイムを実装しました-「私は彼が何を愛していたのか、そして何を愛していたのか」 そして、理論的な作業と科学的基盤がなければ、これらの言語はすべて、開発者の空想と欲求の単なる形にすぎないことがわかります。 そして、100以上のそのような言語があります！ そして、そうではないはずです！ 理想的には、それらに基づいて構築された低レベル言語は2つ、高レベル言語は3〜4だけにする必要があります。



オブジェクトの概念を導入したとき、彼らは彼らの周りに見たもの、つまり人間と動物を基礎として取ったと推測できます。 そして、これは後に大きなサイズに成長する主な間違いでした！ したがって、継承が現れた可能性があります（祖先と子孫およびそれらの間の関係は継承によって説明されますが、世界の他のオブジェクトについてはどうですか？また、「継承」という言葉の定義は実際の世界ではどういう意味ですか？血液とDNA？窒素ベース？）。 他の用語、すなわち抽象化、カプセル化、および多態性は、どのように具体的にOOPを指しますか？ そして、どういうわけか彼らはそのような接続の証拠を提供することを気にしませんでした。 結局のところ、あなたは何でも書くことができ、それは論理的に聞こえます、唯一の問題はここに提示された引数がOOPと関係がないということです。 実際、OOPでは、論理的な誤りが発生しました-（不完全な誘導 ）1つの特定のケースから一般的なセット全体への移行が行われました。 これを示すために、例を挙げます-継承を基礎として生き物だけをとることができるなら、なぜ同じ論理に従って、惑星や銀河全体を基礎としてはいけないのですか？ 結局のところ、惑星や銀河も宇宙からの他のオブジェクトの相続人であり、状態と何らかの行動を持っています。 または、すべての山を、継承のない、実際には動作のないオブジェクトとして想像してください。



他のオブジェクトからの継承を使用する必要がある、または使用できるオブジェクトがあるのはなぜですか？ 「証明する」という言葉を強調します！



結局のところ、あなたがそれについてたくさん考え始めたら、それから漠然とした予感があります：それは欺き、操作と間違いなしではできませんでした！ 結局のところ、単語の価値は、事実とデータに基づいて論理的かつ合理的にそれらを証明するために、可能な限り評価されます。 それ以外の場合は、ピンクのユニコーンまで、あらゆる種類のナンセンスを思いつくことができます！ または別の方法で-あなたの言葉は精神病院から逃げた宗教的な狂信的な過激派の言葉とどのように違いますか？



しかし、常にそうではありませんでした。 科学的アプローチの例を次に示します。



1. 本 「電子デジタルマシンとプログラミング」 A.I. キトバ 。



2. ベーム・ヤコピニの定理 。



私たちが望むほど多くはなく、おそらくどこか他の場所に科学的研究の例がもっとたくさんありますが、それらを見つけることは非常に困難です。 圧倒的多数は、あらゆる種類の「聖書」と記事を論争と議論に使用します（実際には、これはこのプロセスには大きすぎる言葉です）。



科学をプログラミングに応用して、その成果、結果、方法のみに頼ってみましょう。



用語の基本的な定義を紹介します。



オブジェクトは、 化学要素としても知られている最小の不可分なエンティティであり、多くのプロパティと多くの動作モデルがメソッドによって実現されています。 オブジェクトには2つのタイプのメソッドがあります：1）プロパティを取得するため、2）状態を変更するため。



動作モデルは、オブジェクトと対話するためのインターフェースです。



プロセスは、要素（重力、光、加熱、放射）に対する相互作用の一種です。



事実：



1.周囲の世界のすべては、分割不可能な最小の化学元素で構成されているため、多くの行動をとる化学元素を主要な対象の基礎とする必要があります。



2.化学元素を組み合わせてセットにすることができます。



3.化学元素は互いに相互作用し（ 反応 ）、異なるプロセスの影響下にあります。



4.各化学元素は、一定期間独自の状態を持ち、外部プロセスの影響下で変化する可能性があります。



5.プロセスはオブジェクトまたはそのセットでもあり、動作のモデルの助けを借りて、化学要素を変更できます。



記載された事実とデータに基づいて、要素のプロパティと動作、要素間の相互作用とプロセスを分析し、いくつかの原則を概説します。



1.オブジェクトには、基本（原子）と反応（プロセス）の2種類があります。 基本オブジェクトは、特定の条件に従って、状態を変更するメソッドから新しいオブジェクトを返すことができます。



2.反応するオブジェクトは、それらが動作するオブジェクトのインターフェースを知っています。



3.オブジェクトのすべてのプロパティは、プライベートで不変、オブジェクトはパブリックで不変、メソッドはパブリックのみとして定義する必要があります。



4.チェック例外には、例外が1種類しかありません。



5.要素にはNULLなどはありません。 代わりに、0、空の文字列、1つの要素を持つ配列、または要素の空のコレクションのいずれかが必要です。



6.要素はどの形式でも継承されません。



7.また、注釈、型キャスト、内部クラスとローカルクラス、匿名クラスとラムダ、列挙型、単語super 、 extends 、 ?を含むジェネリックはありません。 （ T、V、U、Rのみ ！）、静的メソッドおよび属性。



8.抽象クラスとメソッドはありません。



9.基本オブジェクトは、変更可能なデータを返すことはできません。 このオブジェクトに依頼することができるのは、オブジェクトの保存と変更を担当するだけだからです。 基本オブジェクトの変更は、反応オブジェクトの助けを借りてのみ発生します。



10.状態を保存するには、配列、キュー、コレクション、リスト、マップなどのデータ構造を使用する必要があります。



11.相互に反応するオブジェクトは、別のオブジェクトを返すか、状態を変更できます。



12.データ構造は非常に重要です。 反応オブジェクトは、メソッドのパラメーターとしてさまざまなオブジェクトの多く（コレクション）を受け取り、メソッドの結果としてさまざまなオブジェクトを返すことができます。



13.メソッドは、 形式 構文 （ ステートメント 、 論理代数および論理演算 ）および言語構文の形式で表現されたサイクルを使用して、データを処理し、結果を返すか、オブジェクト（またはそのセット）の状態を変更します。



14.メソッドの本体は、1〜10行のコードを隙間なく占有する必要があります。



15.クラスの本体は、モニター画面の5行から2つの高さまで、隙間なく占有する必要があります。 クラスとメソッドの本体が小さいほど優れています。



仮説：



1.プログラミング言語（プログラミング言語）から継承、静的メソッドと属性、抽象クラスの可能性を排除すると、プロジェクトのコードは少なくとも10〜20％少なくなります。



2.プロジェクトのコードからすべてのデザインアンチパターンを除外すると、コードは少なくとも10〜15％少なくなります。



3.オブジェクトが小さくシンプルであればあるほど、オブジェクトの理解、テスト、および変更が容易になります。



4.オブジェクトのテストが高速になります（p。3を参照）。



5.メソッドのデバッグが高速になります（p。3を参照）。



6.新しいクラスの記述が高速になります（3項を参照）



したがって、事実、原理、および作成された仮説（実験的に確認された場合）を考慮に入れて、エレメンタリまたはアトミックプログラミング理論を導き出すことができます。



60年代および70年代にそのようなアプローチが主要な標準として受け入れられた場合、現在の言語とアプローチの既存の動物園とそれほど否定的で混乱することはありません。



次の部分では、仮説を実験的に証明し、理論を補足します。 コメントで理論的な質問をしてください。 この問題を真剣に考え、考えてください。