22
なぜ一部のプログラマーは、理論と実践の間に対照があると思いますか？[閉まっている]
ソフトウェアエンジニアリングと土木工学を比較すると、私は異なる考え方を観察して驚いた：土木技師なら誰でも、庭に小さな小屋を建てたいなら、材料を手に入れて建てることができるのに対して、 10階建ての家（または、たとえばこのようなもの）では、崩壊しないことを確認するためにかなりの計算を行う必要があります。 対照的に、一部のプログラマーと話したり、ブログやフォーラムを読んだりして、次のように定式化できる幅広い意見をしばしば見つけます。理論と形式的方法は数学者/科学者向けであり、プログラミングは物事を成し遂げることです。 ここで通常暗示されているのは、プログラミングは非常に実用的なものであり、形式的な方法、数学、アルゴリズム理論、クリーン/コヒーレントなプログラミング言語などは興味深いトピックかもしれませんが、すべてが必要な場合は必要ないことです完了しました。 私の経験によれば、100行のスクリプト（小屋）をまとめるのにそれほど理論は必要ありませんが、複雑なアプリケーション（10階建ての建物）を開発するには、構造化された設計が必要です。定義されたメソッド、優れたプログラミング言語、アルゴリズムを検索できる優れた教科書など。 したがって、IMO（適切な量の）理論は、物事を成し遂げるためのツールの1つです。 私の質問は、なぜ一部のプログラマーが理論（形式的手法）と実践（物事を成し遂げる）の間に対照があると考えるのですか？ ソフトウェアエンジニアリング（ソフトウェアの構築）は、例えば土木工学（住宅の構築）と比較して多くの人が容易に認識してい ますか？ または、これらの2つの分野は本当に異なりますか（ミッションクリティカルなソフトウェアは別として、ソフトウェアの障害は建物の障害よりもはるかに許容されます）。 これまでの回答から理解したことを要約しようと思います。 ソフトウェアエンジニアリングとは対照的に、土木工学では、特定のタスクに必要な理論量（モデリング、設計）がはるかに明確です。 これは、土木工学が人類と同じくらい古く、ソフトウェア工学が数十年しか存在していないという事実に一部起因しています。 別の理由は、ソフトウェアがより不安定な種類のアーティファクトであり、より柔軟な要件（クラッシュする可能性がある）、さまざまなマーケティング戦略（すぐに市場に出すために良いデザインを犠牲にすることができる）などであるという事実です。 結果として、適切な設計/理論の量がソフトウェアエンジニアリングに適切であるかを判断するのははるかに困難です（少なすぎる->乱雑なコード、多すぎる->私は決して終わらない） （多くの）経験が役立ちます。 したがって、あなたの答えを正しく解釈すると、 理論が実際にどれだけ必要かについてのこの不確実性が、一部のプログラマーが理論に対して抱く愛と憎しみの混合の原因になります。