プログラミングに関する考察

アリストテレスからヴィットゲンシュタインへ

優れたプログラムを作成できる言語は必要ありません。 悪いプログラムを書くことが不可能な言語を探しています。 著者

まえがき

科学としてのコンピューターサイエンスの発展は、最初のアルゴリズム計算のほとんど目立たないストリームから遠い過去（紀元前3世紀のユークリッド、紀元前19世紀のバビロン、そしておそらくそれ以前）に生まれた川のようです。 歴史をゆっくりと進んで、川は川に合流し、川は何世紀にもわたって水を運び、関連する分野から支流を引き込み、威厳と力を蓄積し、最終的にナイアガラの滝を2番目から3番目の千年紀に破壊し、急速に荒れ狂う流れに変わります過去から未来まで何百万人もの人々を捕らえて運びます。







その後、乱流で急流に投げ込まれたブラウン粒子は、停滞した沼地に流れ込み、次に浅い水に流れ込み、渦になります。 情報技術の世界は、神秘的で、不安定で、予測不可能であると見なされています。 しかし、絶え間ない動きの喜び、困難の英雄的な克服、時間とともに新しい印象の万華鏡の必死の回転は、憧れ、精神のだるさ、そしてbus騒を一瞬上に立ち、この必死に泡立つ流れを横から見て、嵐の川の一般的な方向ではないにしても、少なくともあなたがガタガタしているダクトの最も近い曲がり角。

はじめに

「科学者が8歳の子供に自分が何をしているのかを一般的に説明する方法を知らない場合、彼はcharlatanです」

カート・ヴォネガット、猫のゆりかご、1963



A.「特効薬はありません」とF.ブルックスは前世紀に語り、長い間、高貴な騎士の熱意を「複雑さのドラゴン」との戦いでプログラミングから冷やしました。 それ以来、「His Majesty the Dragon」は、機能の悪いプログラムの代わりに、ユーザーはますます強要されますが、それはそれほど良くはありませんが、ますます多くのプロセッサリソースとコンピューターメモリを消費します（「何？ c）B. Titamir）。 Dragonを喜ばせるために、「code＆fix」（「do and remake」）のようなプログラマーの軍隊全体が成長しました：「スキルではなく、数字で！」、「リファクタリングは私たちのすべてです！」、「共和党のメンバーでもプログラミングできます！」、バナー。 ドラゴンを養うために、彼らは毎日ギガバイトのソースコードを作成しますが、その多くはユーザーによって決して請求されることはありません。 長年にわたって、この嫌なドラゴンは成長し、「アイデア。 歴史的な必要性。 州の関心。 強力な要因であり、私たちの共同努力の正当性です。」



B.別の「銀の弾丸」を探すつもりはありませんが、それが存在しないからではなく、どのように望むにしても、ドラゴンを信じるのは難しいからです。 ドラゴンは、原則として、以前の経験では説明できない現象に遭遇すると、人々の心の中に生まれます。 コンピュータサイエンスの場合、白い斑点の存在は驚くべきことではありません。白い斑点は人間の知識の非常に若い分野だからです。







Q.ドラゴンを信じるプログラマーはほとんどいませんが、多くのプログラマーは複雑さが主観的な概念であると信じています。 「難しい」という言葉の定義の1つは難しく、混乱を招きます。 たとえば、難しいタスク、複雑な（または、より正確には、混乱する）プログラム。 ある人にとって困難で混乱しやすいことは、他の人にとっては簡単で明確な場合があります。 それらに修正された、サイクルとエピサイクルの地球中心プトレマイオスモデルにおける惑星の運動は複雑に見えます。 ケプラー楕円による太陽中心モデルの動きは単純です。 ビット形式で画像を編集するのは難しいでしょうが、グラフィックエディタで編集する場合は簡単です。 マンデルブロ集合の画像は、開始されていない観察者の複雑さによって魅了されますが、適切な言語ではマンデルブロ集合は非常に簡単に説明されています_。 1、2、3、...）は無限に行きません。」



G.本質的に難しくて混乱するものはありません。 何かを理解しようとしている人にとって、何かが難しくて混乱しているように見えるだけです。 多分、私たちが開発するソフトウェアシステムは、私たち自身が複雑で混乱させますか？ ERPシステムSAP / R3に5万以上のテーブルがあり、ロシア語の最大の辞書には約5万4千の名詞しかないのはなぜですか？ ときどき、自分がプログラムに求める単純な機能を追加するのが非常に難しい理由を顧客に説明しようとして、私はキャラタンのように感じることを後悔しています。



D.この投稿では、1つのことを除いて、自分にはタスクを設定しません。あまり関係のないことを書き留めますが、一部の場所では、過去20年間に考えてきた最も一般的なプログラミングの問題についての不完全な考えです。 時間は容赦なく、すべての必要な「石」を収集し、そこから新しいプログラミングパラダイムの十分に強力な基盤を構築するには、単に十分ではないかもしれません。 私の考えが誰かに役立つことがわかったなら、私は満足します。そしておそらく、同僚の何人かを行方不明の「石」を探しに行かせさえします。

アブストラクト

「適切な言語で定式化すると、すべてのタスクが簡単になります 」I.M. Gelfand

プログラムについて

プログラム=タスク+モデル+アルゴリズム+データ構造



このプログラムは、特定の問題を解決するために作成されています：フォボスへの飛行中に宇宙船を制御し、人々の流れの中の写真から犯罪者を認識し、ある携帯電話からSMSメッセージを受信して​​別の携帯電話に転送します。



モデルは、プログラムがタスクを解決するために何をすべきかを記述しますが、どのようにそれを行うべきかを記述しません。 人間の思考で作成されたドメインの（メンタル）モデルは、現実世界の現象（重力場や地球の大気中の宇宙物体の動きなど）と、オンラインストアなどの理想的な概念の両方に関連付けることができます。 モデルは、タスクを解決するための将来のツールの精神的なイメージです。



プログラムを定義する際の重要な概念はtaskです。 技術システムを解決するタスクと切り離して議論するのは理不尽なので、作成中の目標以外のプログラムを考慮することは意味がありません。 さまざまな問題を解決するために、1つのサブジェクトエリアでも、さまざまなモデルが作成され、さまざまなプログラムが開発されます。 惑星間飛行の軌道を計算するには、重力場を太陽と惑星の点質量の重ね合わせとしてシミュレートすれば十分です。 重力モデルの近地球軌道での衛星の動きを予測する実際に許容できる精度を得るには、調和関数の拡張または特別に選択された点質量のシステムの形で地球の磁場の不均一性を考慮する必要があります。 そして、一般相対性理論からの時間と空間のモデルの関与がなければ、グローバルな衛星ナビゲーションシステム（GLONASS / GPS）の特定の問題の解決は不可能です。



したがって、プログラムは、私たちが直面している電卓が理解できる言語で書かれたソリューションです。

オブジェクト指向アプローチについて

現在、プログラムを記録するために約2500のプログラミング言語が作成されています。 それらの発達の歴史は、人間の発話の発達の歴史にやや似ています。 人の最初の発言の内容は、他の個人が彼に提供できる援助の要件だけで構成されているという意見があります。 「人間になった人の最初の声明が、開発された言語の助けを借りて表現された場合、必然的に「 give ！」、「 Carry ！」、「 Break ！」、「 Cut ！」、「 Beat ！」、 持ち上げてください！」、「 pull ！」など。 さらに、これらのコマンドには、このアクションを正確に適用する必要があるものを正確に示すジェスチャが付随していました。 まあ、命令型プログラミング言語のコマンドに非常に似ています！ たとえば、メモリアドレスまたはレジスタを正確に示すアセンブラコマンド。



人はまず、全体としてとられた実際の状況を別の状況と区別することを学びます。 これらの状況の個々の要素（アクションが実行されるオブジェクト、オブジェクトに対して実行されるアクション）の分離は、後で実行されます-実際の活動では、人は自分を取り巻くものにますます精通し、その特性と互いの関係について学びます人自身に。 徐々に、特定の状況（プログラミング、データ）およびアクション自体（プログラミング、機能）からアクションのオブジェクトを分離し始めます。 行動の対象を区別する能力の習得は、原始人の精神発達における真の革命でした。 そして、これはすでにプログラミングで使用されるオブジェクト指向アプローチ（OOP）に非常によく似ています。 少なくとも言語の最新の実装：C ++、Java、C＃。



人は自然言語を使用して、自分の世界の精神モデルを具体化し、別の人に移します。 プログラマーは、OOPを使用して、ソフトウェア製品のメンタルモデルを具体化して、実行のために計算機に転送します。 しかし、OOPは本当に私たちの川のメインチャンネルですか？ それとも、急な曲がり角の前の静かな背水であり、それはゆっくりとした、時には逆流の水が特徴で、すでに沼になっていますか？



OOPを使用して物理世界のメンタルモデルを構築することには、アリストテレスの作品に由来する2000年以上の成功した使用の歴史があります。 アリストテレスの世界では、特定のプロパティセットを持ち、1つのカテゴリにのみ割り当てられた、明確に定義された単一のもののみが存在します。



はい、今では「 運ぶ 」だけでなく、「 carryを運ぶ 」または「 石を 運ぶ 」と言うことをすでに学びました。 開発では、プログラミング言語はオブジェクト（ fireと石 ）を区別することを学んだが、オブジェクトに対するアクションを区別することを学ばなかったという事実に焦点を合わせました。 プログラミング言語に関しては、 menと石のオブジェクトに共通の祖先がない限り、 men.carry（different ）とmen.carry（石）は異なる言語単位になります！ これらのオブジェクトによる「 人が着ることができるもの 」インターフェースの実装は、2つの実装であり、したがってソースコードの2つのユニットがあるため、役に立たないだけです。







OOPの主な制限の1つがここに隠されているため、プログラムが複雑になる可能性があり、OOPの先天的な足の不自由さを補うために、デザインパターンの形で松葉杖を使用せざるを得ません。 ソフトウェアシステムの特定の設計が私たちに合っているかどうかを判断しようとすると、このソリューションを単独で検討することはできません。 結果としてこの設計がどのように使用されるかについての合理的な仮定の観点からそれを考慮すべきです。 この論文を「 fire 」と「 石 」の言語に翻訳すると、このような音になります。 ソフトウェアオブジェクト「 fire 」と「 石 」を設計するとき、ソフトウェアシステムを改善するための主の計画を認識する必要があります。 すなわち、彼はfireと石を作ることに自分自身を制限するのではなく、世界の創造の6日目に彼はそれらを引きずる人を作ると仮定しなければなりません。

継承について

OOPのもう1つの制限は、複数の継承の可能性がある場合でも、各オブジェクトがクラスの1つの階層（「 は 」）に属し、特定のプロパティセットを1つだけ持つことです。 たとえば、赤いバラは花であり、花は植物です。 これは、オブジェクトが進化し、新しいプロパティを取得し、既存のプロパティを失う可能性があるという現実と矛盾しています。 たとえば、バラは商品になり、ギフトになります。 バラはどのクラスの相続人である必要がありますか？ バラ製品またはバラの花？ 別の例。 生まれる人は、年齢、体重、身長、きしむ音、おむつを食べて台無しにするという非常に限られた特性を持ちます。 時間が経つと、学校の学生、買い手、乗客、兵士、学生、従業員、起業家、配偶者、親などの新しいプロパティが取得されます。 そして多分そうではありません。 たとえば、すべての人が軍隊に勤めたり、大学で勉強したり、結婚したり、父親や起業家になったりするわけではありません。 または負け。 たとえば、研究を卒業した、軍隊に勤めた、または離婚した。 したがって、同じオブジェクトは異なるクラスに属することができなければならず、このクラスのセットは動的でなければなりません。 オブジェクトとソフトウェアシステム自体の進化の間に変化します。 原則として、オブジェクトが属するクラスのセットには制限が課せられます。 たとえば。 兵士になるには、18歳でなければなりません。 そして、人が学生である場合、夫になるためには降伏する必要があります。

投稿について

もう1つのOOPの奇妙な点は次のとおりです。 動作は、オブジェクトの状態とメッセージの送信に関して表現されます。 しかし、2台の車の衝突をモデル化した場合、どちらがメッセージを送受信し、どちらがメッセージを送信しますか？

プロパティについて

「オブジェクトの状態は、特定のオブジェクトのすべてのプロパティのリスト（通常は静的）と、これらの各プロパティの現在の（通常は動的な）値によって特徴付けられます。」 しかし、オブジェクトのプロパティはオブジェクト自体に属しますか？ 私はノーと言います。 たとえば、このリンゴは緑だと言います。 しかし、これは本当に何を意味するのでしょうか？ つまり、スペクトルに近い光源を太陽光に向けると、このリンゴは緑の範囲に対応する波長以外のすべての波長を吸収し、太陽光のスペクトル全体を知覚できる観測者は反射された緑の光のみを見ることになります。 ソースまたはオブザーバーが異なる範囲（赤外線など）を持っている場合、リンゴの色は黒になります。 したがって、プロパティはオブジェクトの不可欠な特性ではありませんが、オブジェクトが他のオブジェクトと相互作用するときのオブジェクトの可能な表現です。 たとえば、「表面に浮かぶ」物体の特性は、水との相互作用で現れ、アルコールとの相互作用では現れない場合があります。

集約について

モップとは「ブラシ」と「スティック」で構成される「集合体」です。 しかし、これはどういう意味ですか？ モップを空間内を移動できるオブジェクトと見なすと、凝集はまったく現れず、モップはアトミックオブジェクトと見なされ、その総質量とサイズにのみ関心があります。 しかし、モップをロードして強度をテストし始めると、凝集はその構造コンポーネントとブラシおよびスティックとの相互作用として現れ、テスト結果はこの相互作用が打ち込み釘または溝、スパイク、接着剤を介して発生するかどうかに依存します したがって、集約はオブジェクトの相互作用でもあります。

協会について

オブジェクト（a）がオブジェクト（b）の夫であると言う場合、オブジェクト（aとb）は関連付けによって接続されていると宣言します。 この接続はどのように現れますか？ まず、この接続自体は、3つのオブジェクト（a）、（b）、およびオブジェクト（c）の相互作用の結果です（レジストリオフィス、この接続が生まれたレジストラで、ところで、そこから消える可能性があります）。 第二に、それはオブジェクトの相互作用に現れます。例えば、（aとb）：家計の共同支出または一般的な子供の誕生と育成。 a.isMarried （b）に尋ねても意味がありません、彼は嘘をつくことができます。 しかし、関数isMarried （a、b、c）は非常に意味があります。 したがって、プロパティなどの関係は、オブジェクト間の相互作用の可能性があります。

アイデンティティについて

「アイデンティティは、オブジェクトを他のすべてのオブジェクトと区別するオブジェクトのプロパティです。」 このステートメントに実際に対応すべきものは何ですか？ 車を塗り直したとしましょう。 私にとって、彼は確かに同じままでした。 しかし、交通警察にとっては、それは完全に異なるオブジェクトとなり、新しい状態登録番号を受け取ります。 別の例。 車から車輪が取り外されました。 車は同じままでしたか？ そして、もしエンジンも？ そして、車はいつ同じになるのをやめますか？ アイデンティティは、特定のオブジェクトをバインドするときにのみ発生します。 各モップは非常に特定のブラシとスティックで構成されます。 各夫には非常に具体的な妻がいて、各クライアントには銀行口座のコピーがあります。







したがって、私たちの精神世界には、オブジェクトとそのプロパティはありません。 しかし、構造とその相互作用があります。 交通をシミュレートする場合、車は構造の基本ノードと見なされる必要があり、相互作用（追い越し、切断、ブレーキ）の際に、位相空間（速度、位置）の座標を一貫して変更します。 一方、衝突での相互作用を考慮し始めるとすぐに、自動車は構造の基本ノードではなくなります。 構造レベルを下げる必要があります。 このレベルでは、基本ノードはバンパー、ボディ、フレーム、エンジンなどでなければなりません。 コンポーネント、およびそれらの接続方法（ボルト、溶接など）。 構造ノードの割り当てのまさに事実は、認知活動の行為（ゲシュタルト理論）であり、解決される問題に依存します。

ルートヴィヒ・ヴィトゲンシュタインのオントロジーについて

ヴィットゲンシュタインの世界は、アリストテレスのようなものの世界ではありません。 アリストテレスにとって言語の本質が名詞である場合、ウィトゲンシュタインによれば、言語の本質は文です。 Wittgensteinによれば、言語は名前やプロパティのセットではなく、オブジェクトの相互作用が表現された文で構成されています。 ウィトゲンシュタインの世界では、事実は主要なものであり、オブジェクト間の相互作用であり、物事は可能な相互作用の全体によって決定されます。 このような世界観は、モーフィズム（オブジェクトの相互作用を決定し、ファンクターを決定する）が時間内にモデルの進化を決定する現代のカテゴリー理論と非常によく一致しています。



アリストテレスの静的な世界とは異なり、ヴィットゲンシュタインの世界は動的です。 世界の進化の過程で、事実を追加することができ、物事の考え方が変わります。 この世界の解釈のおかげで、ものは与えられたもの、凍結されたもの、完全に定義されたものとしてではなく、ファジーで可変的な境界を持つ何らかの実体として現れます。 ソフトウェアシステムは、ヴィトゲンシュタインの世界のように動的に進化します。 ソフトウェアシステムの開発中に、開発者は、プロパティと関係のセットを拡張する新しい可能な相互作用をオブジェクトに追加します。







ヴィットゲンシュタインは、「言語ゲーム」の概念を導入しました-単一の全体：言語とそれが絡み合うアクション。 「オファーの種類はいくつありますか？」 言って、声明、質問、命令？ そのようなタイプは無数にあり、「サイン」、「単語」、「センテンス」と呼ぶすべての用途は無限に多様です。 そして、この複数形は安定したものではありません。 ユーザーストーリーを使用してドメインモデルを記述するときに、同様の言語のゲームをプレイしませんか？

ドメイン固有言語（DSL）について

将来的には、プログラミング環境は、DSLが統合されたCADシステムとほぼ同様になると思われます。 アプリケーションシステムは、適用分野の専門家によって作成する必要があります。たとえば、エンジニアは既製のコンポーネントベースから新しい航空機の飛行品質を研究するためのソフトウェアモデルを組み立てます：胴体、翼、エンジン、接続フィクスチャ、流入する流れとの相互作用のモデル。 同様に、既製のコンポーネントとビジネスアプリケーション（経理、物流、倉庫、生産など）から組み立てられます。



これは、サブジェクト領域ごとに独自のDSLを作成する必要があるということですか？ はい、いいえ。 はい、数学、医学、生物学など、人々の職業活動のほぼすべての確立された領域には特定の言語があるという意味で、各主題領域で特定の問題を解決するための特定のモデルを記述する独自のDSLを作成する必要があります。 いいえ、プロの言語は自然言語の単一の構文に基づいて構築されており、人間の思考の一般的な法則に基づいてメンタルモデルを記述するための普遍的な構文が必要であるためです。



ユニバーサルDSL構文を作成しようとする試みは複数回行われています。 それらの中で最も目立つもののみをリストします： oneとtwo 。 提案されたアプローチの深刻な実際的な応用例は知りません。 おそらくこれは、彼らがアリストテレスのオブジェクトの静的な世界をシミュレートしようとしているからでしょうか？ ユニバーサルDSL構文の基礎は、ヴィットゲンシュタインの相互作用の動的な世界と、思考の基本的な特徴を反映したカテゴリカルアプローチである可能性があります。



DNAのようなDSLは以下を記述する必要があります。

1. 既製のコンポーネントからモデルを組み立てるシナリオ。
2. 初期状態の初期化;
3. 時間内のモデル進化の法則。

言語の主な構成要素は、オブジェクトのプロパティが明示され、状態が変化し、新しいインスタンスが生成される相互作用でなければなりません。 進化の過程での各オブジェクトは、潜在的な相互作用の新しいセットで補うことができ、この追加は以前に作成されたコードに影響を与えません。 このアプローチで「 石 」と「 fire 」の世界に「 人間 」が出現すると、新しい相互作用キャリー（ キャリア、物、空間、重力 ）の創造につながります;。 キャリア要素はインタラクションを実装する必要があります： take（carrier、thing） and move（carrier、thing、space） 。 そして、 Thing要素は相互作用を実装する必要があります： 重量（物、重力）と形（物、空間） 。 この場合、キャリーアクションモデルは非常に普遍的になります。 方法は、人が自分の手、動物の歯、特別なグリップのあるクレーンとの相互作用を実現するという事実から変化することはありません。 したがって、 キャリア、モノに必要な相互作用を実装する要素をソフトウェアシステムに簡単に補充でき、普遍的な機能を変更する必要はありません。 それはどのように見えるでしょうか？ おそらく、将来のDSLはMixinテクノロジーまたはAnemic Domain Model（ちなみに、Martin Fowlerはこのモデルをアンチパターンと呼びます）、またはD. Knuthの「 言語プログラミング 」に類似し、相互作用の物語の記述はアルゴリズムとデータ構造の形で解釈されます。

結論

プログラミングは、誤ってエンジニアリングと分類される新しい種類の人間の活動です。

エンジニアリングは、自然科学、数学、物理学、化学の法則が新製品の設計に適用される分野です。ニュートンの法則はソフトウェア開発でまだ発見されていません。新しい非自明なソフトウェアシステムの正しいアーキテクチャを設計および証明するのに役立つラグランジュ方程式、または少なくとも妥協はありません。



プログラミングは人道主義の分野であり、理論、心理学、言語学、記号論などの人文科学の成果を使用してのみ、その理論的基礎の重大な進歩を達成できます。おそらくこの出版物を読んだ後、誰かが代替思考について話し始めるでしょう。