「実際にはこんな難しい処理を書くことはないよね」という中で、こういう問題を解くことにどういう価値があるか。 ぼくの考えでは 計算可能な処理と不可能な処理の性質の違いを実感する 計算可能な処理の場合、どういう処理ならどういうプログラムになるかを実感する というのが大切なんじゃないかと思っています。 同じ問題を解決するのに、プログラムが組めない人ほど難しい処理を書こうとして、プログラムが組める人ほど簡単な処理で解決するという傾向を目にします。技術系MLで非常に高度な処理をしたいという質問を目にすることがありますが、ほとんどの場合は、「こうすればそんな処理必要ないよ」で解決したりしてます。 で、そういうのの原因として「どういう処理がどういう難しさのプログラムになるかアタリがつけれてない」っていうのがあると思うんです。 で、これがシステムの仕様策定のときに深くかかわると思います。 ぼくは、要求を聞
フィジカルって具体的にはなんだろうと考えてみました。 まずは「符号化」能力なのかな？ 与えられた課題をプログラム的に表す力。これができないと処理を組めません。 逆に符号化さえできれば、あとは無理やりでもプログラム組めます。 というか、プログラムは無理やり組んで動かすんです。この「無理やり組んで動かす」能力っていうのもフィジカルですね。「案ずるより産むが易し」っていうのをどれだけ実感したことがあるかという感じでしょうか。 「無理やり組んで動かない」というのは却下で。 人によって、立場によっていろいろな捉え方があると思いますけどね。
3目並べの問題、koichikさんがPrologで作られています。 この例のステキなところは、Javaとかでやる人にコードが全然参考にならないってところですね。Prologのコードを参考にJavaが書けるなら、ある程度のフィジカルありますよ、と。 っていうか，そういうのを鍛えるのがフィジカルトレーニング？ なんだろうな，やっぱり． どっちかというと、こうやってゴリゴリ書ける力が鍛えられればいいなぁと思ったりします。 で、まぁ、koichikさんには物足りなかったようなので コンピュータ同士で対戦するとして、後攻が最初の一手をランダムで指すとき(2手以降はランダムではない)、先攻がある確率*1で勝てるようにせよ とか条件を追加したくなりますが、koichikさんのような手足が充分伸びきった人を対象にしてしまうと問題が難しくなりすぎてしまいますね(^^ 「普通の」言語で対戦できるようにするなら
元ネタは中田英寿がよくいってた 「サッカーはシステムでやるんじゃない。ひとりひとりの選手がやるんだ」 みたいな話なんですけどね。 「1:1で負けていてはシステムは機能しない」とか。 要するに開発を成功させるためにはプロセスをごちゃごちゃいじくるよりプログラマの「フィジカル」の強さを上げることの方が大切なんじゃないかと思うわけです。 アジャイルとかXPとかやわらかいプロセスだと、よりプログラマのフィジカルっていうのが求められると思うんですね。平鍋さんのお話とか聞いてても、同じやり方で成功させるためには「平鍋さんとその仲間たち」レベルの技術者が必要だよなぁとか。 ここでの「フィジカル」っていうのは、デザインパターンとかオブジェクト指向とかリファクタリングとか、そういう「テクニック」ではなくてもっと基本的な力のことで、要するに与えられた処理が間違いなく書けるかどうかっていうことです。 例えばko
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
