プロシン抽象化セッションのまとめ

gistfile1.txt

■未検討の疑問点
・抽象的に考えるにはどのような環境・制約が必要なのか？
・プログラムを書く上でどこまで抽象化するのか？
・抽象化をする上で適切な言語の選択はあるのか？
・OSのような強制的な抽象化とフレームワークのような非強制的な抽象化の共通点は？相違点は？
・抽象化は役に立つのか？何の役に立つのか？
　・抽象化をよくやる人とそうでない人がいると思うが、後者が抽象化するメリットはあるのか？
　　・よくやる人とそうでない人を分けた理由は
　・「抽象化は手段だ」説←何のための手段か？
・日常生活にも抽象化はあるのか？あるなら具体例は？
・抽象化のオーバーヘッドはどこまで削減できるのか？
・プログラムを書く上で抽象化には目的とスコープがあると思う
　・みなさんどうしている？
　　・「どう」って何？
　・スコープとは何？
・抽象化についての共通認識はあるのか？
・抽象化の反対は？
・抽象的と抽象化って似てるようで違うのでは？


■検討した疑問点
・適切な抽象化レベルをどうやって判断するのか
　・いま考えたい対象について
　・そもそも目的に合わせて決めること。
　　・議論をする上でレイヤーを合わせる
　　　・レイヤーとは何？
　　　　・例えばアプリケーションを実装する上で、アセンブラのことを考えない
　　　　・プログラムを書くときにトランジスタのことは考えない
　　　　・NWアプリでアプリ層だけを書きたいなら、それ以外の部分は無視する
　　　　　・アプリだけに集中して書ける環境を作るということ
　　　　　・OSIの7層モデルは抽象化
　　　　・低レイヤを隠蔽するとは限らないのでは？
　　　　　・メソッドやクラスを汎用にするってのは上位を隠蔽してるのに相当する？
　　　　・モジュール化、カプセル化
　　　　・「見ないところ」を決めるもの
    　    ・人間の一度に考えられることには限界があるから
　　・議論は一例にすぎない、プログラミング、ドキュメント書き、考えること
　　・逆にプレゼンなどでは具体的な説明が重要だったりする

・抽象化にはどういうツールがあるか？
　・たとえば抽象データ型
　・関数定義は抽象化だ
　↓
　・いつのタイミングで関数を作る？
　　・最初から作る
　　・似ているものが現れた時
　　　・「似ている」かどうかの閾値はどうやって決めている？
　　・長くなりすぎた時、複雑になりすぎた時
　　　自分の認知能力に対して負担が大きくなった時
　　　・行数、サイズの制約は結構大きい
　　・「ひとかたまりの機能」が見つかった時
　　　・「ひとかたまり」ってどうやって決める？
　　　　・センスが重要、うまい人と下手な人がいますよね
　　　　・一塊を見つける、をグラフの最小カット問題に帰着できる？
　　　　・一塊を見つけるたびに抽象化すると「早すぎる抽象化／早すぎる最適化」に突っ込むのでは？

　　・人に見せる時
　・ボトムアップか？トップダウンか？
　　・中間ぐらいのレベルから上下にせめてく
　↓
　・考えてから実装するか、実装しながら考えるかの違いでは
　・かつて実装しながら考えることができない時代があったはずだが
　　その時はどのタイミングで関数を作っていたのか？
　　・最初から
　　・紙に書いた設計が1枚の紙で収まらなくなった時に別の紙に分けるために
　↓
　・現代のプログラミングには 1:考えてから実装する、2:実装しながら考える、の他に
　　3:仕様を他人に伝えて作らせる、がある
　　・相手と目的によって適切な粒度が異なる

　・モジュールは？
　　・モジュールという言葉があいまい
　　　・Mesaのモジュールは抽象データ型の層があることで
　　　　「何をモジュールの外に見せ、何を見せないか」が定義された
　　　　これは抽象化である
　　　・ただ束ねただけのモジュールは抽象化ではない？
　　　・モジュール化はポータビリティや再利用性を含む概念で、抽象化とは違う
　　　・モジュールの定義次第でモジュール化と抽象化が等価になる

　・変数も抽象化だ
　　・ひとかたまりの概念に名前をつける
　　・具体的な「メモリの番地」を捨てた
　　・「名前をつける」が実は一番大事かも
　　・無名関数を使うぐらいが抽象化ではないか？
　　・数学ではなんで変数にまともな名前を付けないで1文字なんだ？
　　　・意味を持たせたくない
　　　　・物理だと、元の変数名の頭文字をとってるので、意味を保存している？
　　　・複数文字の場合に掛算と認識されるから
　　　・いや、ReやImなどの2文字の名前も存在する
　　・長い名前はわかりやすい・よみやすい
　　・長い名前は抽象化度が低い
　　・（理解しやすさと抽象化の関係についてさらなる検討が

　・モデル化も抽象化だ
　　・目的は制御だ

　・目的達成のためには抽象化だけではなく具象化が必要なケースがあるのでは？
　　・たとえばペルソナ：顧客の具体的なイメージを持つために詳細な設定を作る


・抽象的に考えることはどうやったら習得・教育できるのか？
　・そもそも教えることは可能か？
　　・感性を磨くのか、体で覚えるのか、そもそも答えはあるのか……
　　・材料になる経験を積ませることはできるが、抽象化自体は自分で発見しなければならない
　　・Example Based Programmingと同じ。事例を見せて、そこから共通点を抽出させる。
　　・コンビニでオニギリ買えるのは、相手が「田中さん」「鈴木さん」ではなく「コンビニの店員さん」という抽象化が行われている
　　・無意識のうちに抽象化している、もしくは抽象化されたプロトコルを社会的に獲得している。
　↓
　・学習するための良い問題・悪い問題は？
　　・普通のJavaとAOP、どちらがよい？
　・何歳から教えるべきか？
　　・言語能力との関係。言語を扱う力が十分ついてからにするべき
　・余談
　　・リンゴ1個＋みかん1個は型エラー
　　　・同一視して良いのか？
　　　・ただの決め事ではないのか？


・気持ちいい抽象化では不足である
　・現場から不快に思われるくらいの抽象化が必要
　　・キモチワルイ抽象化＝フレーム破壊レベルまで抽象化している
　　　それくらいまで抽象化しないと新しい価値を出すことが出来ない
　・いや、気持ちいいことは認知能力の向上である
　　・悪いコードのキモチワルサがわかるようになるべき
　・（気持ちよさと抽象化の関係についてさらなる検討が必要）


・抽象と捨象の違いは？
　アブストラクトのアブは離れるだから捨象では
　インダクション デダクション アブダクション の アブ との関係
　帰納と仮説形成は同じことではないのか？


・抽象化とはなにか
　・情報の限定
　　・人間が認知できる量へと限定・圧縮する
　　　人間の弱いところを補うためのもの
　　　・神様の作るプログラムはどんなふうだろう？（人間のDNAとか？）
　　　・人間の記憶できる量が有限だから抽象化して記憶している？
　　・反論：フォーカスするため・性質を見るため
　　　・なぜフォーカスする？
　　　　・数学においての抽象化の例：ルービックキューブを代数的構造に置き換えること
　　・適切なレベルが「問題によって決まっている」「人間によって決まっている」の対決？
　　・「細かいところを見ない」と「特定の性質・共通するものを抜き出す」は違う気がする
　　　・それは「オブジェクト指向」と「アスペクト指向」の違い？
　　　・「共通したものを抜き出す」はモジュール化とは違う気がする
　　・止揚：その両方の意見が、行動としては「見ないところを決める」であり、
　　　　　　メリットが複数ある。どちらを目的とするかが状況によって異なるだけ。
　　・抽象化に対する異なる意見を抽象化することによって共通認識を得るという作業．
　　　・これは「共通部分の抽出」か


・抽象化しすぎて困ったことはあるか？
　・抽象化しすぎたC++のコードが、実装が細分化されすぎて理解できなかった
　　例：　https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition
　・性能追求するなら抽象化するよりは、全部をガリガリにチューニングするほうが多分早い
　　・それは生産性とは両立しない
　・私自身は困ったことがない、そもそも，抽象化しすぎたという経験がない
　　・「抽象化しすぎ」とはどういう状態か？
　　・圏論は抽象化し過ぎの抽象化
　　・圏論は言葉です．
　　・言語化=抽象化
　　・何が目的かによって適切な抽象化レベルが決まるので、
　　　Haskellでアプリを実装する上で圏論まで抽象化することは過剰ってこと
　　・十分に具体的な場合もある、関数の合成とか可換性とか。


・ソフトウェア以外の分野でも抽象化ってあるのかな？
　・製造業だってある。
　　・全体設計して、個別のASSYの設計をTier-1がして、ASSYを形成する部品設計をTire-2がする