プログラマー脳 ⑥ Chapter 6 プログラミングに関する問題をよりうまく解決するには / Chapter 7 誤認識：思考に潜むバグ
まずは昨日読んだ内容を思い出したい。
《変数の役割 11》
良い感じ。
起きる前、寝床で試してみたところ、最初は苦戦した
ギャザラー、フラグ、temp, MOR, MWV が思い出しにくかった
Anki に入れてしまおう。
また、ChatGPT に頼んで、mnemonic を作って貰おう。
→ 作ってくれたものが微妙だったので mnemonic 作戦はギブアップ
ただ、これらは無事に覚えられて嬉しいが、Kindle みたいなワードが頭から抜けがちなのはヤバいし悲しい。
ほら、また、「メタベース」が思い出せなかった。
…えっ、metabase、オープンソースなの！？
「メタベース」を覚えるためにググったら発覚した衝撃の事実。
あと、昨日の内容に「構造の理解と計画の理解」があったことが思い出せなかった。
Chapter 6 プログラミングに関する問題をよりうまく解決するには
《本書の内容》
- プログラム上の問題を効果的に推論するためのモデルを適用する
- 問題に対する様々な考え方が、問題解決の方法にも影響を与えることを理解する
- コードについて考え、より効果的に問題を解決するためのモデルの活用方法を探る
- 長期記憶の能力を向上させることで問題を解決する新しい方法を学習するテクニックを試す
- ワーキングメモリの活用方法を工夫することで問題を解決するモデルを利用する方法を学ぶ
- 無関係な内容を省き、重要な内容のみに注目することで、問題を正しく切り分ける
1 つのテーマは「モデル」なのかな？
昨日、自分は文章の読解時に「スキャン」を行わないという反省を得たばかりだったので、少なくとも今日は（できれば続けたい）、スキャンから始めてみよう。
「本章のまとめ」を覗いたところ、「メンタルモデル」や「想定マシン」といった新ワードが登場している。
「メンタルモデル」はまずまずイメージがつくけど、「想定マシン」はよく分からない。
英語では "Notional machine" らしいけれども、全然イメージの助けにならない。
メンタルモデルを使うとき、人は無駄を惜しむようになる。なぜなら、脳は多くのエネルギーを消費するので、人は頭脳労働の量を減らすために筋肉で解決したがるからである。
草。
自分が先週、クリップが極限まで伸縮してしまう不具合を調査した際のやり方もそんな感じだったと思う。
今となっては、ライブラリのコードの中身を見に行くのが正解だとは知っているけれども、デバッグの方法はなかなか分かっていなかった。
- メンタルモデル
- デザインパターン
- これ、なるべく早く自分のものにしたい。ChatGPT にクイズを出して貰ったら良いと思う。これは Observer パターンでしょうか、みたいな。後々、二択にしたり、もっと複雑にしたり。
- デザインパターン
結局、スキャンというよりは、スピーディーに読み通してしまった。 結果として有用だと感じられたのは、上にメモした 2 点のみだった。 でも、見落としがあるかもなので、今から読み直してみる。
「本章の内容」一つの
長期記憶の能力を向上させることで問題を解決する新しい方法を学習するテクニックを試す
というもの、興味深いけど、読み通して思い当たるものがなかったような…
デザインパターンがそれに該当するのか？
あと、「想定マシン」については、メンタルモデルのうちの、PC の働きを表すものだと理解。
6.1 コードについて考えるためにモデルを利用する
6.1.1 モデルを利用することの利点
- 利点
- その時に必要な情報のみにフォーカスできるよう、余分な部分を見えなくしてくれる
- コードのアーキテクチャ図や、値の遷移図なども、モデル。
- 「列車の間を往復する鳥」問題にて、鳥の軌跡をモデル化するかどうかによって複雑さが大きく異なるのと同様に、何でもモデル化すれば良いという訳ではない
6.2 メンタルモデル
状態表やグラフなどもモデルであるが、このようなものは、手を動かして作成する必要がある。
それに対し、そのような作業を必要としないモデルが存在し、それをメンタルモデルという。
例えば、木構造というメンタルモデルのおかげで、「ある要素を参照している要素」と表現せずに「あるノードの子ノード」と表現できる。
フォルダとファイルの関係も、メンタルモデル。
また、「コードのこの行が実行されると…」という場合も、実際に実行されるのは対応して生成されたバイトコードであるため、メンタルモデルである。
6.2.1 メンタルモデルを詳しく検討する
- メンタルモデルは、不完全で不安定
6.2.2 新しいメンタルモデルを学ぶ
6.2.3 コードについて考えている際にメンタルモデルを効果的に使う方法
読み直しても、やはり、デザインパターンが気になる。
少しでも簡単なものから始めたかったので、Singleton パターンについて調べてみた。
design-patterns-in-ruby/singleton.md at master · davidgf/design-patterns-in-ruby
アプリケーション内で、あるクラスのインスタンスが1つしか生成されないようにするものなのか。
自分が開発しているコードでは、Singleton モジュールは利用されていない様子。
6.3 想定マシン
想定マシンは、特定のプログラミング言語の実行に関係する機能を正しく抽象化したもの。
メンタルモデルとは異なり、それぞれが完全であり、お互いで矛盾しない。
6.3.1 想定マシンとは何か
6.3.2 想定マシンの実例
6.3.3 さまざまなレベルの想定マシン
6.4 想定マシンと言葉
なるほど、return / 返す というのは、「関数がスタックに値を積み、呼び出し元（この考え方もメンタルモデル）がその値を使えるようにすること」か。
6.4.1 想定マシンの拡張
6.4.2 想定マシン同士がメンタルモデルを作り出す場合
6.5 想定マシンとスキーマ
6.5.1 なぜスキーマが重要なのか
6.5.2 想定マシンは意味論的なものか
Chapter 7 誤認識：思考に潜むバグ
本章では、バグに焦点を当てる。
7.1 2つ目のプログライング言語を学ぶのは、最初の言語を学ぶよりも、なぜ簡単なのか
- 何かの知識が別の領域で役に立つことを 転移 という
- 新しい情報を既知の情報と関連付けることを 精緻化 という
7.1.1 既知のプログラミングに関する知識を最大限活用する方法
- 既存の知識と新情報との関連性を自発的に意識することが重要らしい
7.1.2 転移の種類
- 意識することなく実行できるスキルの伝達 → 一般道の転移 (Low Road Transfer)
意識して獲得するような複雑なタスクの転移 → 高速道路の転移 (High road Transfer)
近転移
- 遠転移
7.1.3 すでに持っている知識は呪いか幸いか
- 正の転移
- 負の転移
- BASIC を学ぶと他の言語で負の転移が起きやすい様子
7.1.4 転移の難しさ
- チェスの優秀さが他の知的分野の優秀さに繋がったりはしないことが研究で知られている
7.2 誤認識：思考の中のバグ
7.2.1 概念変化で誤認識をデバッグする
- 誤認識を解くには、多くの場合は間違いを指摘するだけでは不十分で、誤った考え方を新しい考え方に置き換える必要がある
- どこかで学んだ「誤って覚えた後に正しい内容を覚えなおした方が定着が強固になる」という説とは逆だ
7.2.2 誤認識の抑制
7.2.3 プログライング言語に関する誤認識
7.2.4 新しいプログラミング言語を学習する際の誤認識を防ぐ
7.2.5 新コードを読む際の誤認識を診断する
学びの少ない章だった
