制御指向じゃなくデータ指向で行こう。

朝一で着ても暖かい研究室、ありがとう沢山のPCさんたち。

昨日書いてたエントリの補足。

「処理はちゃんとやろうぜ」って書いてたけど、何か違和感あると思ったら

for(i=0;i<YOUSOSUU;i++){
youso = hairetsu[i];
}

な、インデックスによる要素アクセスをしてなかったからだ。 イテレートいくない、とか言いながら自分でやってるじゃねぇか

後、変数への代入てのは、データの流れから見るとGOTOみたいなもんかねぇ やっぱ、なんか、うまくないよね。

うーん。 「フローチャートなんてゴミ」ってんで 「もうそんなものやってませんよ、あんなのは役に立たないじゃないですか」 みたいな話は割と多いような気がするけど 「プログラミングの基本は制御構造ですよねー、if, for, whileからやりましょうね」 てのは、結局フローチャートじゃね? 落書きしなくなっただけで

いや、制御構造は大事だけど、絵は要らない。っていう単純な話ならいいんだけど 制御構造よりもデータ構造の方が重要で、制御構造なんかやらんでもいい っていうような気もするんだよね やらんでもいい、は言い過ぎだけど

簡単なプログラムなら、上から下に流れるように(戻らずに)書ける人は多いだろう # 別に catで書くって意味じゃない

どうしてそういう風に書けるかっていうと 「頭の中にバッファがあって、そこで書いてからエディタに入力するから」 ではない 少なくとも俺はそんな書きかたしてない。

「必要なデータ構造を考えて、それを処理していく」っていう風に書いてるから 大抵の言語では上から下の順番で書ける。

データ構造が主で、制御構造はそれを処理する為の従だ。

これがひっくり返って 「これをああいう風に処理すれば出来るから、えーとこの変数とこの変数が必要でー」 ってなっちゃうと、コード書いては戻って変数作っての繰り返しになる。

制御構造がさらっと書けるのは大事かもしれないけど データ構造を理解する前に制御構造ばかりやると ダメなやり方で解決するクセが付いちゃうような気がするなー ifとforで何でも出来るじゃん、みたいな間違った方向で

もう、いっその事 HaskellやろうぜHaskell 流行ったので(もうブーム去った感があるよね)あちこちのBlogにHaskellの話が書いてたんだけど 躓いてる人多すぎ Javaが出てきたときも、躓いた人多すぎ(こっちは現在進行形か)

データ構造を理解してコード書いてりゃ、Haskellだってサクッと書けるし 構造化プログラミングが出来てりゃ、オブジェクト指向だってサラッと移行出来るはず

要するに「新しい(※)ものが分かんない」のではなくて「古いものがちゃんと分かってない」んだよね # 歴史的にじゃなく、俺的に、お前的に

まぁ、それは別に悪い事じゃないんだけど。 最初の1個の時は古いものの概念すらないわけだし じゃあ、何が悪いかというと 古い物を理解したつもりになって、間違った方法で新しい物に取り組むからだ。 本質は何にでも通じるけど、誤魔化しはそうじゃない。

なんつーの「親子丼作るの難しいなぁ。あ、電子レンジで出来るじゃん。」 なヤツが、カツ丼も電子レンジで作ろうとして 「あれぇ、どうしても上手くいかないなぁ...orz」な感じ。

いやいやいや、それ間違った方法だから。 で、本人は"その方法が間違っているという事に気付かない"ので、挫折する。 方法が間違ってる事に気付けば、方法を直せば良いんだけど、それが出来ない。

逆に、鍋で親子丼作れるやつは 「カツ丼? 作った事無いけど多分作れる。カツ煮りゃいいんだろ」 と、一見なめた様な事抜かして、でもちゃんと作れる。

何も出来ない奴には 「いいかッ料理は鍋で作るもんだ。電子レンジは大人になってからッ」 って言っとけ レンジで10種類の料理が作れるよりは、鍋で1つをちゃんと作れた方がいい。

料理の話を続けると、制御構造指向なコードってのは、技法指向だ。煮込むとか炒めるとか データ構造指向なのは、材料指向。肉とか卵とか野菜とか肉とか肉とか肉とか。

入門書のサンプルコードがつまんないのは、多分技法解説の料理本見ても食欲わかないのと同じ理由 いや、入門でいきなり難しいものは作れないからしょうがないんだけどさ

関数型言語の書き方って、料理のレシピに似てるよね。 Aの材料を混ぜ合わせてタネを作り、焼いて、Bの材料を混ぜて作ったソースをかける。 みたいな、Makefileの依存関係とかもそんな感じ。

良く、レシピで唐突に「予め混ぜ合わせたCを~」とか出てくる。 手続き的にやると「Cなんか作ってねえよ、先に言え」ってなるけど 依存関係を予め解決しておけば問題ない。

これはレシピが「どういう操作をして料理を作るか」っていう技法指向じゃなくて 「何を処理して、料理を作るか」っていう材料指向だからだよね。

料理の出来る人は、材料指向で考えて、それを処理するのに手順が出てくるけど レシピ片手に~って人は、手順指向でトレースしようとするから、上手く行かない。 「何をしたか」じゃなくて「物がどうなったか」で考えようぜ、目の前にあるんだから。

味見しない(出来ない)のも、関係あるのかな。 「こういう手順をしたのでなります。」に類似する主張をたまに聞く。 レシピの時間通りにタイマーまで使ってご丁寧に煮るとかね。

料理する人は、手順なんか考えない。 「煮えたかな? 味染みたかな? 焦げてないかな?」っていう風に材料を考える。 タイマーなんか使わない # 経験的に手間を軽減する為に使う事は良くあるだろうけど、絶対的にそれに従うわけじゃない

信用出来るのは目の前のデータだけだし、美味しく頂く(あるいは処分する)のも目の前のデータだ。 弱火とか強火とか、そんなのはどうでも良いのだ。レシピに書いてなくても、材料みて合わせりゃいい。

というわけで、料理の出来ないヤツはプログラミング出来ないとか無理矢理結論付ける。 # 最初の主張はなんだっけ

まぁ、制御構造は出来なきゃいけないし、良く使う道具ではあるけど 思考に使っちゃいかんって話だ。

あー 腹減ってきたな。

あ、そうそう。言っとくけどプログラミング入門俺の担当じゃないから。 担当だったら、もうちょっと現実的な制約の下で考えなきゃならないけど その制約は無いので無責任自由に色々考えてみてる今日この頃。 ブレストん時は制約なんかしちゃダメ、使えなかったら後から捨てりゃいいんだから。

実際には、入門の後に実際に使う事を考えなきゃならないとか 正しい方法だと、表面的な面白みが無くて聞いてる方のやる気が出ないとか # 電子レンジで色々作った方が楽しいじゃん、鍋は後からで良いよ。って意見も1リアル。

まぁー 難しいよね。