プログラマーはマシン語を理解しておくべき？ 310
ストーリー by Oliver
そこのあなたにパタヘネ本 部門より
そこのあなたにパタヘネ本 部門より
Fatalwedge 曰く、
shi3zの日記にて
から始まる文章に対して波紋が広がっているようです。当然のことながら、プログラムというのは、マシン語を理解して初めて「書ける」と言うのです。
タレコみ子は現在プログラミングとはほど遠い業務に居ますが、マシン語まではいかないもののPCアーキテクチャの基礎原理を理解しておいて良かった、と感じる場面には多々遭遇します。ましてやプログラマーであれば確かにマシン語（レベルでの理解）をしておいた方が望ましいと思うのですが、さて/.に集うエンジニアの皆様はどれだけマシン語を理解していますでしょうか？また必要性を感じた場面は？
旅行者の法則 (スコア:5, 興味深い)
自分が機械語解るからって、先輩面しちゃいけませんね。
ショクレー先生に「コンピュータは半導体を自分で接合してから初めて『使える』と言うのです」と
説教してもらいたいです。あとこのコピペも。
696 ：Mr.名無しさん ：2007/01/09(火) 22:53:01
電車のボックスシート(２人掛けの席が向かい合っている)で、
隣に座ったオヤジが激しくふんぞり返って股を広げきっていたので、
わたし「狭いんですけど」と言ったら、
オヤジ「しょうがないだろう！これ以上どうやってよけるんだ？」
わたし「どうやっても何も、他の人はきちんと座れてるじゃないですか」
オヤジ「女の癖にうるさい！」
わたし「女の癖にって、あなただって女から産まれてきたんじゃないんですか？」
オヤジ「屁理屈を言うな！大体、それが目上の者に対する態度か！」
わたし「目上と年上は違うと思うんですけど。
バカでも死にさえしなけりゃ年はとれますから」
オヤジ「目上も年上も同じだ！年上の言うことは黙って聞け！」
その時、向かい側に座ってた初老の男性が、
「じゃあ俺の言うことなら黙って聞くんだな？」
と一言。
オヤジは返す言葉がなかったらしく、席を立って
次の駅で降りてしまいました。
Re:旅行者の法則 (スコア:5, おもしろおかしい)
「昨今のCPUはマシン語からμopに変換するので、マシン語は相対的に高級言語だ。
だからマシン語はμopを理解してから初めて云々」
と言って欲しいですね。
知っていて欲しいのはSQLの処理のされかたぐらい (スコア:4, 参考になる)
じゃあプログラマがマシン語のようなものを通じて知っておくべき知識ってなんだろう？
・スタック
・ポインタ（アドレス）
・ビット演算
正直どれも要らない。
プログラミングの基礎として知っておいて欲しいのはこんなところじゃないかな。
・無駄なリソースを使いまくらない。
・実際にどうやって処理されるか考えて書こう。
特にSQLなんかだと、テキトーに書いて一生終わらないクエリがよくあるので、データベースの中でどのように処理されるのか想像できるぐらいの知識が欲しい。
Re:知っていて欲しいのはSQLの処理のされかたぐらい (スコア:2, 参考になる)
Javaやスクリプト言語でWeb系開発するくらいなら、概ね同意ですが、
CやC++を生業としてる人や、組み込み系な人は、上記３項目は基礎知識として必要じゃないですかね。
プログラミングと一口に言っても、ワンマイコンチップのファームウェアから、ビジネスロジックまで、
いろいろあるから、こればかりは、分野によるでしょうなあ。
そういう意味では、SQLの仕組みの知識についても、分野次第で、必要だったり不要だったり。
私の場合、C++でSQLクエリエンジンを実装したことがあるので、どちらもやる羽目に。。。
Re:知っていて欲しいのはSQLの処理のされかたぐらい (スコア:2, すばらしい洞察)
O(exp(N))についていく富豪というのは、逆にCPUロードがあげたいがために一生懸命アプリを探している、
某京速なんとかな人たち？
Re:旅行者の法則 (スコア:3, すばらしい洞察)
理解できるよう努力しますんでぜひとも公開してください。
Re:旅行者の法則 (スコア:3, すばらしい洞察)
時代によってCPUも変わるし、プログラム言語の流れだって変わってる。
なにで書くかなんて飾りです。それがご老人にはわからんのですよ。
むしろ、数多くのアルゴリズムを知識として蓄積したほうが、 よっぽど「書ける」プログラマの素質なんじゃないかなと思いますけどね。 実際に、指定された言語で書けるかどうかはわからないけど、 学習は早いと思いますよ。
Re:旅行者の法則 (スコア:3, すばらしい洞察)
「当然のことながら、プログラムというのは、マシン語を理解して初めて「書ける」と言うのです。」
なんて言うのは傲慢すぎ。それが先輩面ってこと。
それに自分で半導体作れなくてもコンピュータは使えるってことで。
モデレートに文句言うのはかっこ悪いよ。
参考リンク (スコア:5, 参考になる)
肩が凝った人のためにネタ [bogusne.ws]も置いておこう。
プログラマーは日本語を理解しておくべき (スコア:5, すばらしい洞察)
Re:プログラマーは日本語を理解しておくべき (スコア:3, すばらしい洞察)
「プログラマはアーキテクチャを理解して一人前」とか言い直したら評価はかわるのかな？
僕含め、賛同する人はみんな「マシン語==アーキテクチャ」に変換してますよね。
純粋に「マシン語」であるというのであれば、僕も要らないと思う人ですが、
アーキテクチャを理解する事はプログラマとして、必須でしょうとも思う。
そして、マシン語はアーキテクチャに直結しますから。ねぇ？
Re:プログラマーは日本語を理解しておくべき (スコア:3, 参考になる)
まさに、これが「美しい」と言えたのはその頃の話でしょうね。
私は64KBの広大なメモリを持つMZ-80Bからなので、その手のコードは「トリッキーな」、あるいは「邪悪な」と呼ばれていたように思います。
確かに、初めて 「RST C, 38H」 (38 FF ＝ JR C, -1; RST 38H)(FFを1回目は相対アドレスとして、ジャンプ後はRSTとして使用) とか
「JP (BC)」 (C5 C9 ＝ PUSH BC; RET) なんてのを見たときには感心したりもしましたけど。
本当にあった怖い話 (スコア:5, 興味深い)
Pen4 2.8G HTで2000秒かかった。
（プログラムはとある画像処理のプログラム）
何でかなぁと思ってソースを眺めていたら (注・他人が書いたコード)、
ifの嵐になっている部分があり、なおかつそのifの分岐確率がほぼトントンのようだった。
そのため、分岐予測が失敗して、パイプラインストールが大量に発生していて、
パイプラインの深いPen4が圧倒的に遅くなってしまったようだ。
これマシン語じゃなくて、CPUの中の人の話か……。
整理して組み上げる練習 (スコア:4, 興味深い)
一応CAD屋やってます。
最近のCADはパラメCADと言って、形状を手順で表現するのが普通です。たとえば、円柱を表現するときに、円を軸方向に平行移動した軌跡であるとか、長方形をその1辺を軸にして360度回転させた軌跡だとか、いろいろ表現できるわけです。
これは形が複雑になってきても同じで、いかに簡単な図形を組み合わせて形状を作っていくかという勝負になります。この時に必要なのは「物事を整理してひとつずつ順番に組み上げる」という考え方です。その手順は何通りもありますが、目的に応じて選択する力も要ります。
実は、CADは持って生まれたセンスというか得手不得手があるので、モデリングが下手な奴(でもパソコンは自称得意な奴)は、業務をサポートするマクロを作るほうに回そうとしたのですが、これがちゃんとしたマクロも組めない。実は必要とされるのはCADモデリングと同じ「物事を整理してひとつずつ順番に組み上げる」ことだったのです。
そう思うと、アセンブラというのは一番プリミティブな道具しかないので、「物事を(ｒ」練習には向いています。アセンブラを知らないからその考え方ができないとは言わないけど、逆にアセンブラをやってればそういう練習は嫌でもしたはずですから、そういう人のほうがプログラミングも上手だし、ひょっとしたらCADモデリングも上手かもしれません。
そういった意味でアセンブラやれってのは賛成。
言語と目的によるだろ (スコア:3, すばらしい洞察)
もしかしてJavaとかPerlとかPHPとかでのコーディングははプログラミングじゃねぇ！とかいいたいんじゃ・・・とか思って元記事を見たらそうではないみたいですが。
# 学生時代に実習でマイコンのプログラミングをしたとき、「サブルーチンをアセンブラで書いてもいいですか」と教官に聞いたら「そんな無駄なことする必要はない」とか言われたことをふと思い出した
Re:言語と目的によるだろ (スコア:2, すばらしい洞察)
○「そんな（オレが知らないアセンブラをを見るという時間の）無駄なこと（をさせる気か？だから）する必要はない（ただでさえ…）」
Re:言語と目的によるだろ (スコア:2, 興味深い)
＞「サブルーチンをアセンブラで書いてもいいですか」と教官に聞いたら
＞「そんな無駄なことする必要はない」とか言われたことをふと思い出した
無駄です。
あなたが聞いたと言うことは、あなたが出来るからです。
なのでわざわざ書く必要がないということです。
カリカリチューンしろという課題ならともかく、
そうでない部分の学習だとしたら教師の言うことはもっともです。
# ただ「必要はない」だけで書いてもよかったんじゃないですかね？
# 完璧を期すなら、アセンブラを使うバージョンと使わないバージョンを作りましょう。
Re:言語と目的によるだろ (スコア:2, すばらしい洞察)
だってコンパイラやCPU自体にバグが無いって訳では無いですから。
「マシン語」が必要になる「目的」 (スコア:2, 興味深い)
# 実際に書いたことはないので本当に必須かどうかは知らない
Re:「マシン語」が必要になる「目的」 (スコア:2, すばらしい洞察)
食い扶持でCやC++でコードを書いている人は自分の書いたコードがどういう風に
機械語に変換されて実行されているか位は少なくとも知るべき。
自分の書いたプログラムに脆弱性が発見されてもどこをどう直せば直るのか全く
わからないという屈辱を味わう事になるよ。
#そして無能な開発者は本来はお礼を言わなきゃならない報告者に逆ギレするわけだ
Re:言語と目的によるだろ (スコア:2, 参考になる)
ほんとかどうかはしらんけど。
Re:言語と目的によるだろ (スコア:2, 興味深い)
無いのですよ。下手にバイトコードレベルでいじって最適化(と思い込んでいる行為)を
やるとかえって遅くなる危険性が高いですよ。
Re:言語と目的によるだろ (スコア:4, 参考になる)
現在のサーバサイド Java の場合、最適化は確率と統計の世界に入ります。
JIT コンパイル自体が実行時間の一部になってしまうので、JIT 範囲を絞り込むためにプロファイリングを行い、HotSpot と判断した部分のみコンパイルします。
なので、同じコードでも、プログラム中での実行頻度によって実行速度が変わる -それも実行の途中から- のです。
こうなるとネイティブ環境での常識が通用しません。マイクロベンチマークを回すと極度に最適化されて良すぎる結果が出るとか。
ルールで最適化の正否を判断できないので、システムの組みように困るというか、悪いと思える場所でも影響がどのくらい有るのか分かりにくいというか。
参照: 日本HP - HP-UX Developer Edge - メモリ・リーク解析とHotSpot JVM [hp.com] (日本HPのサイトですしメモリリークを解説する記事の一部ですが、これが一番端的な解説をしていると思います)
たとえば (スコア:3, すばらしい洞察)
マシン語の知識は学ぶ価値がある。
マシン語の知識をまったく持たない人間に、
マシン語の知識の要・不要など論じる資格はない。
マシン語の知識はそういうものだと思う。
必要性を感じた時～♪ (スコア:3, 興味深い)
--
C++ でプログラムを書いていて、C++ レベルでは間違っていないはずなのに動作がおかしいという事があり、アセンブリ言語（≒マシン語）レベルで調べてみると、コンパイラ（Visual C++ 6.0）の最適化処理がバグってた…orz
同じようなことを言うのであれば (スコア:3, 興味深い)
マシン語ぐらい常識だよなっ！ (スコア:3, 興味深い)
デバッガで動かすと何事もなかったかのようにマシン語コードの中にステップインしたりするのを見ていると、
「マシン語ぐらい常識だよなっ！」
と、マイクロソフトの中の人が主張している気がする。
もう若くないので勘弁して下さい。
せめて疑似コードぐらいにまからないものか……
-- Where your reading book is, there will your heart be also 天戸 司郎 (Silo Amato)
教える立場から見ると (スコア:3, 参考になる)
授業で学生にキャッシュやパイプラインの話をしても、上の空。
でも、これらの話と関連させて自分のPCの性能測定と考察をやらせると、
関心の度合いがぜんぜん違う。
すごい単純なプログラムで、性能が100倍も違う場面を見せられたら、
気になるでしょうね。
知識って、役に立つ場面が思いつかなければ、不要だと思って
しまうんです。
# /.Jで 薀蓄を語るって言うのも、十分役に立つ部類かと、
こういうことを言いたくなる気持ちは分かる (スコア:3, 興味深い)
そんな感じの障害が突然発生して、それを最優先で復旧しなきゃいけない、
とかそんな事態があるわけですよ。
で、そういう障害の原因を調査すると、ソフトウェアが原因だったりすることが多いわけ。
デバッガとか使いながら原因と思しきプログラムのソースコードを見ると、一目で
「ああ、俺だったらこんなアルゴリズムにしないのに…重くて当然だよ…」
と感じるわけです。実際、そこを修正すればすぐに障害復旧できたりする。
んで、なぜ自分がその原因箇所を理解できたか？ …と考えると、やっぱりマシン語レベルというか、
そういうところの知識を利用してるんだよね。
マシン語まで理解している奴が職場にいなかったら、
この障害は長期間持続することになったかもしれない。
そもそも、開発者がマシン語を理解していれば、障害は発生しなかったかもしれない。
そういう経験を何度かすることによって、「プログラマはマシン語を理解しておくべき」という
信念が形成されるわけだ。
逆に言えば、障害時に原因箇所を特定できる能力を養える他の方法があるのなら、
別にマシン語を理解しなくてもいいと思うんだよね。
ま、そんな方法思いつかないから、現状ではマシン語を理解するのはベストの方法だと思うけど。
そんなわけで、全員とは言わなくても、
アプリケーション開発者の１０人に一人くらいはマシン語まで理解している人がいて、
その人を開発のリーダー的なところに置いておいたほうが品質が向上するんじゃないかと思います。
# mishimaは本田透先生を熱烈に応援しています
そりゃそうだろ (スコア:2, すばらしい洞察)
常識だ！とかいってもしょうがないものがいっぱいあるように。
メールの仕組みなんかしらなくたって
携帯電話からメールは送れるし
その人たちにメールの仕組みを知るべきとかいってもしょうがないし
というレベルぐらいまで
しらないままに書ける言語がでてきているからしょうがないとおもう。
自分はいろいろ開発しているけど
プログラマもどきだしＳＥでもない
そんなふうに自分が足元がおぼつかないことは
文系の女子は自分自身が一番よく知っている
そんなことにわざわざ突っ込みいれるのは
モテないかも
それぐらい
Re:そりゃそうだろ (スコア:2, すばらしい洞察)
のたまう講師がいました。
これを聞いて、「SMTPを理解していない人が居るからこそ、SMTPを理解している人に価値があるんじゃねーの？」と思いました。
遙か昔は「読み書きできる」ってだけで仕事になったのに、今では読み書きなんて（少なくとも日本では）仕事が出来る最低限のライン。
少し前は「コンピュータが使える」だけで仕事になったのに、今では表計算/ワープロソフトは最低限使えることが必須となりつつある。
これで「SMTPを全ての人が理解している」状況になったら、そのテの仕事は無くなりはしないけど激減するのだろうなぁ。
#記事は「技術者なら」とのことだろうけど、あの講師は「使うなら」だったからなぁ。。。
#それが本望ならばいいけど、自分で自分の首を絞めている気もする。
##リンク先を読んでたら、同じようなことを叫んでる人が他にもいると知りました。
##あの講師の言動はその受け売りだったのかな
古のSuperASCIIに (スコア:2, 興味深い)
機械語命令まで知る必要はないかなと思いました。
その後SoftwareDesignでPowerアーキテクチャのコンパイル後の逆アセンブル結果を見ながらチューニングする記事があって
機械語で書けなくても流れが読める能力は必要かなと思い改めましたけど。
#でもデバッグは主にprintf
プロセッサの知識 (スコア:2, 参考になる)
組込み分野にいて、ソフトもハードもやってるとプロセッサの知識は役に立つ。
HPCの分野の人なら、キャッシュとか分岐処理とかの知識があれば高速化の手がかりになるだろうし。
でも、大学の情報工学科を出た人ならたいてい、授業でパタヘネ本とか使ってプロセッサや論理回路の
勉強したんじゃないのかなぁ？
特に、論理回路を勉強しないなんてことはないと思うんだけど……
言語の弊害でしょう (スコア:2, 興味深い)
機械語を理解しなきゃいけない高級言語は欠陥言語です。
この前提からすると、プログラマはマシン語を理解する必要はない！
理解しなければならないとすると、使ってる言語が悪い
8、16bit機のCP/M、DOS時代を懐かしんで (スコア:2, おもしろおかしい)
不快な他人のコードは1bitたりとも走らない。
メモリを蹂躙し、デバイスをひれ伏させる。
マシンのすべては我が物だ。すべてが我が掌に乗っている。
そのとき、僕は神になる。
社会学をやるのに量子力学を修得する必要はない (スコア:2, すばらしい洞察)
化学を知らなければ生物学ができない、なんてことはない。
生物学を知らなければ社会学ができない、なんてことはない。
量子力学を修めて社会学者として成功した人なんていないだろう。
Java、PHP、Rubyなど最近のプログラミング言語を使うときは、マシン語（量子力学）よりもオブジェクト指向やデザインパターン（社会学）の方がよっぽど重要になって来ている。マシン語に拘っている人は、得てして「木を見て森を見ず」になっていることが多いように見える。
Re:社会学をやるのに量子力学を修得する必要はない (スコア:2, おもしろおかしい)
哲学は、実際には心理学である。
心理学は、実際には生物学である。
生物学は、実際には化学である。
化学は、実際には物理学である。
物理学は、実際には数学である。
数学とは……哲学そのものである。
x86 は筋が悪いしなぁ、、、 (スコア:2, 興味深い)
積極的に手を出す動機付けも多分にあったけど、
今じゃ Kernel, boot loader, compiler を作る以外では
そうそう必要にはならないはず、、、
下手に使っても、ポータビリティは落ちるし、
最適化コンパイラじゃないとまともなパフォーマンスも得られんしで、
68 から移行した時に、もう必要ないや、、、って捨てちゃった、、、
そもそもマシン語とは言え、
所詮は数ある命令セット(つまりはプログラミング言語)の1つに過ぎないわけで、
どうせ覚えるんなら、
OOPとか、AOPとか、λとか、etc, etc,,,
優先して覚えた方がメリットが大きいものは他にいくらでもあるだろう。
# つまり、アセンブラ修得の優先順位は相対的にかなり低い、、、
多分、元記事の主旨は、
プログラムカウンタやスタックなんかのイメージを持つべきって意味だろうけど、
それは無理にアーキテクチャを特定したアセンブラである必要はない。
# あくまで概念だけでも十分、、、
# どうせ変数がレジスタと同じ数しか定義できん C みたいなもんだから、、、
しかも今日日の一般的なプログラマって、
インタプリタ系の言語使ってる割合がかなり増えてるわけで、
唯一メリットになりそうなデバックの効率化という理由でも覚えるメリットは少ないだろう。
uxi
C/C++使いなら (スコア:2, 参考になる)
少なくともエンジニアなら「何故?」と疑問に思えば追求するでしょう?
例えば__stdcall, __cdecl, __thiscallが絡んだエラーや、printfの可変引数のからくりは
アセンブラがわからないとわかりづらい。
最近質問されたものだと、Callback用メソッドには何故staticを付けるのかというのがあった。
それでstaticを付けない形のCallbackの記述法を示してメソッド名を書いて呼び出す際と関数
ポインタの場合とでアセンブラレベルでどういった差が出てくるのか、thisポインタがどのよう
に処理されるのか説明したんだけど、何らかのアセンブリ言語の知識が皆無の相手へ説明して納
得してもらうのは難しいと思う。
でもブラックボックス的に納得して先に進むのもありだし、「理解しておくべき」じゃないね。
要は引き出しの事でしょう。 (スコア:2, 興味深い)
自分の恩師が以前こんな事を言っていました。
先生「今、メモリがすごい安くなっているでしょう？」
当時６４Mでひーこらマシンを動かしていた自分には衝撃的な話でした。自分「そうですね。１２８で1万円切っていますからね」
先生「その内、２５６や５１２で１万を切る時代が来ると思うんだよ。その時はメモリを効率的に使うプログラムよりもメモリを無駄に使って高度な事をする技術が広がっていくようになると思うんだ」
自分「メモリって大切じゃないですから。ちゃんとリソースを使い切らないように管理しないと」
先生「でも、別に管理しなくても回収できるような仕組みが出来たらそれも考える必要がなくなるんじゃないかな。むしろ、そういう 『無駄遣いする技術』って今後増えてくるような気がするなぁ」
んで、実際今になってまさにメモリを無駄遣い（してるよーにしか見えない）OSでメモリを無駄遣いする言語（所謂Script言語）を使ってゴリゴリ面白いコードを書いています。
先生の予言というか、予見はまさに的中。
詰まる所、必要とされる技術は状況や時代によって変わる訳でして、「マシン語」が「絶対」なんて事はないんです。
少なくとも開発効率という点を考えるならばらマシン語より遙かに効率の良いプログラム言語なんていっぱいある訳ですよ。
どうしてもスピードを重視しなければいけないような仕事（組込系とか？）をする時に、マシン語という引き出しを持っているならば有利に仕事を進めることが出来ると思います。
今後、今回のタレコミにあった「マシン語」には「C言語」「Java」「Perl」「PHP」「Ruby」「JavaScript」「オブジェクト指向」「デザインパターン」なーんて言葉が入るようになるんじゃないかなぁ。
それだけ引き出しとなる物が増えたことにもう少し喜ぶべきでは？
それが正しいかどうかわからない人は (スコア:2, すばらしい洞察)
そうすれば、言っていることが正しいのか間違っているのか自ずとわかると思います。
理解していない人には解らないでしょう。
わからなくていい人は、そもそも関係ないので、議論に参加する必要もないと思います。
知らないより知っている方がいい (スコア:2, 興味深い)
知っている人はそれができる（可能性がある）。
ただそれだけ。
でもそれがでかいんだよな。
-----------
くるみ「学校で習ったことなんて社会に行ってから役に立たないってお父さんが言ってたよ～」
ベッキー「教育を役立てられなかった負け犬の家庭か」
Re:当然である (スコア:4, 参考になる)
SEは、顧客とのコミュニケーション力と
技術に支えられた交渉力の必要な職業ではないかと考えています。
もし、楽だと考えているなら、余程ひどい仕事っぷりかと。
# あとね、プログラム書きたいのに書けなくなるんですよ？
# ひどいじゃないですか！
Re:当然である (スコア:3, おもしろおかしい)
# 計算機の方が楽なぐらい、無能な人間もいます。
Re:当然である (スコア:2, 興味深い)
Re:当然である (スコア:3, おもしろおかしい)
ってな感じでしょうか．by FF
最終レベルは７だそうです (スコア:2, 参考になる)
どういうわけか、コの業界ではレベル１，２であっても
いきなり最終レベルであるレベル７に到達することもあるそうです(笑)。
clausemitz
Re:個人的な話ですが (スコア:2, すばらしい洞察)
HTTPを読めないでWebアプリ作ろうって方が、よっぽど怖い・・・しかしおおいんだな、これが。
-- gonta --
"May Macintosh be with you"
Re:下層レイヤを知ってれば有利だよって事？ (スコア:4, 参考になる)
元記事には、マシン語の知識が無いとPHPやJavaScriptで遅くなってしまった時にピンとこない、というような事がかかれてますが、ではマシン語の知識があればPHPやJavaScriptで速いコードが書けるのかというと、一概にそうとも言えないでしょう。PHPやJavaScriptのエンジンがどのように動いているかという事を理解しているほうがむしろ高速化に役立つような気がします。
例えばPHPでのリファレンス、関数との間のやりとりを値でやるかリファレンスでやるか、マシン語の知識があると「リファレンスのほうが速そうだな」と思ってしまう。でもマニュアルにはそれを察してか、リファレンスでの返しの部分に、「パフォーマンス向上の目的でこれを使うな、そんな事しなくてもPHPエンジンが最適化してくれる」と書かれるんですよね。
余談ですが、じゃ、最終的なのまマシン語なのかというと、今では確かにそうかもしれないけど、ハンドアセンブルしていた頃はそうでもなかったんですよね。どの命令が具体的にどのような処理をするか（何クロック必要か）を知っていると、速いコードが書けたわけです。特にZ80で拡張された命令はどれが速くてどれが遅いかとか…。
まぁ、理想論から言えば、下層レイヤは意識する必要が無ければ無いにこしたことはないでしょう。それが各層での技術の見せどころでしょうかね。
Re:でっていう (スコア:3, すばらしい洞察)
公理系からすべての定理を証明できる、というのを理解しているのと、公理系を理解せずに定理のみでさらに高級な定理を証明しよう、というのの差かな。
別にすべての(つまり、難解な定理も含んだ)定理を公理系のみから証明してみせる必要は無くって、それが可能だということを知っていることと、簡単な定理を実際に公理系のみから証明する経験を積んでおく、というのが重要だと言っているのでしょう。これは、数学の専門家なら当然やっていることだよね。
ただ、数学はスペシャリストのみが必要な理論の世界で、プログラミングは実業だからねえ。公理・原理を理解しないレベルの低い(高級言語しか理解しない)プログラマもコストとの見合いで必要だったりする。そういうプログラマも生きていく道があるんだから、それはそれでいいのかも知れない。