それはそうだと思うけど＞＜ でも、うまく説明できないけど用意した土台にくっつく瞬間の部分？＞＜みたいなのは、初心者だからこそ提示してても気づけない可能性が高いし、さっきの「加算命令というものが！＞＜」みたいな風に教えてあげないと、通過（？）しちゃうかも＞＜
orange
さんがブースト
無論、現実に高度な問題を考えるうえでその壁というか限度が見えないということもままあるでしょうけど、それは初心者に教える例として使える難易度の問題ではないというだけで、選択のミスではと
orange
さんがブースト
そういう、「これ以上掘り下げる必要はありません」という壁のようなものは、設計そのもの(いわゆる「答え」)を直接には記述しないわけで、これが事前に提示される必要があるのではと考えます
orange
さんがブースト
条件が足りないと「足し算をする必要があります→まず AND と XOR を作ります」みたいな分割までやらないといけない(それをやる直前まで「ここで終わり」と気付けない)かもしれないわけで、「ここまでいけば十分であろう」というのを設計者自身に自覚してもらう/見通してもらうためには「足し算できる機械が最初から用意してあります」という前提条件が必須だと思うわけです
ていうかプログラミングって設計だよね！＞＜ 設計できないとオリジナルのコードは全く書けなくて当然だよね！＞＜って話に、
個別のアルゴリズムを予め教えてっても、アルゴリズム自体を「自分で考えながら学ぶ」んじゃなく、答えを教えられておぼえるみたいになっちゃうよね？＞＜
なぜならば、プログラミングに於いての「自分で考える方法（＝設計の考え方）」を学んでないんだから？＞＜
難しい＞＜；
orange
さんがブースト
既成の部分が使えるかを知るためには「これはこう使える」みたいな用法まで含めた部分がわかっていないといけないわけで、それって最初に教えるべき部分ではなくて、「問題を(設定された粒度まで)分解できる人が、部分的に未分割な問題とうまく付き合う方法」という、言ってみればステップアップ後の段階なのではと思いました
ていうかそんな事言ったら何らかの課題で教える時に正解を丸ごと教えないとケチみたいな話になっちゃう＞＜ それじゃ何も設計は出来ない＞＜
orange
さんがブースト
そういう条件自体を見つけるのも設計だよ！＞＜； 設計って設計開始時点では無いものを考える作業だよ＞＜；（じゃなきゃただのコピーだよ！＞＜；）
でもある程度以上大きなものの設計って基本的にそういうものかも＞＜（自動車を作ろうって考えたら、部品で買える所までは辿らないといけないし、既製の部品で納得がいかなければ最後は「鉄鉱石ってどうやって掘るんだろ？＞＜」とかなりかねないし、そういう意味では元々きりが無い＞＜）
orange
さんがブースト
たとえばなんか巨大な整数を与えられて「さあ分解してみましょう」と言われたとして、それをなんだかよくわからないけど延々と分解していって、いつか「おっ、それは既にありますね！やった！」と言われるまで延々とポチポチして分解しつづけるみたいな終わりのないジョブ、私にはちょっと耐えられないです
さっきも書いたけど、ほぼ全ての人にものすごく嫌がられるけど、でもかなり有用＞＜；
orange
さんがブースト
それ私が嫌いなタイプのやつだ……完全に個人的嗜好の問題っぽい
例えば部品に辿って考えていって教えられてる人が「じゃあ、これとこれを足せばいいって事？」ってなったとして
「足せばいい！？＞＜ なんとここに便利な加算命令というものが！！！＞＜」
「マジで！！！！？」
みたいな＞＜
うん＞＜； なのでまず「設計とはどういうものか？＞＜」という概念を先に教えないと無理だよ！＞＜；って話をしてるし、具体例としては1対1で気づかせるって方法の話をしてた＞＜；
orange
さんがブースト
あれ？いま初学者に教える話だった気がしましたが
完成品から部品にたどって必要なものを考えていって、その必要なものが「そういえばそれ、完成品で既にあるかも！＞＜」ってなったらそれを使えばいいし、そこが底かも＞＜（駄洒落かも＞＜）
orange
さんがブースト
たとえば求める条件の記述が、状況によって「カードが昇順に整列されている」で十分なこともあれば、整列や大小関係とはどういうことなのか記述する必要もあるかもしれないし、そういった「設計をこれでよしとする(メタな)条件」が明示されてほしいという感じだろうか
- ＠orange_in_space
2017年 4月に登録
