><https://twitter.com/orange_in_spacehttps://pawoo.net/@orange_in_space
どれぐらいの難易度が適切かどうかはもちろん人によるので、最初から自分で探索してみたいってこと"も"あるだろうけど。
いずれ必要だとしても、最初からハードモードでやらせる必要はあるのだろうか🤔
言っておくだけだと、暗闇を一人で歩かせる事になるでしょ?>< 一緒に歩いた方が助ける事が出来るというか対処を教えられるでしょ?><
或いは、強制と反復によって思考パターンを植え付ける方式に抵抗がある、という感じだろうか?
結局「こう考えれば楽にできるんやで」とだけ言っておけば自然とそれを使うようになるし、敢えて暗闇を歩かせる必要はあるのだろうか、という……?
つまり、壁にぶつかる直前までの方法論を(ちょっとだけ方向を変えて)継続することで進行することができるので
そのときは設計を別経路からやりなおす(バックトラックする)か、壁を乗り越えるサブ問題を設定する(再帰的にやる)べきなのであって、結局その「壁にぶつかってその存在を知る」フェーズは設計の本質を知るのに必要ではないのではと
で、メンタルモデルとしては、「設計できるようになるには、自分で考えるクセをつけるのが大切でしょ!?><」って事で、嫌がられるのが前提で、「じゃあそれをするのはどうやってやればいい?><」って問い詰めていく方法って実際に有用だったかもって言いたい><;
その、調査したつもりの制限という壁に突き進んでいても実際にぶつかるまではなかなか気づけないよ!><みたいな事が言いたい・・・><
であればこそ、方法論の前に十分なメンタルモデルが欲しい、という発想になるわけです(最初の話に戻った)
逆に言えば、「前提となる環境等を十分に調査・把握しないうちから設計をしようとしたって真っ当にできるわけがない」みたいな話になるかな?
「ソートせよ」が存在しないというのは、命令の一覧を眺めることで知ることができるわけで、それは設計という作業を通して知るべき知識ではなくて、設計に先立って把握しているべき条件や知っているべき知識から察せられるべき事柄ですよね
最終的には当然そうなるし、脇道を極めていけば目の前の計算機ではその方法では処理できないので新しく考えた計算機を作るんだけどその為には鉱石を採掘・・・みたいな話にもなるかも><そういう脇道は無限(比喩)にあるし、真に全ての前提条件を記述する事も不可能だし、その部分であっても初学者が理解するのは困難(というか混乱させる)なので、実際にぶつかる場所で「じゃあそれはどうやってやればいいとおもう?><」って聞いて結果的にとめるのも重要かも><(とめなくてもいいけど><)
その「できるのかを知る」は低位のレイヤーにいくとたとえば「コンピュータアーキテクチャを知る」などになるわけで、それは必要な知識かもしれないけど、やりすぎればもはや設計とは別のレイヤーではと思います
例えばすごく第一歩として言うのであれば、CPUの命令表には「ソートせよ」とは書かれてない>< そういう意味での制限><
それは全ての前提条件ではないかも>< 制限としての前提条件のうちのかなり限られた部分集合かも><;オレンジが言いたい事はそういうことじゃなく、それができるのかを知るためには、それをさらに分解して考えていく必要があるみたいな事が言いたい・・・><
たとえば CPU で実行可能なあらゆる命令が列挙されているとして、それはソートアルゴリズムを必然的に記述できるので設計が完了しているとは見做せませんよね
それはバックトラックと再帰的な問題の分割により達成されるものなので、前提条件と無関係では……?そもそも「よく考えたら出来ない」というのがどう判定されるかというと、「操作の最小単位まで分割できなかった」という条件によるわけで、結局最小単位がわかっていないと失敗判定もできないような
前提条件を真に全て細かく出せてしまったら、それはそれ自体が設計かも><(それはつまり前提条件により必然的に決まるので><)
ストレスフルなのもわかるけど、設計って自分が思いついたアイディアが、自分にとって未発見の制限にぶつかって取り下げる事も大きく含まれると思うのでなんとも><; 「あ!><; よく考えたら出来ない!><;」って大切かも>< じゃなきゃ設計にならない><
思考の /dev/null