システムの複雑さの増加は、プログラマーの次の世代にどのような影響を与えましたか？

「新しい」プログラマーとして（2009年に最初にコード行を書きました）、たとえば.NETフレームワークのようなものを使用して、今日非常に複雑な要素を示すプログラムを作成するのは比較的簡単であることに気付きました。ビジュアルインターフェイスの作成、またはリストの並べ替えは、ごくわずかなコマンドで実行できるようになりました。

プログラミングを学んでいたとき、コンピューティング理論も並行して学んでいました。並べ替えアルゴリズム、ハードウェアの動作原理、ブール代数、有限状態マシンなどのこと。しかし、理論で学んだ非常に基本的な原理をテストしたい場合、ライブラリ、フレームワーク、OSのようなものによって多くのテクノロジーが不明瞭になるため、始めるのが常にずっと困難であることに気付きました。

40/50年前には、メモリが十分でなく高価だったため、メモリ効率の高いプログラムを作成する必要がありました。そのため、ほとんどのプログラマは、データ型とプロセッサによる命令の処理方法に細心の注意を払いました。最近では、処理能力と使用可能なメモリの増加により、これらの懸念は優先事項ではないと主張する人もいます。

私の質問は、古いプログラマーがこれらのような革新を天の恵みまたは抽象化する追加の層と見るかどうかであり、なぜそう思うのでしょうか？そして、若いプログラマーは、拡張ライブラリの領域を探索する前に、低レベルのプログラミングを学ぶことにより多くの利益をもたらすでしょうか？もしそうなら、なぜですか？

処理能力と利用可能なメモリの量が増えたため、必要ありません。

安価なメモリ、巨大なディスク、高速なプロセッサを備えていることだけが、あらゆるバイトとサイクルに夢中になる必要性から人々を解放した唯一のものではありません。コンパイラは、高度に最適化されたコードを生成するという点で、人間よりもはるかに優れています。

さらに、実際に最適化しようとしているものを忘れないでください。これは、特定のコストで生み出される価値です。プログラマは機械よりもはるかに高価です。プログラマーが実用的で、正確で、堅牢で、フル機能のプログラムをより速く、より安価に作成できるようにするために私たちが行うことはすべて、世界でより多くの価値を生み出すことにつながります。

私の質問は、この低レベル要素の「隠蔽」について人々がどう感じるかということです。古いプログラマーは、それを天の恵みだと思っているのか、それとも不必要なレイヤーだと思っていますか？

作業を完了することが絶対に必要です。私は生計のためのコードアナライザーを書いています。レジスタの割り当てやプロセッサのスケジューリング、その他数百万の詳細について心配する必要がある場合、バグの修正、パフォーマンスレポートの確認、機能の追加などに時間を費やすことはありません。

プログラミングはすべて、その下にあるより価値のあるレイヤーを作成するために、その下のレイヤーを抽象化することです。すべてのサブシステムとそれらが相互にどのように構築されているかを示す「レイヤーケーキダイアグラム」を実行すると、ハードウェアとユーザーエクスペリエンスの間に文字通り何十ものレイヤーがあることがわかります。Windowsレイヤーケーキ図には、生のハードウェアとC＃で「hello world」を実行する機能との間に必要なサブシステムの60レベルのようなものがあると思います。

若いプログラマーは、拡張ライブラリーの領域を探索する前に、低レベルのプログラミングを学ぶことの恩恵を受けると思いますか？

あなたは前に重点を置いているので、否定的にあなたの質問に答えなければなりません。私は12歳の友人が今すぐプログラミングを学ぶのを手伝っています。x86アセンブラーではなく、Processing.jsでそれらを開始すると信じてください。あなたが若いプログラマーのようなもので始めると、Processing.js彼らは約8時間で彼ら自身のシューティングゲームを書くでしょう。アセンブラで起動すると、約8時間で3つの数値が乗算されます。若いプログラマーの興味を引き付ける可能性が高いのはどれだと思いますか？

質問が「ケーキのレイヤーnを理解しているプログラマーはレイヤーn-1を理解することから利益を得るのか？」答えはイエスですが、それは年齢や経験とは無関係です。基礎となる抽象化をよりよく理解することで、より高いレベルのプログラミングを改善できるのは常に事実です。

私はこのテーマについてアイデアを持っていて、20年前にそれらを本に入れました。絶版ですが、Amazonで使用済みのコピーを入手できます。

あなたの質問に対する簡単な答えのひとつは、アリストテレスと同じくらい古いものです。自然は真空を嫌います。マシンがより速く、より大きくなったのと同様に、ソフトウェアもより遅く、より大きくなった。

より建設的なものにするために、私が提案したのは、情報理論とソフトウェアとの直接的な関連性がコンピューターサイエンス教育の一部であることです。今では、たとえ非常に接線的な方法でしか教えられません。

たとえば、プログラムを入力シンボル、出力シンボル、ノイズ、冗長性、帯域幅を備えたシャノン型の情報チャネルと考えると、アルゴリズムのbig-O動作を非常にきちんと直感的に理解できます。

一方、プログラマーの生産性は、コルモゴロフ情報理論を使用して同様の用語で理解できます。入力は頭の中の象徴的な概念構造であり、出力は指先から出てくるプログラムテキストです。プログラミングプロセスは、2つの間のチャネルです。ノイズがプロセスに入ると、一貫性のないプログラム（バグ）が作成されます。出力プログラムのテキストに十分な冗長性がある場合、バグをキャッチして修正することができます（エラーの検出と修正）。しかし、それがある場合は、あまりにも冗長それはあまりにも大きく、誤り率と組み合わせて非常に大きさが、原因となるバグの導入を。この推論の結果、私はプログラミングを言語設計のプロセスとして扱う方法を示す本の大部分を費やしました、ニーズに適したドメイン固有言語を定義できるようにすることを目標としています。CS教育ではドメイン固有の言語にリップサービスを提供しますが、やはり接線です。

言語の構築は簡単です。関数、クラス、または変数を定義するたびに、使用する言語に語彙を追加し、使用する新しい言語を作成します。一般的に高く評価されていないのは、新しい言語を問題の概念構造により近づけることが目標であるべきだということです。これを行うと、理想的には概念とコードの間に1対1のマッピングがあるため、コードを短くしてバグを減らす効果があります。マッピングが1-1の場合、ミスを犯し、コンセプトを別のコンセプトとして誤ってコーディングする可能性がありますが、プログラムがクラッシュすることはありません。

これを取得していません。ソフトウェアシステムの設計に関するすべての勇気ある話では、要件に対するコードの比率はますます大きくなっています。

確かに、非常に便利なライブラリがあります。ただし、抽象化については非常に慎重でなければなりません。BがAに基づいて構築されている場合、CがBに基づいて構築されている場合はさらに優れていると想定するべきではありません。私はそれを「プリンセスとエンドウ」現象と呼びます。面倒なものの上にレイヤーを重ねても、必ずしもそれが修正されるわけではありません。

長い投稿を終了するために、プログラミングのスタイルを開発しました（時にはトラブルになります）。

• 発明は悪いことではありません。エンジニアリングの他の部門と同様に、それは良いことです。確かに他の人のための学習曲線を作成している可能性がありますが、全体的な結果が生産性の向上であれば、価値があります。
• Haikuスタイルのミニマリストコード。これは特にデータ構造設計に当てはまります。私の経験では、最近のソフトウェアの最大の問題は、肥大化したデータ構造です。

高度な抽象化は、コンピューティングの継続的な進歩を達成するために不可欠です。

どうして？なぜなら人間はいつでも頭の中にたくさんの知識しか持たないからです。このような抽象化を活用できるため、現代の大規模システムは今日のみ可能です。これらの抽象化がなければ、ソフトウェアシステムは単純に自重で崩壊します。

メソッドを記述するたびに、抽象化が作成されます。メソッド呼び出しの背後に隠れている機能を少し作成しています。なぜそれらを書くのですか？メソッドをテストし、機能することを証明し、メソッド呼び出しを行うだけで必要なときにいつでもその機能を呼び出すことができるため、そのメソッド内のコードについて考える必要がなくなります。

コンピューティングの初期には、機械語を使用していました。私たちは、ハードウェアを作成するためのハードウェアに関する深い知識を持って、非常に小さなベアメタルプログラムを作成しました。それは骨の折れるプロセスでした。デバッガはありませんでした。あなたのプログラムは通常動作したか、クラッシュしました。GUIはありませんでした。すべてがコマンドラインまたはバッチプロセスでした。作成したコードは、その特定のマシンでのみ機能します。異なるプロセッサまたはオペレーティングシステムを搭載したマシンでは動作しません。

そこで、すべての詳細を抽象化するための高水準言語を作成しました。プログラムを他のマシンに移植できるように、仮想マシンを作成しました。プログラマがメモリ管理についてそれほど熱心にならなくて済むように、ガベージコレクションを作成しました。これにより、クラス全体の難しいバグが排除されました。ハッカーがバッファオーバーランで悪用できないように、言語に境界チェックを追加しました。私たちは関数型プログラミングを発明して、プログラムを別の方法で推論できるようにしました。最近、並行性をより活用するためにそれを再発見しました。

このすべての抽象化は、あなたをハードウェアから隔離しますか？確かにそうです。テントを張る代わりに家に住むことは、あなたを自然から隔離しますか？絶対に。しかし、誰もがテントの代わりに家に住んでいる理由を知っています。家を建てることは、テントを張るのとはまったく異なる球技です。

それでも、それを行う必要がある場合でもテントを投げることができます。プログラミングでは、ハードウェアに近いレベルまでドロップダウンして、パフォーマンスやメモリのメリットを得ることができますそれ以外の場合は、高水準言語で達成してください。

抽象化しすぎませんか？スコッティが言うように、「配管を追い越す」？もちろんできます。良いAPIを書くのは難しいです。問題領域を正確かつ包括的に具体化する優れたAPIを、直感的で発見可能な方法で記述することはさらに困難です。ソフトウェアの新しいレイヤーを重ねることが常に最適なソリューションとは限りません。 経験の浅い開発者は、より鋭く、よりリーンなツールがより適切である場合に、時々彼らに手を差し伸べるため、ソフトウェア設計パターンは、ある程度、この状況を悪化させました。

本当に良いトレーニングには、両方の極端なものと、その間の橋渡しが含まれます。

低レベル側：コンピューターがコードをゼロから実行する方法*（アセンブリー言語の知識やコンパイラーが行っていることを含む）。

ハイレベル：一般的な概念。たとえば、連想配列、クロージャなどを使用し、内部でどのように動作するかを心配する時間を無駄にしません。

私見は誰もが欠点を含めて両方を経験し、低レベルの概念から高レベルの概念に到達する方法を味わう必要があります。連想配列が好きですか？すばらしい、1kBのRAMを搭載した50セントの組み込みプロセッサで使用してみてください。Cを使用して高速コードを書くのが好きですか？これで、3週間でWebアプリを作成できました。Cを使用してデータ構造とメモリ管理に時間を費やすか、新しいWebフレームワークを学習して数日でWebアプリを実装することに時間を費やすことができます。

それの複雑さの面に関しては、最近は複雑なシステムを作ることのコストを明確に理解せずに作るのは簡単すぎると思います。その結果、私たちは社会として、時々私たちに噛みつく膨大な技術的負債を積み上げてきました。それは地震のようなものです（地質学的断層の近くで生活するための費用ですよね？）、それだけが徐々に悪化しています。そして、私はそれについて何をすべきか分かりません。理想的には、複雑さの管理について学び、より良くなると思いますが、そうなるとは思いません。責任ある工学教育には、ほとんどの大学が現在提供しているものよりもはるかに多くの複雑さの結果に関する議論を含める必要があります。

*そして、とにかく、コンピューターがコードを実行する方法の「グラウンド」はどこですか？アセンブリ言語ですか？それともコンピュータアーキテクチャですか？それともデジタルロジックですか？それともトランジスタ？またはデバイス物理学ですか？

高レベルのプログラミングには多くの利点があり、プログラミング言語の重要な部分だと思います。Javaが成功する理由の1つは、包括的なライブラリがあることです。より少ないコードでより多くを達成します-定義済みの関数を呼び出すだけです。

プログラミング言語のユーザーとプログラミング言語のライター（コンパイラライター）を区別できるようになりました。最適化はコンパイラライターに任せます。保守性、再利用などに重点を置いています

システムの複雑さの増大は容赦なく、圧迫され、最終的には不自由です。古い世代のプログラマとしての私にとっても、非常に残念です。

私は40年以上プログラミングを続けており、50〜100の異なる言語または方言でコードを記述し、5〜10の専門家になりました。私が非常に多くを主張できる理由は、ほとんどが同じ言語であり、微調整を加えているからです。この調整により複雑さが増し、すべての言語がわずかに異なります。

コレクション、変換、並べ替えと検索、エンコード/デコード、フォーマット/解析、バッファと文字列、算術、メモリ、I / Oなど、同じアルゴリズムを何度も実装しました。すべての実装は少しずつ異なるため、新しい実装はすべて複雑になります。

Webフレームワークやモバイルアプリの空飛ぶ空中ブランコの芸術家たちが生み出した魔法、そしてこんなに短い時間でこんなに美しいものをどのように作り出すことができるのか、私は疑問に思います。それから、彼らがどれだけ知らないか、彼らがデータや通信、テスト、スレッド、または何をする前に何を学ぶ必要があるかを理解します。

私は、第4世代言語の時代に自分の技術を学びました。そこでは、ライティングソフトウェアの繰り返し部分をますます多く取り込むために、より高いレベルの言語を連続して生成すると信じていました。それで、それは正確にどうなったのですか？

MicrosoftとIBMは、WindowsとOS / 2向けのアプリを書くためにCに戻ることでその考えを打ち破りましたが、dBase / Foxpro、さらにはDelphiも衰退しました。その後、Webは、HTML、CSS、およびJavaScript / DOMのアセンブリ言語の究極のトリオで再びそれを行いました。そこからすべて下り坂です。常により多くの言語、より多くのライブラリ、より多くのフレームワークとより複雑な。

私たちは別のやり方でそれをしなければならないことを知っています。CoffeeScriptとDart、LessとSass、HTMLを記述しなくても済むテンプレートについて知っています。とにかく知っています。私たちには漏れやすい抽象化に満ちたフレームワークがあり、不可解な呪文を学ぶ少数の選ばれた人々によって何ができるのかを見ていますが、私たちと私たちのプログラムは過去の決定に閉じ込められています。変更したり最初からやり直したりするには複雑すぎます。

その結果、簡単であるべきことは容易ではなく、複雑であることから可能であるべきことはほとんど不可能です。確立されたコードベースに新しい機能を実装するために変更を加えるコストを見積もることができ、私は大丈夫だと確信できます。見積もることはできますが、正当化することも説明することもできません。複雑すぎます。

最後の質問への回答として、若いプログラマーにできる限りレイヤーケーキの上位に着手し、必要性と欲求が推進力を提供する場合にのみ下位レイヤーに飛び込むことを強くお勧めします。私の好みは、ループがなく、分岐や明示的な状態がほとんどまたはまったくない言語です。LispとHaskellが思い浮かびます。実際には、私は常にC＃/ Java、Ruby、Javascript、Python、およびSQLで終わります。それがコミュニティがある場所だからです。

最後の言葉：複雑さは究極の敵です！それを打つと人生はシンプルになります。

私の質問は、この低レベル要素の「隠蔽」について人々がどう感じるかということです。古いプログラマーは、それを天の恵みだと思っているのか、それとも不必要なレイヤーだと思っていますか？

どちらでもない。

レイヤー化が必要なのは、それがなければ、システムが維持不可能なスパゲッティになってしまうからです。また、再利用性の原則の1つでもあります。ライブラリの開発者が良い仕事をすれば、それを使用する人々は実装の詳細を気にする必要はないはずです。私たちのシステムで使用する定型コードの量は、35年前に最初のプログラムを作成したときの数倍の規模で増加しています。その成長は、時間が経つにつれてより強力なことができるようになることを意味します。これはいい。

私にとって問題だった場所は完全に文化的です。私の実利的な半分は、最後の細部に心を包み込み、やりたいことを終わらせることはもはやできないことを理解しています。（年をとっても助けにはなりません。）私の変な灰色あごひげの半分は、私が取り組んでいたすべてのことをきめ細かく理解するのに何年も費やす手間がかかりました。

若いプログラマーは、拡張ライブラリーの領域を探索する前に、低レベルのプログラミングを学ぶことの恩恵を受けると思いますか？

他の回答で指摘されているように、新参者の注意を引き付けて維持し、彼らに理想的な、下から上への教育を与えることの間には、バランスを取る必要があります。前者を実行できない場合、後者は発生しません。

私たちの業界には、他の社会と同じようなものがあります。以前は、ほとんどすべての人が自分の食べ物を育て、それをするのに多くの時間を費やしていました。それ以来、私たちはその仕事をする農家と呼ばれる専門家を発芽させ、社会に貢献する他のことを他の人に自由にさせました。私は食料品店で食料を購入しますが、必要な場合はほとんど自分で食料を完全に生産することはできません。はるかに圧縮された時間スケールではありますが、同様のことが進行しています。プログラマーは、ある層のセットに特化しており、他の層のセットには特化していません。GUIを記述する平均的な人は、スワップスペースなどがあることを知っているかもしれませんが、おそらくオペレーティングシステムがそれをどのように管理しているかについてはあまり気にしていないでしょう。

このすべての結果は、もはや単なる開発ではないということです。継続的な専門化により、開発者はコミュニケーションと統合のスキルを継続的に向上させる必要があります。

すべての場合と同様に、少しでも良いことがありますが、あまりにも痛いです。問題は、停止するタイミングがわからないシステムが多すぎることです。もう1つ抽象化するだけで、プログラムの高速化が可能になります...特徴の少ない抽象化で費やすよりも、エッジの周りで作業することに多くの時間を費やしてください。

ここで説明されている

またはここ -「1行のコードでドメインに500人のユーザーを追加できます」...

あなたの抽象化はあなたから複雑さを隠そうとしますが、実際にはそれらがすることはその複雑さを隠すことです。複雑さはまだありますが、それを制御することははるかに少ないというだけです。だからこそ、このような状況に陥るのです。

若いプログラマーは、拡張ライブラリーの領域を探索する前に、低レベルのプログラミングを学ぶことにより恩恵を受けますか？もしそうなら、なぜですか？

そうは思いません。「レイヤー下」の動作が低いことに注意することが有益な状況はまだたくさんあります。例えば

• レイヤーnで問題をデバッグする場合、レイヤーn-1（つまり、下のレイヤー）で何が起こるかを考慮することで多くの場合説明できます。レイヤー0は「トランジスター」だと思いますが、トランジスターの問題を説明したい場合は、おそらく物理学（例えば、熱）について話すので、物理学は実際にはレベル0です。

• コードを最適化するとき、（残念ながら）抽象化のレベルを下げるのに役立つことがあります。つまり、低レベルのレイヤーに関してアルゴリズムを実装します。ただし、コンパイラーは、関係するすべてのコードが実際に表示される場合、これを行うのが本当に上手くなりました。この理由は最近、モバイルおよび組み込みデバイスのブームでより一般的になりました。モバイルおよび組み込みデバイスは、プロセッサが弱く、「ワットあたりのパフォーマンス」が、たとえばデスクトップシステムよりもはるかに重要です。

しかし、一般的には、コンピューターに（やや非効率な方法であっても）作業をさせるのがずっと簡単になりました。つまり、以前よりもずっと多くのプログラマーがいるということです。これは、順番に「人間」の要素をより重要にしました。ロバート・ハーベイの答えは、「人間はいつでも頭の中にそんなに多くの知識しか持てない」と述べました。

プログラミング言語とライブラリ（API）の設計における主な動機は、人間の脳で物事を簡単にすることです。現在でも、すべてがマシンコードにコンパイルされています。ただし、これはエラーが発生しやすいだけでなく、理解が難しいことでも有名です。とても望ましい

• 作成するプログラムの論理エラーを見つけるのにコンピューターを助けてもらいます。静的型システムやソースコードアナライザー（最近ではEric Lippertがかなり人気のあるもので動作していると聞きます）のようなものがそれを助けます。

• コンパイラーで効率的に処理できる言語を持ち、プログラマーの意図を他のプログラマーに伝えて、プログラムでの作業を容易にします。馬鹿げた極端な例として、平易な英語でプログラムを書くことができると想像してください。仲間のプログラマーは、何が起こっているのかを想像するのは簡単かもしれませんが、それでも機械のインストラクターへのコンパイラーの記述は非常に困難であり、あいまいなことで有名です。そのため、コンパイラーが理解できる言語が必要ですが、これもわかりやすい言語です。

多くの（ほとんどの？）コンパイラーは依然として非常に汎用的であるため、非常に汎用的な命令セットを備えています。「ボタンを描く」指示や「この映画を再生する」指示はありません。したがって、抽象化階層を下に移動すると、理解して保守するのが非常に難しいプログラムになります（コンパイルするのは簡単ですが）。唯一の選択肢は、階層を上に移動して、ますます抽象的な言語とライブラリに導くことです。

「古いプログラマーが、このような革新を天の恵みや抽象化する追加の層と見なしているのなら、なぜそう思うのでしょうか？」

私は高校生の頃から約34年間プログラミングを行ってきました。BasicとZ80アセンブラーから始まり、C、さまざまな4GL言語、Scheme、SQL、そしてさまざまなWeb言語に移行しました。専門職が取り組む問題の範囲、規模、および深さは、特に1990年代にその期間にわたってインフレ期を経験しました。ライブラリ、フレームワーク、OSサービスなどの構造体はすべて、問題の拡大したスペースに伴う複雑さに対処するための工夫です。それらは天の恵みでもなければ、それ自体の重荷でもありません-広大なソリューション空間の継続的な探求です。

しかし、私見、「革新」は小説の形でよりよく理解されており、横向きの動きと誤解されていません-すでに紹介した形を再紹介しています。ある意味では、原始的な形態が構成されない場合、進化の初期に行われた決定を固定する場合、または独自の残骸を再処理できない場合、生態系の繁殖力が損なわれます。ほとんどではないにしても、私たちが焦点を当てている構成要素の一部は、価値の長期的な維持を懸念として優先しません。それは変化し始めました-たとえば、ハイパーテキストやグラフベースのモデルはもちろんのこと、サービス指向やドメイン駆動設計のようなアプローチは、風景を変えています。他のエコシステムと同様に、最終的に支配的な形態は新しい形態に取って代わります。私たちは多様性を許すことによって最高のサービスを提供します、

「そして、若いプログラマーは、拡張ライブラリの領域を調査する前に、低レベルのプログラミングを学ぶことの恩恵を受けますか？もしそうなら、なぜですか？」

ほとんどの人間の言語は忘れられてからずっと比metaに基づいていると主張するので、科学/数値リテラシーの観点から低レベルのプログラミングを学習することをサポートしますが、その規模と範囲をサポートするプリミティブを探すことがより重要です下位レベルの詳細を安全に無視できる方法で取り組んでいる問題。フレームワークはプリミティブではなく、OSやライブラリでもありません。本当に必要な種類の抽象化を行うのはかなり苦手です。真の進歩は、（a）前に何が起こったのかを知っており、（b）以前に探求されていないか、探求され忘れられた解決の空間を探求するのに十分に異なる何かを思い付くのに十分に斬新な方法で考えることができる人々を取ります。

OTOH、たとえあなたの目標が技術者/機械レベルとして働くことであったとしても、ある程度の低レベルのプログラミング経験は、あなたの問題解決能力を開発するのにまだ役立つでしょう。

私の最初のプログラム（15歳のティーンエイジャーとして）は、1974年にPL / 1でIBM 370/168メインフレームのパンチカードで行われました。父はIBMで働いていたので、日曜日にデータセンターに行くことができたのは幸運でした。

当時、数千の声明のプログラム（つまり、パンチされたカード）は大きなプログラムでした（また、数千のパンチされたカードの重量が何キロにもなるため、重いプログラムでもありました）。ビジュアルインターフェイスは存在しませんでした（//GO.SYSIN DD *IIRCで始まるパンチカードコマンドを使用して「標準入力」から読み取った典型的なプログラムですが、JCLをマスターしませんでした）。アルゴリズムは重要であり、標準ライブラリであるIIRCは今日の標準ではかなり小さかった。

今日、数千行のプログラムは一般に小規模と見なされています。たとえば、GCCコンパイラには1,000万行を超えるソースコードがあり、それらを完全に理解している人はいません。

私は、今日のプログラミングは1970年代とはかなり異なっていると感じています。なぜなら、はるかに多くのリソース（特に、既存のライブラリとソフトウェアフレームワーク）を使用する必要があるからです。ただし、データセンターソフトウェア（Googleの検索エンジンなど）や一部の組み込みソフトウェアを開発している人々は、1970年代の平均的なプログラマーよりもアルゴリズムと効率を重視していると思います。

全体像を理解することは依然として重要であるため、低レベルのプログラミングを理解することは今日でも重要です（ほとんどのプログラマーは、バランスの取れたツリー、二分法でアクセスされるソートされた配列などの基本的なコンテナーアルゴリズムをコーディングしない場合でも）。

1970年代と今日の主な違いは、開発者の（人間の）努力とコンピューターの能力のコストの比率です。