システムの複雑さの増加は、次世代のプログラマにどのような影響を与えましたか？
「新しい」プログラマー（私は2009年に最初にコード行を記述しました）として、.NETフレームワークなどを使用して今日の非常に複雑な要素を示すプログラムを比較的簡単に作成できることに気付きました。ビジュアルインターフェイスの作成、またはリストの並べ替えは、非常に少数のコマンドで実行できます。
プログラミングを学んでいたとき、並行してコンピューティング理論も学んでいました。ソートアルゴリズム、ハードウェアの連携動作の原理、ブール代数、有限状態機械などが含まれます。しかし、理論で学んだ非常に基本的な原則をテストしたい場合は、ライブラリ、フレームワーク、OSなどの技術によって多くのテクノロジーが隠されているため、始めるのが常にはるかに困難であることに気付きました。
十分なメモリがなく高価だったため、40/50年前にメモリ効率の高いプログラムを作成する必要がありました。そのため、ほとんどのプログラマは、データ型とプロセッサによる命令の処理方法に細心の注意を払いました。今日では、処理能力と利用可能なメモリの増加により、これらの懸念は優先事項ではないと主張する人もいます。
私の質問は、古いプログラマーがこのようなイノベーションを天の恵みとして、または抽象化するための追加のレイヤーとして見るかどうか、そしてなぜそう思うのでしょうか？そして、より若いプログラマーは、拡張ライブラリーの領域を探る前に、低レベルのプログラミングを学ぶことに利益をもたらすでしょうか？もしそうなら、なぜですか？
利用可能な処理能力とメモリの量が増えるので、それは単に必要ではありません。
安価なメモリ、巨大なディスク、高速なプロセッサを備えていることだけが、すべてのバイトとサイクルに執着する必要から人々を解放したわけではありません。コンパイラは、重要なときに高度に最適化されたコードを生成する点で、人間よりはるかに優れています。
さらに、私たちが実際に最適化しようとしているものを忘れないでください。これは、特定のコストに対して生み出される価値です。プログラマーは機械よりもはるかに高価です。プログラマーが機能する、正しく、堅牢で、フル機能のプログラムをより速く、より安価に作成するために私たちが行うことはすべて、世界でより多くの価値を生み出すことにつながります。
しかし、私の質問は、低レベルの要素のこの「非表示」について人々がどのように感じているかです。年配のプログラマーはそれを天の恵みだと思っていますか？
どんな仕事でも成し遂げることが絶対に必要です。私は生活のためのコードアナライザーを書きます。レジスタの割り当てやプロセッサのスケジューリング、その他の何百万もの詳細について心配する必要がある場合、バグの修正、パフォーマンスレポートの確認、機能の追加などに時間を費やすことはありません。
すべてのプログラミングは、その上にさらに価値のあるレイヤーを作成するために、その下のレイヤーを抽象化することです。すべてのサブシステムとそれらが相互にどのように構築されているかを示す「レイヤーケーキ図」を実行すると、文字通りダースのレイヤーがあることがわかりますハードウェアとユーザーエクスペリエンスの間。 Windowsレイヤーケーキ図には、生のハードウェアとC＃で「hello world」を実行する機能との間に必要なサブシステムが60レベルあるようなものがあると思います。
若いプログラマーは、拡張ライブラリーの領域を探る前に、低レベルのプログラミングを学ぶことで利益を得ると思いますか？
あなたは前に重点を置くので、私はあなたの質問に否定的に答えなければなりません。私は12歳の友人が今すぐプログラミングを学べるように手伝っています。x86アセンブラーではなく Processing.js で始めていると思われる方がよいでしょう。若いプログラマーをProcessing.js彼らは約8時間で独自のシューティングゲームを作成します。アセンブラーで開始すると、約8時間で3つの数値が乗算されます。若いプログラマーの興味を引く可能性が高いと思いますか？
質問が「ケーキのレイヤーnを理解するプログラマーはレイヤーn-1を理解することから利益を得ますか？」答えはイエスですが、それは年齢や経験とは無関係です。基礎となる抽象概念をよりよく理解することで、より高いレベルのプログラミングを改善できるのは常にそうです。
私はこの問題についてアイデアを持っていました、そして私は20年前に本にそれらを入れました それらを本に入れました 。それは絶版ですが、あなたは それでもAmazonで中古コピーを入手することができます ことができます。
あなたの質問に対する簡単な答えの1つは、アリストテレスと同じくらい古いものです-- Natureは掃除機を嫌います 。マシンがより速く、より大きくなるのと同じくらい、ソフトウェアはより遅く、より大きくなりました。
より建設的になるために、私が提案したのは、情報理論、およびソフトウェアとの直接的な関連性は、コンピューターサイエンス教育の一部であるというものでした。それは、仮にあったとしても、非常に接線的な方法でのみ教えられています。
たとえば、プログラムを入力シンボル、出力シンボル、ノイズ、冗長性、帯域幅を備えたシャノンタイプの情報チャネルと考えると、アルゴリズムのビッグOの動作を非常にきちんと直感的に理解できます。
一方、プログラマーの生産性は、コルモゴロフ情報理論を使用して同様の用語で理解できます。入力は頭の中での象徴的な概念構造であり、出力は指先から出てくるプログラムテキストです。プログラミングプロセスは、2つの間のチャネルです。ノイズがプロセスに入ると、一貫性のないプログラム（バグ）が作成されます。出力プログラムのテキストに十分な冗長性がある場合、バグをキャッチして修正することができます（エラーの検出と修正）。ただし、冗長である場合、それは大きすぎ、サイズが非常に大きく、エラー率と原因バグの。この推論の結果として、私は本のかなりの部分を費やして、プログラミングを言語設計のプロセスとして処理する方法を示し、ドメインを定義できるようにすることを目標として、ニーズに適した特定の言語。 CS教育ではドメイン固有の言語にリップサービスを提供していますが、やはり接線です。
言語の構築は簡単です。関数、クラス、または変数を定義するたびに、最初に使用した言語に語彙を追加し、作業に使用する新しい言語を作成します。一般的に認められていないのは、新しい言語を問題の概念構造にさらに一致させることを目的とすることです。これを行うと、コードと短縮の効果があり、理想的には概念とコードの間に1-1のマッピングがあるため、バグが少なくなります。マッピングが1-1の場合、間違いを犯して概念を別の概念として誤ってコーディングする可能性がありますが、プログラムがクラッシュすることはありません。これは、コード化したときに発生するものです一貫した要件がない。
これは得られません。ソフトウェアシステムの設計に関する勇気ある話し合いのすべてにおいて、要件に対するコードの比率はますます大きくなっています。
確かに、非常に便利なライブラリがあります。ただし、抽象化については非常に慎重である必要があると思います。 BがAに基づいて構築されているかどうかは問題ではなく、CがBに基づいて構築されている場合はさらに優れていると考えるべきではありません。それを「姫とえんどう」の現象と呼んでいます。問題のあるものの上にレイヤーを重ねても、必ずしも修正されるわけではありません。
長い投稿を終了するために、私はプログラミングのスタイルを開発しました（これは時々私を困らせます）。
- 発明は悪いことではありません。それはエンジニアリングの他の分野と同じように、良いことです。確かにそれは他人のための学習曲線を作成しているかもしれませんが、全体的な結果がより良い生産性である場合、それは価値があります。
- 俳句風のシンプルなコード。 特にはデータ構造の設計に使用されます。私の経験では、最近のソフトウェアの最大の問題は、肥大化したデータ構造です。
高度な抽象化は、コンピューティングの継続的な進歩を達成するために不可欠です。
どうして？なぜなら、人間は頭の中で多くの知識をいつでも持つことができるからです。このような抽象化を活用できるため、現代の大規模システムは今日のみ可能です。これらの抽象化がなければ、ソフトウェアシステムは単に自重で崩壊するだけです。
メソッドを書くたびに、抽象化を作成しています。メソッド呼び出しの背後に隠されている機能を少し作成しています。なぜあなたはそれらを書くのですか？メソッドをテストして機能することを証明し、必要なときにいつでもメソッドを呼び出すだけでその機能を呼び出すことができるので、メソッド内のコードについて考える必要がなくなります。
コンピューティングの初期の頃は、機械語を使用していました。私たちは、作成対象のハードウェアについて深い知識を持つ非常に小さなベアメタルプログラムを作成しました。それは骨の折れるプロセスでした。デバッガーはありませんでした。通常、プログラムは機能するか、クラッシュしました。 GUIはありませんでした。すべてがコマンドラインまたはバッチプロセスでした。あなたが書いたコードは、その特定のマシンでのみ機能します。別のプロセッサまたはオペレーティングシステムを搭載したマシンでは機能しません。
そのため、詳細をすべて抽象化する高級言語を作成しました。プログラムを他のマシンに移植できるように、仮想マシンを作成しました。プログラマがメモリの管理にそれほど熱心である必要がないようにガベージコレクションを作成しました。これにより、困難なバグのクラス全体が排除されました。ハッカーがバッファオーバーランで悪用できないように、境界チェックを言語に追加しました。別の方法でプログラムについて推論できるように関数型プログラミングを発明し、並行性をより有効に活用するために最近それを再発見しました。
このすべての抽象化により、ハードウェアから隔離されますか？もちろんです。テントを張る代わりに家に住んでいると、あなたは自然からあなたを守りますか？もちろんです。しかし、なぜ彼らがテントではなく家に住んでいるのか誰もが知っています。家を建てることは、テントを張ることとはまったく異なる球技です。
それでも、必要に応じてテントを張ることができ、プログラミングでは、ハードウェアに近いレベルに（可能であれば）ドロップダウンして、パフォーマンスやメモリのメリットを得ることができます。それ以外の場合は、高水準言語で達成してください。
抽象化しすぎませんか？ Scotty が言うように、「配管を追い抜く」？もちろんできます。良いAPIを書くのは難しいです。直感的で発見可能な方法で問題ドメインを正しく包括的に具現化する優れたAPIを作成することはさらに困難です。ソフトウェアの新しいレイヤーを重ねることは、常に最良の解決策とは限りません。 Software Design Patterns ある程度は、この状況をさらに悪化させました。経験の浅い開発者は、より鋭くより細いツールがより適切な場合に、彼らに手を伸ばすことがあるからです。
本当に良いトレーニングには、両方の極端な方法と、その間の架け橋が含まれます。
低レベルの側面では、アセンブリ言語の知識やコンパイラが実行していることなど、コンピュータがコードを最初から実行する方法*。
ハイレベル側：一般的な概念。内部でどのように機能するかを心配する時間を無駄にすることなく、連想配列、クロージャーなどを使用します。
IMHOの誰もが、両方の短所を含む両方の経験と、低レベルの概念から高レベルの概念にどのように移行するかについての経験を持っている必要があります。連想配列が好きですか？それでは、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です。コードを最適化すると、（残念ながら）抽象化のレベルを下げるのに役立つことがあります。つまり、下位レベルのレイヤーの観点からアルゴリズムを実装します。しかし、コンパイラは本当にこれをあなたに代わってifするのが得意です関連するすべてのコードを参照してください。この理由は、最近、プロセッサが弱い傾向にあり、「ワットあたりのパフォーマンス」がデスクトップシステムなどよりもはるかに重要であるモバイルデバイスや組み込みデバイスのブームによって人気が高まっています。
ただし、一般的には、（少し非効率的な方法であっても）コンピュータに何かをさせることがはるかに簡単になりました。つまり、以前よりもはるかに多くのプログラマがいることになります。 Robert Harveyの回答 は、「人間はいつでも頭の中で多くの知識しか持てない」とすでに述べています。それは今日非常に関連する側面です。
プログラミング言語とライブラリ（つまりAPI）の設計における主な動機は、人間の脳で物事をより簡単にすることです。今日まで、すべてがマシンコードにコンパイルされています。ただし、これはエラーが発生しやすいだけでなく、非常に理解しにくいことでも知られています。だからそれは非常に望ましいです
作成したプログラムの論理エラーを見つけるのにコンピューターを利用してもらいます。静的型システムやソースコードアナライザー（ Eric Lippert は最近人気のあるもので動作するようです）のようなものがそれを助けます。
コンパイラで効率的に処理できる言語とがintentプログラマーから他のプログラマーに渡って、プログラムの作業を容易にします。ばかげた極端な例として、単純な英語でプログラムを書くことを想像してみてください。仲間のプログラマーは、何が起こっているのかを想像するのに簡単な時間を持っているかもしれませんが、それでも、説明はマシンインストラクターにコンパイルするのが非常に難しく、悪名高くあいまいです。したがって、コンパイラが理解できる言語が必要ですが、これはも理解できる言語です。
多くの（ほとんど？）コンパイラーは依然として非常に汎用的なコンパイラであるため、非常に汎用的な命令セットを備えています。 「ボタンを描く」命令や「この映画を再生する」命令はありません。したがって、抽象化階層をdownに移動すると、プログラムを理解および維持するのが非常に困難になります（コンパイルは簡単ですが）。唯一の代替手段は、階層を移動して、より多くの抽象的な言語とライブラリにつながることです。
「もし古いプログラマーがこのようなイノベーションを天の恵み、あるいは抽象化するための追加のレイヤーと見なすとしたら、なぜそう思うのでしょうか？」
私は高校生の頃からプログラミングをしており、BasicとZ80アセンブラーから始めて、C、さまざまな4GL言語、Scheme、SQL、そして今ではさまざまなWeb言語に移行してから約34年になります。専門家が取り組む問題の範囲、規模、深さは、特に1990年代にその期間にわたってインフレの期間を経験しました。ライブラリ、フレームワーク、OSサービスなどの構成要素はすべて、問題の空間の拡大に伴う複雑さに対処するための工夫です。それらは天の恵みでも、それ自体の重荷でもありません。広大なソリューションスペースの継続的な探索です。
しかし、私見、「イノベーション」は、新しい形の観点からよりよく理解されており、横方向の動きと間違われることはありません。いくつかの点で、プリミティブフォームが構成されていない場合、進化の早い段階で決定が確定されている場合、または独自のデトリタスを再処理できない場合は、エコシステムの多産性が損なわれます。私たちが引き続き焦点を当てている構成要素のほとんどではないにしても、長期的な価値の持続を懸念事項として優先していません。それは変わり始めています。たとえば、ハイパーテキストやグラフベースのモデルは言うまでもなく、サービス指向やドメイン駆動設計などのアプローチが状況を変えています。他のエコシステムと同様に、最終的には優勢なフォームが新しいフォームに変わります。大規模なトップダウン標準化に続いて一度にすべてを崩壊させるのではなく、広く、小さな増分で多様性を許可することで、最善のサービスが提供されます。
「そして、若いプログラマーは、拡張ライブラリーの領域を探索する前に、低レベルのプログラミングを学ぶことにメリットがありますか？もしそうなら、それはなぜですか？」
ほとんどの人間の言語は忘れられて以来ずっとメタファーに基づいていると私は主張するので、私は科学/数値リテラシーの観点から低レベルのプログラミングの学習をサポートしますが、その規模と範囲をサポートするプリミティブを探すことがより重要です低レベルの詳細を安全に無視できる方法で取り組んでいる問題。フレームワークはプリミティブではなく、OSやライブラリでもありません。それらは、私たちが本当に必要とする種類の抽象化を行うのがかなり貧弱です。実際の進歩は、（a）以前に何が起こったのかを知り、（b）これまでに探究されたことのない、あるいは探究され忘れられた解決策の空間を探求するのに十分異なる何かを考案するのに十分な斬新な方法で考えることができる人々をとります。
OTOH、あなたの目標が技術者/機械レベルとして働くことである場合でも、低レベルのプログラミングのある程度のレベルは、問題解決スキルの開発に役立ちます。
私の最初のプログラム（15歳のティーンエイジャーとして）は、1974年のIBM 370/168メインフレーム用のパンチカードの PL/1 でした。父はIBMで働いていて、日曜日にデータセンターに行くことができて幸運でした。
当時、数千のステートメント（つまり、パンチされたカード）のプログラムは大きなプログラムでした（そして、何千ものパンチされたカードが数キログラムに相当するため、重いプログラムでもありました）。ビジュアルインターフェイスは存在しませんでした（//GO.SYSIN DD * IIRCで始まるパンチカードコマンドを使用して「標準入力」から読み取った典型的なプログラムですが、習得しませんでした [〜＃〜] jcl [〜＃〜] ）。アルゴリズムは重要であり、IIRC標準ライブラリは今日の標準ではかなり小さいものでした。
今日、数千行のプログラムは一般的に小規模と見なされています。たとえば、 [〜＃〜] gcc [〜＃〜] コンパイラには、ソースコードが1,000万行以上あり、nobodyそれらを完全に理解しています。
今日のプログラミングは1970年代とはかなり違うと思います。これは、はるかに多くのリソース（特に既存のライブラリとソフトウェアフレームワーク）を使用する必要があるためです。ただし、データセンターソフトウェア（Googleの検索エンジンなど）または一部の組み込みソフトウェアを開発している人は、1970年代の平均的なプログラマーよりもアルゴリズムと効率を重視していると思います。
全体像を理解することは依然として重要であるため、今日でも低レベルのプログラミングを理解することは重要だと思います（ほとんどのプログラマーがバランスツリーや二分法でソートされた配列などの基本的なコンテナーアルゴリズムを自分でコーディングしない場合でも）。
1970年代と今日の主な違いは、開発者の（人間の）努力とコンピュータ能力のコストの比率です。