漏れのある抽象化の法則

※ クロステックの「抽象化の破れ」の話し(「抽象化のやぶれ」というノーコード/ローコード開発の落とし穴 https://xtech.nikkei.com/atcl/nxt/column/18/00138/010800705/ )を検索してたら、当たった…。

※ 「抽象化の破れ」も、「漏れのある抽象化」も、たぶん同じことを言っているんだろうと、思う…。

※ 非常に参考になったんで、貼っておく…。

『1. 漏れのある抽象化の 法則について

  1. 自己紹介● 名前 – 橘田 隼一● TwitterID – hayabusa333● 興味があること – カーネルとか言語開発とか● 現在のお仕事 – テストプログラマー● 信仰 – Joel教
  2. 漏れのある抽象化の法則
  3. 漏れのある抽象化の法則 ● Joel Spolsky提唱 ● Fog Creek Software 創 業者 ● 人気ブログ Joel on Software
  4. 抽象化一度に注目すべき概念を減らすことおよびその仕組み
  5. TCP/IPIP● 信頼性のない通信方式TCP● 信頼性のある通信方式
  6. TCPはIPの上に実装されている
  7. 信頼性のない通信方式で信頼性のある通信を行う
  8. TCPはIPを使って通信を行っているが詳しいことを 知らなくても通信できる
  9. TCPはIPを使って通信を行っているが詳しいことを 知らなくても通信できる
  10. TCPはIPを抽象化している
  11. しかしLANケーブルが切れていれば繋がらない回線が重ければ、TCPは信頼性を確保できない
  12. 抽象化には漏れがある
  13. これが漏れのある抽象化の法則
  14. 漏れのある抽象化の法則自明でない抽象化はすべて、程度の差こそあれ、漏れがある
  15. 抽象化は失敗する。あるときは小さく、あるときは 大きく、漏れがあるのだ。 物事は悪くなるものだ。この漏れは、抽象化が行われているあらゆる場所で起こる。
  16. Joel の出した例
  17. 大きな二次元配列の要素を順番にたどるという単純な事でも、水平方向か垂直方向かで、「芝目」に依存してパフォーマンス特性が劇的に異なるこ とがある
  18. C言語で記載for(i = 0; i < 30000; i++){ for(j = 0; j < 30000; j++){ array[i][j] = 0; }}for(i = 0; i < 30000; i++){ for(j = 0; j < 30000; j++){ array[j][i] = 1; }}
  19. デモ
  20. この性能差はプログラム言語に よって出たものではなくOSやCPUによって現れたものである
  21. C言語は簡単である。ただしOSの特殊な振る舞い に目をつむれば
  22. OSは簡単である。 OS ただしCPUの特殊な振る舞いに目をつむれば
  23. あなたが日常使うことの90%は 1週間で学習できるが、残りの10%を知るためには2、3年かか るかもしれない
  24. 先ほどの例の理由を知るためには、C言語だけではなく OSの特性、メモリ管理、仮想化、CPUの挙動についても知らない といけない
  25. 漏れのある抽象化の法則にうまく対処する唯一の方法は、その抽象化がどのように機能し、それが何を抽象化している のかを学ぶことだ。
  26. そういうわけで、抽象化は私たちが作業する時間を節約してくれるが、私たちが学ぶ時間までは節約してくれないのだ。
  27. ネットワーク・サーバはプログラム言語で実装されている
  28. プログラムはOSやCPUの上で動いている
  29. 抽象化されている先を 知らなければ 問題は解決できない
  30. 問題を解決できるエンジニアになるためには全てを勉強する必要がある
  31. 我々が目指すエンジニア像は 漏れのある抽象化の法則の漏れを解決できるエンジニアで あるべきである
  32. ぜひ、漏れのある抽象化に だまされないで 漏れを解決できる人に なってほしい
  33. 参考書籍
  34. ご清聴ありがとう ございました』  
  35. ※ こっちも、非常に参考になったんで、貼っておく…。  子どもは何にも知らないの
     https://blog.practical-scheme.net/shiro/20070912-machine-language

『shi3zの日記 – マシン語を知らない子ども達
マシン語読みの言語知らず
アルゴリズムを知らない子ども達
コンパイラの中身を知らない子ども達
オシロスコープを知らない子供たち
元のshi3zさんのエントリが断定調で、一般論と具体論が混ざってることもあって 異論反論パロディが続出したようで。つい黙ってられなくて あちこちにコメントしてしまったけど まとめとく。

解釈が割れた点は:

元の論の対象となる「プログラムが書ける人」は一般の職業プログラマや趣味プログラマまで 含むのか、それとも抽象化の破れにいつも直面してそれを何とかしてしまえるような 一部のタフな人材を指してるのか。
元の論の「マシン語を理解する」は80386アーキテクチャ特有のバッドノウハウまで 理解してばりばりアセンブラを書き下せることを指すのか、それともストアドプログラム アーキテクチャ、MMU、特権命令、割り込み、コンテキストスイッチなどの現代の 代表的なマシンアーキテクチャを理解するということを差し、80386を持ち出したのは 単なる代表例にすぎないのか。
あたりかな。私は両方とも後者と取ったけど、別に解釈すれば異論が出るのがわかる。

ただ、どういう解釈をしても次のような意見が出てくることには首をひねる。

「抽象化はレイヤの積み重ねで、論理回路の下にも半導体があり、電磁気学や 量子力学を知る必要があり、と続いてゆくから程度問題にすぎない。結局「自分は 論理回路から知っているよ」という優越感ゲームにすぎないのでは」

そう思う人にはDaniel HillisのThe Pattern on the Stone (翻訳: 思考する機械 コンピュータ) を勧めとく。翻訳は読んだことが無いが、原書の内容はとても平易なので、 内容だけなら中学生でも理解できるだろう。

第1章は論理回路。第2章で論理演算と状態機械。第3章でプログラミング言語。 第4章でチューリングマシン。第5章でアルゴリズム。以降、暗号や並列計算、 機械学習などを扱う。これを読んだからってプログラムがかけるようにはならないし 紹介された個々の概念を理解したことにはならないけれど、少なくとも現代のコンピュータが どういう概念の積み重ねで出来ているかという構造がわかるようになっている。

で、第1章の論理回路なんだけど、Danny Hillisはここで「スイッチとランプ」 「棒とばね」「パイプと弁」などで論理回路を作って見せる。つまりデバイスが 何であろうと、1と0が表現できてそれを伝達する仕組みさえあれば、残りの全ては その上に構築できるということだ。もちろん物理的に実現可能な規模で現代の CPUを作ろうとしたら半導体以外では非常に困難だろうけれど、今後全く新種の デバイスが出現して物理層がごっそり置き換わったとしても、上の層に 変化はない (ちなみに量子コンピューティングになったらどうなるの、という話は ちゃんと同書の中にも出てくる)。

私は高周波回路も量子力学も苦手だったし、数百MHzのバスクロックに乗るパルスの 波形や数GHzのチップクロックの中を走る電子の雲がどうなってるかなんて 考えたくも無いんだけれど、それらがデジタル回路の抽象化の壁を越えてくる確率と 「高級言語」で書かれたプログラムのSEGVに出会う確率にはあまりに大きな差がある。 抽象化力を指標とすれば、論理回路は非常に強力で成功した抽象化であり、 一方現代の高級言語の多くはまだその域に達していないとも言える。

このような抽象化の壁の厚さの違いに自覚的であることにより、次のようなメリットがある。

学ぶものごとに優先順位をつけられる。たくさんの層があっても、 壁が分厚くなっているいくつかの層を重点的に学べば安定した足場が得られる。
良い抽象化と悪い抽象化の区別がつけられる。自分で抽象化を設計する時に、 自覚的に壁の厚さを選択できる。
抽象化力の違いを無視して相対化してしまう危険は上のメリットの裏返しだ。

あまりにたくさんの層があって全部は学べないから、とりあえず目の前の層を学んどいて、 漏れが出てきたらすぐ下の層、というふうに広げてゆくしかない、と思う。 でも時間に限りがあるから安定した足場までなかなか到達せず、いつも不安を抱えている
自分の設計した抽象化が良いのか悪いのか、判断基準が良くわからない。 また、与えられた問題に必要とされる抽象化の程度を判断できない。
なんだかんだで、ネタにマジレスな野暮だけど、せっかく書いたから貼っておく。

Tags: Programming, Assembly, Hardware』