orange @[email protected]

難しい＞＜；

設計するって立場になるのは、『漠然と神様がしてたと思ってた事』(比喩)をする立場になること、つまり、神様のようなものになることとも言えるかも＞＜
色々なルールを自分で決められるし自分で決めないといけないし、そして(広義の)ユーザーが満足出来る用にそれを行わなければいけない＞＜

でもその先にスタティックなライブラリがあったり、さらにその先にCPUの命令があったりするわけじゃん？＞＜
そういう構造を思い浮かべられるようにする事も大切かも＞＜
CPUだって、そりゃ現在のPCで使われてる水準の物はゼロから一人で作るのは不可能だけど、古典的なものは一人でも作れるし、ロジックゲートだってトランジスタとかで作れるし、なんだったらリレーを手作りしてもよい＞＜

メンタルモデルの話だから違うかも＞＜
オレンジの「神様ではなく」の意図は、単に自分でも「追加できる」では無くて、「あなたはここまで部品を作ってきた人と同等の立場であり、その気になれば最初からすべてを作りなおす事が出来る」というメンタルモデルの形成＞＜
神様でも超人でもないよって事＞＜(超人並みの人が携わってる事は多いけど、少なくともオリンピックで金メダルをとる立場よりは容易に出来ること＞＜)

それは完全にそうなので、ごくごく初期にScratch使うとかもオレンジはいいかもって思ってるし、あくまで練習用と断った上でなら優しい入門向け言語(それこそBASICでも)を最初の1時間に使うのもいいと思ってる＞＜

「『includeの中身は神様が作ったわけじゃなく誰かが作ったんだよ＞＜』って事を教えられずに理解というかメンタルモデルを形成するの大変だよね＞＜」
って言いたい＞＜

「なんで文字を表示する時にprintとかなの？」に対して、
「そういうもの」で通すか「文字を表示する部品を作った人がprintとかの名前で作ったからだよ＞＜」って説明するか＞＜
プログラミング経験がない人がプログラミングする時に「なんでもいい、自分で決めなさい。ただし、他の人にもわかりやすいように作りなさい」って事を理解するのってすごく大変だと思うし
「部品の仕様は部品を作った人がそう決めたからそうなった＞＜」って知るのはプログラマになるために必要なメンタルモデル形成への有用な近道だと思うかも＞＜

「部品を読み込んでる」って最初から教えるのが重要なのは、実際にどういう動作をしているかだけではなく
「あなたはこれから何らかの『ルール』に従ってコーディングする事になるが、その『ルール』は言語仕様のみではなく、誰かが作った部品の仕様でもあり、そしてあなたがこれからする事のひとつは『新たにルールを作り出すこと』でもある＞＜」
って事、つまり「あなたはエンドユーザーでは無く設計する立場になる＞＜」って事を教えるのに重要だと、オレンジは考えるかも＞＜

includeをおまじないって教えるのが最悪なのは昔から言われてる通りにその通りだとオレンジも思うけど、オレンジ流では「既に誰かが書いてくれた部品を読み込んでって文だよ！＞＜ こういう風にあなたも部品を書けば誰かが便利に使えるんだよ＞＜」って最初から教えるかも＞＜

こういうのでも、いま話題のJavaの簡素化mainやC# のなんかいきなり書くやつでもそうだけど、「あくまで練習環境です」って徹底しながら教えないと、むしろ後で「関数の前のstaticって文字列って何？」とかの段階で大混乱すると思うんだけど＞＜

先入観って言うと悪いものっぽさがあるし、先入観で失敗した事例は人類史に大量にありまくりだけど、一方で同じものを「まず考えてみる」という言葉にに置き換えると、考え無しに動いて失敗した事例もまた人類史に大量にありまくる＞＜