青 いや！ 黄色！ -または-新しいプログラミング言語を使用すると、開発速度が向上しますか

プログラムが保存された最初のコンピューター用の最初のプログラムを作成するために、どの言語が使用されましたか？

もちろん、バイナリ機械語。

なんで？

明らかに、文字アセンブラーがなかったからです。 最初のプログラムは、バイナリコードで作成する必要がありました。

バイナリマシン言語よりもアセンブラでプログラムを書く方が簡単ですか？

ずっと簡単です。

番号を教えてもらえますか？ 何倍簡単ですか？

まあ、それはいまいましい、アセンブラーはあなたのためにすべての最も困難な「ルーチン」作業を行います。 つまり すべての物理アドレスを計算します。 彼はすべての物理的な機械命令を作成します。 これにより、たとえばアドレス空間の外部でアドレス指定するなど、物理的に実現不可能なコマンドを発行することが不可能になります。 そして、簡単にダウンロード可能なバイナリ出力を作成します。



ワークロードの保存は膨大です。

いくら 番号を教えてもらえますか？

OK PDP-8のような古いマシンのアセンブラーで、最初の25個の整数の2乗を印刷するなどの簡単なプログラムを作成する場合、約2時間かかります。 同じプログラムをバイナリマシン言語で記述すると、2倍の時間がかかります。



doubleと言うのは、最初に紙にシンボリックシンタックスでプログラムを記述し、次に紙に機械語を手動でアセンブルするからです。 その後、このバイナリコードをコンピューターに手動で入力する必要があります。 そして、このすべての追加作業には、最初のケースでプログラムを作成するのと同じくらいの時間がかかりました。 おそらくもっと。

十分です したがって、文字アセンブラを使用すると、作業量が半分に減りますか？

実際、もっと多くのことを考えています。 整数の二乗はかなり簡単なプログラムです。 プログラムが大きいほど、手動でアセンブルしてロードすることが難しくなります。 実際、労力の増加はプログラムの規模に依存すると考えています。 大規模なプログラムの場合、時間を大幅に節約できます。

説明してください。

さて、文字アセンブラーでプログラムの1行を変更する必要があるとします。 テープをパンチした古いPDP-8では20分かかります。 しかし、手動アセンブリでは、すべてのアドレスを再カウントし、すべての機械命令を手動で再アセンブリする必要があります。 元のプログラムのサイズに応じて、時間はなくなります。 その後の手動入力には、これ以上の時間は必要ありません。



プログラムを、固定されたアドレスにロードされたモジュールに分割することで時間を節約できました。モジュールは、それらの間に自由な間隔があります。 大きなプログラムをダウンロードするのに役立つ小さなプログラムを作成することで、さらに時間を節約できます。 しかし、そのような「通常の」負荷は、それにもかかわらず、非常に非常に高くなります。

いいね しかし、それにもかかわらず、数字はあるのでしょうか？ 平均して、バイナリでプログラムを書くのに比べて、アセンブリの使用はどれほど簡単ですか？

わかった 私たちは約10回言うことができると思います。

つまり、文字アセンブラを使用すると、1人のプログラマがバイナリコードで作業する10人のプログラマの作業を実行できますか？

はい、これはおそらく真実に近いでしょう。

シンボルアセンブラが労働投入量を約10倍削減した場合、Fortranはどの程度削減しましたか？

とてもまともです。 50年代について話しているなら、Fortranは単純でした。 言い換えれば、文字レイアウトに関しては文字アセンブラよりもやや大きかったのです-私が言っていることを理解しているかどうかはわかりません。

これは、彼が複雑さをさらに10分の1に減らしたことを意味しますか？

もちろんあなたはそうではありません！ シンボリックアセンブラの「通常の」負荷はそれほど高くありませんでした。 Fortranは複雑さを比較的少なく抑えたと言えます。 おそらく約30％。

つまり、10人のFortranプログラマーが13人のアセンブラープログラマーを置き換えることができますか？

この観点からプロセスを検討したい場合は、そうです。

私たちは続けます-Cのような言語は、Fortranと比較してどのように時間を節約しますか？

さて、CはFortranに比べて「ルーチン」作業に費やす時間が少し少なくなります。 古いFortranでは、行番号や一般的な演算子の順序などを覚えておく必要がありました。 また、本文中には驚くほど多くのジャンプ演算子がありました。 C言語は、Fortran 1よりもプログラミングにはるかに快適です。複雑さを約20％削減したと言えます。

いいね つまり、10人のCプログラマが12人のFortranプログラマを置き換えることができますか？

もちろん、これは仮定にすぎませんが、合理的な仮定と言えます。

いいね さて、C ++は、Cに関連する複雑さをどれだけ減らしましたか？

聞いて、やめましょう。 現在、これ以上の影響は覚えていません。

ほんと？ なに？

開発環境。 つまり、50年代にはパンチカードと紙テープを使用していました。 単純なプログラムのコンパイルには少なくとも30分かかりました。 そして、あなたが車にアクセスできれば。 しかし、C ++が普及した80年代後半、プログラマーはプログラムをディスクに保存し、簡単なプログラムのコンパイルは2〜3分しかかかりませんでした。

労働集約度の低下ですか？ それとも、単に待ち時間を短縮しますか？

A.それでここにあります。 問題は明らかです。 はい、車は長い間待たなければなりませんでした。

リクエスト：労働投入量の推定値を提供する場合、待ち時間を除外してください。 言語自体にのみ関連する時間を節約することに興味があります。

分かりました それで、C ++について尋ねました。 実際、正直なところ、C ++が複雑さをなんとか大幅に減らしたとは思いません。 もちろん、 何かがありましたが、5％以下であると思います。 これは、Cでのルーチン負荷が単純に小さいため、C ++で作業する場合の比較時間の節約はそれほど大きくないことを意味します。

5％を使用するということは、100人のC ++プログラマーが105人のCプログラマーを置き換えることができるということです。

一般に、はい。 ただし、中小規模のプログラムのみ。 大規模なプログラムの場合、C ++にはいくつかの追加の利点があります。

どれ？

これを説明するのはかなり難しいです。 しかし、要点は、C ++のオブジェクト指向の特性、特に多態性により、大規模なプログラムを独立して開発およびデプロイされたモジュールに分割できるようになったことです。 そして、これ-非常に大きなプログラムの場合-ルーチンの負荷を大幅に削減します。

番号を教えてもらえますか？

80年代と90年代に作成された非常に大きなプログラムの数を考えると、一般的に、C ++は労力をおそらく7％削減したと言えます。

これは特に自信があるとは思えませんでした。

はい しかし、この値を使用しましょう。 7％。

いいね 100人のC ++プログラマが107人のCプログラマを置き換えることができますか？

私がそう言ったように見えます。 この値を使用しましょう。

JavaはC ++と比較してどのくらいの時間を節約しますか？

言うのは難しいです。 時間を節約します。 Javaはよりシンプルな言語です。 自動動的メモリ割り当て解除制御（ガベージコレクション）があります。 ヘッダーファイルはありません。 仮想マシンで動作します。 彼には多くの美徳があります。 そして、いくつかの欠陥。

数字はどうですか？

私は横滑りしているような気がします...しかし、あなたはそのように私に迫っているので、あなたは、セタリス・パリブス（決して起こらない）は、Javaで作業している間、C ++と比較して人件費を5％削減できると言うでしょう。

100人のJavaプログラマが105人のC ++プログラマを置き換えることができますか？

はい！ しかし、いいえ。 そうではありません。 スプレッドが大きすぎます。 100人のJavaプログラマをランダムに選択し、それらを105人のC ++プログラマも選択した場合と比較した場合、結果を予測することはあえてしません。 本当の勝利を得るには、もっと多くのプログラマが必要です。

それ以上？

少なくとも2桁。

言い換えれば、10,000人のランダムに選択されたJavaプログラマが、10,500人の同様に選択されたC ++プログラマを置き換えることができますか？

おそらくそうです。

とても良い。 Rubyのような言語は、Javaと比較して複雑さをどの程度軽減しますか？

まあ、親愛なる！ （ため息）。 何言ってるの？ 見て、Rubyは本当に美しい言語です。 シンプルで複雑、エレガントで奇妙です。 それはJavaよりもはるかに遅いですが、コンピューターは今ではとても安いので...

申し訳ありませんが、私はこれについて尋ねていません。

あなたは正しい。 知ってるよ。 そのため、Rubyの複雑さがJavaなどの言語に比べて少ない主な方向はTypesです。 Javaでは、正式な型構造を作成し、その一貫性を維持する必要があります。 Rubyは、タイプを使ってかなり迅速かつ自由に再生できます。

労働生産性の向上のように聞こえます。

一般的に、いいえ。 型構造を使用して迅速かつ自由に再生できることにより、Javaでのプログラミングでは利用できない実行時エラーのクラスが出現することがわかりました。 そのため、Rubyプログラマーは、プログラムのテストとデバッグの負荷が高くなります。

言い換えれば、これらの効果はバランスが取れていますか？

それはあなたが尋ねる人次第です。

お願いします。

わかった 私は効果がお互いにバランスをとっていないと言うでしょう。 Rubyを使用する場合の複雑さは、Javaを使用する場合よりも低くなります。

いくら 20％？

人々はそう思っていました。 実際、90年代には、SmalltalkプログラマはC ++よりも何倍も生産的に働くと多くの人が考えていました。

あなたは私を混乱させています。 これらの言語を覚えているのはなぜですか？

はい、C ++はJavaに、SmalltalkはRubyにかなり近いためです。

なるほど。 したがって、RubyはJavaと比較して複雑さを数倍減らしますか？

いいえ、おそらくそうではありません。 90年代を振り返ると、待ち時間の問題はまだかなり顕著でした。 典型的なC ++プログラムのコンパイル時間は数分でした。 Smalltalkプログラムのコンパイル時間は実質的にゼロでした。

ゼロ？

事実上はい。 問題は、JavaやC ++などの言語を使用する場合、すべてのタイプを調整するために多くのアクションを実行する必要があることです。 SmaltalkとRubyを使用する場合、このような問題はありません。 したがって、90年代には、数分から数ミリ秒の時間が必要でした。

なるほど。 しかし、これはすべて待機時間であるため、それを考慮することはできません。

あまり好きではありません。 コンパイル時間がほぼゼロの場合 、他のプログラミングスタイルと規律が発生します。 数分ではなく数秒という非常に短いサイクルで作業できます。 これは非常に高速なフィードバックを提供します。 コンパイル時間が長いと、迅速なフィードバックが不可能になります。

高速フィードバックは人件費を削減しますか？

はい、ある程度まで。 サイクルが非常に短い場合、各サイクルの「ルーチン」負荷は非常に小さくなります。 追跡の必要性に起因する忙しさが減少しています。 サイクルを長くすると、「通常の」負荷が増加し、非線形になります。

非線形？

はい、「通常の」負荷はサイクル時間に比例して増加しています。 たとえば、O（N ^ 2）として成長できます。 知りません しかし、依存関係は非線形であると確信しています。

いいね！ したがって、Rubyがリーダーです！

いや それがポイントです。 過去20年間にわたるハードウェアの改善により、Javaのコンパイル時間はほぼゼロになりました 。 Javaプログラマーのサイクルタイムは、Rubyプログラマーのサイクルタイム以上ではありません（または、これ以上であるべきではありません）。

明確にしてください。

JavaとRubyを使用している場合、短周期の規律を使用するプログラマーは、労働投入量にわずかな違いしか見ない（または、一般に見られない）と言います。 その差は非常に小さいため、測定が困難になります。

計り知れない違い？

この違いについて統計的に信頼できる結果を得るためには、何千人ものプログラマーで実験を行う必要があると思います。

しかし、RubyはJavaに比べて複雑さを軽減すると以前に言いました。

サイクルタイムが長い場合にのみそうだと思います。 編集/コンパイル/テストのサイクルが非常に短く保たれている場合、その影響は無視できます。

ゼロ？

もちろんそうではありませんが、おそらく約5％です。 しかし、散布は巨大になります。

それで、10,500の短いサイクルのJavaプログラマーは、10,000のRubyの短いサイクルプログラマーと同じ仕事をしますか？

サンプルサイズの注文をもう1つ追加すると、同意することになります。

Rubyよりも優れた言語はありますか？

Clojureのような言語を使用すると、5％を取得できます。これは、一方では非常にシンプルで、一方では機能的だからです。

関数型言語に5％しか与えませんか？

いいえ、短いサイクルの規律は、現代の言語のパフォーマンスの違いを事実上消去すると言います。



短いループで作業する場合、使用する現代言語はほとんど問題になりません。

つまり、Swift？ ダーツ？ 行く？

関係ありません。

スカラ？ F＃？

関係ありません。

言い換えれば、私たちは頂点に達したのです。 将来の言語は、現在の言語よりも優れたものはありません。

あまり好きではありません。 私は効率の低下の道にいるとだけ言っています。 バイナリコードに関連するアセンブラの場合と同様、将来の言語では10倍のゲインは得られません。 将来の言語は、既存の言語に比べて労働力を50％または20％または10％削減することはありません。 短期間の規律により、実際の測定不能との差異が減少しました。

次に、新しい言語がすべて表示されるのはなぜですか？

これは聖杯の検索です。

そして、これはあなたの好きな色のレベルの問題です。

---

翻訳者のメモ：投稿のタイトルとその主題は、映画 「モンティパイソンと聖杯」の断片への言及であり、円卓の騎士が死の橋を渡るために5つの3つの質問に答えています。