（開発に関連した） 教義は、特定の技術（または技術的解決策）が絶対的な善であるという主張です。
この記事の主なアイデアは、そのような独断的な考え方は業界では非常に一般的ですが、有害であり、悲しい結果につながるということです。
まず第一に、 プログラミングは悪いです。 なんで？
複雑だから 。 どちらが良いですか？ 建設
設計エラーはすぐにわかります。 プログラミングエラーは表示されません。
プログラミングは、多くの知識とスキルを必要とする面倒なプロセスです。 デザインには低いスキルが必要です。
25年前に、リンクを表示する「写真とテキストを含む動的ページ」をプログラミングするタスクが与えられたと想像してください。リンクをクリックすると、別の「動的ページ」などが表示されます。
そのようなプログラムの実装に関連する困難を想像してください。 異なるプラットフォーム上。
今はどうですか？ そして今では、1日のどんなオタクもHTMLとCSSからそのようなページを構築します。 さらに、そのようなページのデザインのエラーは通常すぐに表示され、簡単に修正できます。
したがって、プログラミングは複雑です。 それは骨の折れる作業であり、高い資格と大規模なチームが必要であり、明白でない「落とし穴」が含まれ、建築などで開発する必要があります。
複雑さは、その性質からプログラミングに固有のものです。 彼女は避けられない。 これはプログラミングの暗い側面です。
しかし、「明るい面」があります。 プログラミングは、間違いなく良い結果をもたらします-その動作により、さまざまなタスク、オペレーティングシステム、ドライバーなどを解決できるプログラム
（全体としてのプロセスとしての）プログラミングの独断的な見方は、しばしばその複雑さを否定することになります。
しかし、この見解は常に明示的に表現されているわけではありません。 たとえば、一部の謝罪者、伝道者、および他の患者は、プログラミングは「まだ難しい」と主張します。 しかし、「この1つのことで、すべてが変わります。」
そのドグマをさらに見てみましょう...
「自動メモリ管理（java）は手動（C ++）よりも（簡単）であり、一般に、Java（C＃）はC ++よりも優れています」
手動でメモリを割り当てて解放するのは困難です。
ただし、この複雑さを管理できる、つまり制御を維持できる特定の手法があります。
たとえば。 リソース（明示的に解放する必要がある）は、常に何らかのオブジェクトに属します。 オブジェクトが作成されると割り当てられ、オブジェクトが破棄されるとシステムに返されます。 オブジェクトは常に別のオブジェクトに属します。 この階層の最上部には、すべてのオブジェクトの主な所有者であるアプリケーションがあります。
オブジェクトの所有権を共有する場合は、カウンターで所有者を入力します。 最後の所有者（カウンターをゼロに設定した）がオブジェクトを解放します。 オブジェクトの所有権は明示的に譲渡できます。
ここに書いているのはなぜですか？ 難易度を明確にするため。
私の練習から、これらの技術は手動メモリ管理の問題の99％を解決すると言うことができます。 これ以上の微調整やトリックは必要ありません。 マインドフルネスのみ。
そしてここに自動メモリ管理があります。 そして、この複雑さを「単純化」します。
難易度はなくなっていますか？ いいえ、もちろんです。 彼女は変身した。
ガベージコレクターが登場しました。 これは、予測不能な時間にリソースを必要とする別個のタスクです（アプリケーションを一時停止します）。 構成する必要があります 。つまり、コレクターは（追加の）複雑さをもたらします。
自動デストラクタは言語と最も単純なタスクを残しました-ファイルを開いたコード内の同じ場所でファイルを閉じる-複雑になりました。 ファイナライザはこの複雑さを解決しません。
最も興味深いのは、メモリ不足です。 javaでは、今では_different_になっています 。 C ++でメモリの不足がメモリの不足を意味する場合、Javaでメモリの不足は意味します...はい、それは明確ではありません！ 別の難しさ。
ふう まあ、まあ、私は新しい複雑さに圧倒されました。 しかし見返りに？ 代わりに、自動ガベージコレクションがある場合、最終的にメモリリークから解放されますか？
いや
ここで独断は何でしたか？ そして、なぜそれが起こったのですか？ 説明しようと思います。
複雑さには高い資格が必要です。
プログラミング-複雑なプロセスとして-高い資格が必要です。 高価です。
ITの爆発的な成長により、開発者の需要が爆発的に増加しました。
プログラミングを単純にすること、つまり、未熟な開発者の助けを借りることが可能であると判断した賢明 な人物がいました。
Javaはそのような試みの1つです。 Javaは、未熟なプログラマーのための開発ツールとして考えられていました（Javaの教祖は今は許してください:-)）。
Javaは特定の理由で生き続けました。 彼女には欠点を補う特定の利点があります。
しかし、自動メモリ管理は手動よりも優れていると明確に述べることは可能ですか？
この質問はあなたの裁量でお願いします。
JavaはC ++ よりも簡単であると明確に言うことは可能ですか？
以下に例を示します。 文字列内の印刷できない文字をスペースに置き換えます 。
C ++のこのタスクは、_タスクではありません_。 一般的に。 どうしてそんなに確かなの？ Google！
Googleは、トピック「C ++で印刷できない文字を最速で置き換える」を見つけることができません。 このトピックは存在しません。
Javaでは、これはタスクです。 ソリューションの検索が必要です。 Javaの根底を掘る必要があります。
ちょっと待って！ 結局のところ、Javaは同じ「よく知られている善」なのでしょうか？！ これは標準ライブラリ、抽象化後の抽象化、どこでもOOPで
バイトはクラスの後ろに隠れました。 これはいいです。 そしてこれは悪いです。
別の教義。
「XMLは設定の保存に最適です」
永続的な（アプリケーション自体の寿命を経験する）設定を保存することは困難です。 XMLはこの複雑さを解決しますか？
さらに読まないで、考えてください。
XMLは、その階層構造のために非常に便利です。 これにより、目的のブランチにすばやくアクセスできます（既にメモリにロードされている場合）。 簡単に拡張できます。 これは、人が手動で編集できるテキストファイルに保存されます。
そのため、100メガバイトのXMLファイルと設定があります。 設定の1つのフラグを「0」から「1」、つまり実際には1バイトに変更します。 この置換を反映するには、ディスクに何バイト書き込む必要がありますか？
100（100）メガバイト。
はい、XMLは読み取り専用設定を保存するのに悪くありません。 しかし、永続性に関連する複雑さはどこにも行きません。 彼女は小さなサイズのXMLファイルで身を隠しました。
最も小さなセットアップにアクセスするには、XMLファイル全体を読む必要があります。 小さな変更を保存するには、ファイル全体を書き込む必要があります。
なぜこれが起こったのですか？
最も重要な「良い」XMLを分離しましょう。
これは人間が読めるテキスト形式です。
悪くなくてもいいですか？ 起こらない！
「良い」は常に「悪い」と連動します-大量のデータがある場合、テキスト形式は貧弱です。 少しずつ更新することはできません。 最小限のデータを読み取るには、メモリに完全にロードする必要があります。
繰り返しますが、私たちは悪い（つまり複雑さ）がどこにもなくなっていないことを確信しています。
真の永続性が必要です-RDBMSが私たちを助けてくれます この複雑さを制御し、階層、人間が読み取れる形式、および設定への直接アクセス（クエリ言語-SQLのみ）を取り除きます。
などなど。
それでは、プログラミングを簡単にすることはできますか？ 学生が数日で独自のオペレーティングシステムを作成できるようにする「銀の弾丸」はありますか？
いいえ、プログラミングはこれまでも現在も困難です。
この複雑さのさまざまな側面を制御する多くのテクノロジーが登場しました。
しかし、プログラミングが簡単になったと言うことは不可能です。
複雑さをインテリジェントに制御する方法を見つけるのは良いことです。 問題なくパスを見つけることは時間の無駄です。
PSこの記事の例は意図的に簡略化されています。 これは、記事がマルチボリュームの作品にならないようにするためです。 もちろん、取り上げられているトピックはいずれも、より深く、より多国間です。