20

Edsger Dijsktra が見た、プログラミング スタイルに関するこの記事に出会いました。簡単に言い換えると、主な違いはモーツァルトです。プログラミングに例えると、何かを書く前に問題を完全に理解している (議論の余地がある) のに対し、ベートーベンは紙にメモを書きながら決定を下し、途中で多くの改訂を行いました。Mozart プログラミングでは、バージョン 1.0 は、エラーなしで最大限の効率で動作することを目指すソフトウェアの唯一のバージョンです。また、Dijkstra は、そのレベルの洗練度と安定性に達しないソフトウェアは公開すべきではないと述べています。

彼の見解に基づいて、2 つの質問があります。モーツァルトのプログラミングは可能ですか? 代わりにモーツァルト スタイルを採用した場合、今日私たちが作成するソフトウェアは本当に役立つのでしょうか?

私の考え。ソフトウェアの複雑化に対処するために、私たちはこの方法から、アジャイル開発、公開ベータ テスト、コンスタント リビジョンなど、速度が最も重要な Web 開発を定義する方法に移行したようです。しかし、Web ソフトウェアが通過できるすべてのリビジョンを考えると、特にメンテナンス中に、パッチがパッチの上に適用され、退屈なリファクタリング プロセスによって洗練されることがよくあります。Mozart の方法は非常に魅力的です。少なくとも、Digsby、Windows、iTunes などの煩わしいソフトウェア アップデートは軽減されます。これらの多くは、新しい即時リリースを必要とする予期せぬ脆弱性の結果です。

編集:ダイスクトラの見解のより正確な説明については、以下の回答を参照してください。

4

10 に答える 10

52

モーツァルトのプログラミング スタイルは完全な神話です (誰もが最初の作業を編集および変更する必要があります)。この例では、「モーツァルト」は本質的にメタファーですが、モーツァルト自体が実質的に神話であったことは注目に値します。

モーツァルトは、4 歳で最初のソナタを作曲した魔法の神童とされていました (彼は実際には 6 歳でしたが、それはひどいものでした。どこでも演奏されるのを聞いたことはありません)。もちろん、彼の父親がヨーロッパで最も優れた音楽教師と見なされていたこと、そして彼の子供たち全員に、楽器やペンを手に取るとすぐに、毎日何時間も演奏と作曲の練習をさせたことはほとんど言及されていません.

モーツァルト自身は、下書きのほとんどを破棄することで、自分の音楽が頭から完全に浮かび上がってくるという幻想を永続させることに注意を払っていましたが、彼が他の皆と同じように編集者であることを示すには十分な量が残っていました。ベートーベンはそのプロセスについてもっと正直でした(おそらく、彼は耳が聞こえず、とにかく誰かが彼に忍び寄っているのかどうかわからなかったからです)。

モーツァルトが鳴き鳥を聴いてメロディーを得たという理論については言及しません。または、サイコロを使ってランダムに音楽を生成するシステムを彼が作成したという事実(これは実際には非常にクールですが、モーツァルトの音楽の多くがどこからともなく現れたように見えることも説明している可能性があります)。

この話の教訓は、誇大広告を信じてはいけないということです。プログラミングは仕事であり、最初に犯した間違いを修正するための作業が続き、2 回目に犯した間違いを修正するための作業がさらに続き、というように死ぬまで続きます。

于 2008-11-15T16:02:48.693 に答える
15

スケーリングしません。

頭の中でコード行、ルーチン、さらには小さなプログラムを理解することができます。しかし、ミディアムプログラム?できる人もいるかもしれませんが、何人で、どれくらいの費用がかかりますか? そして、彼らは本当に次の給与プログラムを作成する必要がありますか? それはムザックでモーツァルトを浪費するようなものです。

ここで、モーツァルトのチームを想像してみてください。ほんの数秒。


それでもパワフルな楽器です。頭の中で行全体を把握できる場合は、それを実行してください。おもしろいケースをすべて含む小さなルーチンを見つけられる場合は、それを実行してください。

表面的には、完全に異なるインターフェイスを必要とする 1 つのエッジ ケースをまったく考えていなかったため、設計図に戻ることを回避できます。

より深い意味 (ヘッドフェイク?) は、別の人間の言語を学ぶことで説明できます。長い間、どの単語が自分の考えを表しているか、どのようにそれらを有効な文に並べるかを考えていましたが、その書き起こしには多くのフォアグラウンド サイクルが必要です。
話しているだけで解放感を感じる日が来るでしょう。「外国語で考えている」というか、「言葉が自然に出てきた」という感じかもしれません。特定の単語やイディオムを探してつまずくこともありますが、ほとんどの場合、翻訳は「潜在意識の CPU」の膨大なリソースで実行されます。


「高い目標」は、問題の転写と問題の解決を分離するために、実装言語から (ほとんど) 独立した解決策のメンタル モデルを開発することです。文字起こしは簡単で、反復的で簡単にトレーニングでき、抽象的なソリューションは再利用できます。

これがどのように教えられるかはわかりませんが、「書き始める前にできるだけ多くのことを理解する」ことは、その目標に向けた優れたプログラミングの実践のように思えます。

于 2008-11-15T16:54:11.320 に答える
14

Edsger Dijkstraは、「思考の規律」というタイトルのこのYouTubeビデオで、モーツァルト対ベートーベンのプログラミングに関する彼の見解について説明しています。

代替テキスト

このスレッドの人々は、ダイクストラの見解がどのように非現実的であるかについてほとんど議論しています。私は彼をいくらか守ろうとします。

  • ダイクストラは、本質的に顧客に対してソフトウェアを「テスト」している企業に反対しています。 バージョン1.0をリリースし、すぐにパッチ1.1を適用します。彼は、「ホットフィックス」パッチが境界線上で非倫理的である程度にプログラムを洗練する必要があると感じました。
  • 彼は 、ソフトウェアを一挙に作成する必要があるとか、変更を加える必要がないだろうとは考えていませんでした 彼はしばしば彼の設計の理想について話し合います。その1つは、モジュール性と変更のしやすさです。しかし、問題を完全に理解した後、彼はしばしば個々のアルゴリズムをこのように書くべきだと考えました。それは彼の規律の一部でした。
  • 彼は、プログラマーとの豊富な経験の結果、知識の限界を押し広げない限り、プログラマーは満足できないことに気づきました。彼は、プログラマーは自分たちが完全に何かをプログラムすることを望んでおらず、それに挑戦がなかったので100%理解していると言いました。 プログラマーは常に知識の瀬戸際にいたいと思っていました。 彼は、プログラマーがそのような理由を理解している間、それは低エラー耐性プログラミングを代表するものではないと述べました。

ダイクストラの「規律」も正当化されると私が信じているプログラミングのいくつかの産業またはアプリケーションがあります。NASAローバー、医療業界の組み込みデバイス(つまり、薬の調剤など)、私たちのお金を転送する特定の金融ソフトウェア。これらのエリアには、リリース後の段階的な変更の贅沢はなく、より「モーツァルトアプローチ」が必要です。

于 2008-11-15T19:37:38.713 に答える
14

真のプログラミング モーツァルトについての Usenet の古典的な話。

本物のプログラマーは Fortran で書きます。

ライト ビール、手計算機、「ユーザー フレンドリー」なソフトウェアのこの退廃的な時代では、おそらく彼らはそうしているかもしれませんが、「ソフトウェア」という言葉がおかしく聞こえ、リアル コンピューターがドラムと真空管で作られていた古き良き時代にさかのぼります。本物のプログラマーは機械語で書きました。Fortran ではありません。RATFORではありません。アセンブリ言語でさえありません。マシンコード。生の、飾り気のない、不可解な 16 進数。直接。

まったく新しい世代のプログラマーがこの輝かしい過去を知らずに成長しないように、ジェネレーション ギャップを乗り越えて、本物のプログラマーがどのようにコードを書いたかをできる限り説明する義務があると感じています。それが彼の名前だったので、私は彼をメルと呼びます。

私が初めてメルに会ったのは、タイプライター会社の現在は消滅した子会社であるロイヤル マクビー コンピューター コーポレーションで働いていたときでした。同社は、小型で安価な (当時の標準からすれば) ドラム メモリー コンピューターである LGP-30 を製造し、さらに改良された、より大きく、より優れた、より高速な RPC-4000 の製造を開始したばかりでした。メモリーコンピューター。とにかく、コアはコストがかかりすぎて、とどまることはありませんでした。(そのため、会社やコンピューターのことを聞いたことがありません。)

私はこの新しい驚異のための Fortran コンパイラーを書くために雇われ、Mel はその驚異へのガイドでした。Mel はコンパイラを承認しませんでした。

「プログラムが独自のコードを書き直すことができない場合、それは何の役に立つのですか?」と彼は尋ねました。

メルは、会社が所有する最も人気のあるコンピューター プログラムを 16 進数で作成していました。それは LGP-30 上で動作し、コンピュータ ショーで見込み客とブラックジャックをしました。その効果は常に劇的でした。LGP-30 のブースはどのショーも満員で、IBM のセールスマンが立ったまま立ち話をしていました。これが実際にコンピューターを販売したかどうかは、私たちが議論したことのない問題でした.

Mel の仕事は、RPC-4000 用のブラックジャック プログラムを書き直すことでした。(ポート? それはどういう意味ですか?) 新しいコンピューターには 1 プラス 1 のアドレッシング スキームがあり、各マシン命令には、オペレーション コードと必要なオペランドのアドレスに加えて、次の場所を示す 2 番目のアドレスがありました。回転ドラムには、次の指示がありました。現代の用語では、すべての命令の後に GO TO! が続きます。それをパスカルのパイプに入れて燻します。

Mel が RPC-4000 を気に入ったのは、自分のコードを最適化できるからです。つまり、ドラム上の命令を見つけて、1 つのジョブが完了すると、次の命令が「読み取りヘッド」に到着し、すぐに実行できるようにすることができました。その仕事をするプログラム、「最適化アセンブラ」がありましたが、メルはそれを使用することを拒否しました.

「どこに物を置くかは決してわかりません」と彼は説明しました。「そのため、別の定数を使用する必要があります」.

私がその発言を理解するまでには長い時間がかかりました。メルはすべての操作コードの数値を知っており、独自のドラムアドレスを割り当てていたので、彼が書いたすべての命令も数値定数と見なすことができました。彼は、以前の「加算」命令を取り上げて、正しい数値を持っていれば、それを乗算することができました。彼のコードは、他の誰かが変更するのは容易ではありませんでした。

Mel の手で最適化されたプログラムと、最適化アセンブラー プログラムによって処理された同じコードを比較したところ、Mel の方が常に高速に実行されました。それは、プログラム設計の「トップダウン」手法がまだ発明されておらず、メルがとにかくそれを使用しなかったためです. 彼はプログラムループの最も内側の部分を最初に書いたので、ドラムの最適なアドレス位置の最初の選択肢が得られました。最適化アセンブラは、そのようにするほど賢くありませんでした。

Mel は時間遅延ループも書きませんでした。 彼はドラム上の指示を見つけたので、必要なときに、連続する指示が読み取りヘッドをちょうど過ぎたところにありました。次の命令を見つけるために、ドラムはもう 1 回転しなければなりませんでした。彼は、この手順に対して忘れられない用語を作り出しました。「最適」は「ユニーク」と同様に絶対的な用語ですが、「最適ではない」、「あまり最適ではない」、または「あまり最適ではない」というように相対的なものにすることが口頭で一般的に行われるようになりました。Mel は、最大の時間遅延の場所を「最も悲観的な」場所と呼びました。

彼がブラックジャック プログラムを完成させて実行した後 (「イニシャライザも最適化されています」と彼は誇らしげに言いました)、営業部門から変更要求を受け取りました。このプログラムは、洗練された (最適化された) 乱数ジェネレーターを使用して「カード」をシャッフルし、「デッキ」からディールしました。彼らは、メルにプログラムを修正してもらい、コンソールのセンス スイッチの設定でオッズを変更し、顧客が勝つようにしたいと考えていました。

メルはうなずいた。彼は、これは明らかに不誠実であり、プログラマーとしての彼の個人的な誠実さに影響を与えると感じたので、それを拒否しました。ヘッド セールスマンはメルと話し、ビッグ ボスも話しました。上司の勧めで数人のフェロー プログラマーも話しました。メルはついに屈服してコードを書いたが、彼はテストを逆手に取り、センススイッチがオンになるとプログラムはチートし、毎回勝った。メルはこれに満足し、彼の潜在意識は手に負えないほど倫理的であると主張し、それを修正することを断固として拒否した.

メルがより環境に優しいパ$ture$のために会社を辞めた後、ビッグボスは私にコードを見て、テストを見つけてそれを元に戻すことができるかどうかを確認するように頼んだ. 少ししぶしぶ、私は見ることに同意しました。Mel のコードを追跡することは、まさに冒険でした。

私はしばしば、プログラミングは芸術形式であり、その真の価値は、同じ難解な芸術に精通した別の人によってのみ評価できると感じてきました。プロセスの性質上、時には永遠に、人間の目や賞賛から隠されている素敵な宝石と素晴らしいクーデターがあります。たとえ 16 進数であっても、彼のコードを読むだけで、その個人について多くを学ぶことができます。メルは縁の下の力持ちだったと思います。

おそらく、私の最大のショックは、テストのない無実のループを見つけたときでした。テストなし。なし。常識では、プログラムが永遠に無限に循環する閉ループでなければならないと言われました。ただし、プログラム制御はそれを通過し、安全に反対側に出ました。それを理解するのに2週間かかりました。

RPC-4000 コンピュータには、インデックス レジスタと呼ばれる最新の機能がありました。これにより、プログラマーは、インデックス付き命令を内部で使用するプログラム ループを作成できました。毎回、インデックス レジスタ内の数値がその命令のアドレスに追加されるため、一連の次のデータを参照します。毎回インデックス レジスタをインクリメントするだけで済みました。メルは一度も使っていません。

代わりに、彼は命令をマシン レジスタに取り込み、そのアドレスに 1 を追加して、元に戻します。次に、変更された命令をレジスタから直接実行します。ループは、この追加の実行時間を考慮して作成されました。この命令が終了すると、次の命令がドラムの読み取りヘッドの真下にあり、準備が整いました。しかし、ループにはテストがありませんでした。

重要な手がかりは、インデックス レジスタ ビット (命令ワード内のアドレスとオペレーション コードの間にあるビット) がオンになっていることに気付いたときに得られました。ライトが点灯すると、ほとんど目がくらみました。

彼は、作業中のデータをメモリの最上部近く (命令がアドレス指定できる最大の場所) に配置していたので、最後のデータが処理された後、命令アドレスをインクリメントするとオーバーフローが発生しました。キャリーはオペレーション コードに 1 を追加し、命令セット内の次のコードであるジャンプ命令に変更します。案の定、次のプログラム命令はアドレス位置 0 にあり、プログラムは順調に進みました。

私は Mel と連絡を取り合っていないので、彼が過去の時代からプログラミング技術を洗い流してきた変化の洪水に屈したかどうかはわかりません. 私は彼がしなかったと思うのが好きです。いずれにせよ、私は十分に感銘を受け、問題のあるテストを探すのをやめ、Big Boss に見つからないことを伝えました. 彼は驚いていないようだった。

私が会社を辞めたとき、正しいセンススイッチをオンにすると、ブラックジャックプログラムはまだチートをしていました。本物のプログラマーのコードをハックするのは気が進まなかった.

于 2008-11-15T15:46:21.050 に答える
6

モーツァルトの話は、出荷されるものと開発される方法を混同していると思います。ベートーベンは、彼の交響曲を公開するためのベータ テストを行いませんでした。(最初の公演の後、彼がスコアをどれだけ変更したかを見るのは興味深いでしょう。)

また、ダイクストラがすべてを頭の中で行うように主張していたとは思いません。結局のところ、彼は紙の上での作業を伴う規律のあるプログラミングに関する本を書き、数学的品質の規律を見たいと思ったのと同じ程度に、数学者が問題に取り組んでいる間にどれだけの紙とチョークボードを消費するか気づいていますか?

私はSimucal の回答を支持しますが、モーツァルトとベートーベンの比喩は捨てるべきだと思います。規律と理解に対するダイクストラの主張は、それが本当に属していない隅に追いやられています。

補足事項:

テレビの普及はそれほど熱くなく、作曲家が何をしているのか、プログラマーが何をしているのかについて、いくつかのことを混乱させています。ダイクストラ自身の言葉を借りれば、1972 年のチューリング賞講演で次のように述べられています。作曲家は、望ましい動作を発見するために出かけるかもしれません。

また、バージョン 1.0 が最終バージョンであるべきだという Dijkstra の考えでは、望ましい動作と機能が時間の経過とともにどのように進化するかについて、あまりにも簡単に混乱してしまいます。彼は、将来のすべてのバージョンは、最初のバージョンが厳密かつ確実に考え抜かれ、実行されなかったために作成されたものであると単純化しすぎていると思います。

市場投入までの時間の緊急性がなくても、重要な種類のソフトウェアは、ユーザーのエクスペリエンスとその実用的な目的に合わせて進化することを、私たちは今ではよく理解していると思います。明らかな反例はゲームです (劇場映画がどのように開発されているかも考えてみてください)。ベートーベンは、これまでの経験や探求のすべてがなければ、交響曲第 9 番を書くことができたと思いますか? 聴衆はそれが何であるかについてそれを聞くことができたと思いますか? 彼は完璧なソナタを完成させるまで待つべきでしたか? ダイクストラがこれを提案していないことは確かですが、彼はモーツァルトとベートーベンの主張をやりすぎていると思います。

さらに、チェスをプレイするソフトウェアを検討してください。新しいバージョンは、以前のバージョンが正しく再生されなかったからではありません。それは、チェスをプレイするヒューリスティックと利用可能なコンピューターの能力の進歩を活用することです。このような状況や他の多くの状況では、バージョン 1.0 が最終バージョンであるという考えは根拠がありません。彼が、信頼性が低く、メンテナンスや将来のリリースで補われる欠陥のあるソフトウェアのリリースに正当に反対していることを理解しています. しかし、モーツァルトの反論は私を支持しません。

では、ダイクストラは最初に購入した自動車を運転し続けたのでしょうか、それともまさにその自動車のクローン車でしたか? 計画的な陳腐化があるかもしれませんが、その多くは、以前の世代の自動車技術では利用できなかったり、考慮されなかったりした可能性のある改善と信頼性に関係しています。

私はダイクストラの大ファンですが、モーツァルトとベートーベンの話は単純すぎて不適切だと思います。私もベートーベンの大ファンです。

于 2008-11-15T20:27:38.597 に答える
5

モーツァルトのプログラミングを採用しているように見える可能性があると思います。私は Blizzard という会社を知っています。この会社は、ソフトウェア製品が完成して準備が整うまでリリースしません。これは、Diablo 3 が、まばゆいほど素晴らしいコーディングの 1 つのセッションで誰かの頭から完全に湧き出て完成するという意味ではありません。それ、それが私たちの残りの部分にどのように見えるかを意味します. Blizzard は内部でゲームの全体をテストし、すべてのねじれが解決されるまでは世界に公開しません。ほとんどの企業はこのアプローチを採用せず、代わりに、問題を解決するのに十分なソフトウェアをリリースし、バグを修正して機能を追加することを好みます。このアプローチは、ほとんどの企業で (程度の差はありますが) 機能します。

于 2008-11-15T16:49:37.913 に答える
4

まあ、私たち全員がモーツァルトほど上手になることはできませんよね?おそらく、ベートーベンのプログラミングの方が簡単です。

于 2008-11-15T15:43:36.347 に答える
1

Apple が「モーツァルト」プログラミングを採用していたら、今日の Mac OS X や iTunes は存在しないでしょう。

Google が "Mozart" プログラミングを採用した場合、Gmail や Google Reader は存在しません。

SO 開発者が「モーツァルト」プログラミングを採用していたら、今日の SO は存在しないでしょう。

Microsoft が "Mozart" プログラミングを採用していたら、今日の Windows は存在しなかったでしょう (まあ、それでいいと思います)。

したがって、答えは単純に NO です。完璧なものはありません。また、完璧であることを意図したものもありません。これにはソフトウェアも含まれます。

于 2008-11-15T15:58:37.220 に答える
1

先を見越して計画を立てることだと思います。少なくとも、何をしようとしているのか、どのようにそこにたどり着く予定なのかについて、何らかの概要を持っている必要があります。キーボードの前に座って、「ミューズ」がプログラムの必要な場所に導くことを期待している場合、結果はかなり不均一になりがちで、そこに到達するまでにはるかに長い時間がかかります。

これは、どのような種類の書き込みでも当てはまります。ベストセラーの小説が生まれるまで、何も考えずにただタイプライターの前に座って、ぶらぶらし始める作家はほとんどいません。実は私の義父(高校の英語教師)は手紙のあらすじを書いています。

于 2008-11-24T14:35:36.247 に答える
0

コンピューティングの進歩は、あちこちで栄光や天才を犠牲にする価値があります。

于 2008-11-15T16:06:30.153 に答える