プログラミングしているときの思考ついて話そうぜ
■ このスレッドは過去ログ倉庫に格納されています
俺たちはプログラミングしてるとき
どこまで自分で「論理的に考えて」
どこまでをコピペやおまじないイディオムやパターンを「信じて」
使っているのだろうか。
自分の頭で論理的に組み立ててることを認知科学の分野で「アルゴリズム」
という。
これはコンピュータのアルゴリズムとは別に、「人間の頭の中で組みたてられる
アルゴリズム」という意味。「演繹」といってもいいだろう。
すべてアルゴリズム的にプログラミングを考えるのは無理だ。
すべての命令名をCPUの0と1の処理に変換してアセンブリレベルとかで
プログラム考えてるやつはまずほとんどいない。
一方「何らかの名前」を信じて「そういうものだ」として使うことを
「ヒューリスティクス」という。「帰納」に近いものの考え方だ。
大量にコードを書くときは人間はヒューリスティクスに頼らざるを得ない。
ヒューリスティクスの究極系が「丸コピペ」だ。
ただし丸コピペすると「勘違い」が発生して目標が達成できないことが多い。 この2つの思考方法をどう配分すれば適切なんだろうか？
例えば「System.out.println();」はかなり「信じられる」メソッドだろう。
おれはJavaの「System.out.println()」以外の「System」クラスの
他の機能はあまり使わないし、「System.out」以外に「System」が「out」
以外のオブジェクトを持っていることを知らない。
どうように「System.out」のメソッドの内、「.println()」か
「.print()」メソッドぐらいしかほぼ使わないし、ほかにどんな
メソッドがあるかも知らない。
しかし「System.out.println();」という「一連の名前」だけ
つまみ食いで覚えて(ほかのオブジェクトやメソッドを網羅的に覚えずに)
使っている。
ただ言語のリファレンスドキュメントを調べる場合「網羅的に」
説明が載っているから「どれだけつまみ食いで覚えればいいのか」が
迷うことがある。
結局手探りで、いろんなコードをコピペして試しに使ってみて、
「使えたもの」だけ覚えていく感じで、プログラミングを覚えていく。
でもそれでは困るときがある。
それは「高度な設計上の技術」を学ぶ時で、
「あと後になってからそのメリットがわかる」タイプの技法は
その場で「使えた感」が得られないとき。
「おまじない系」「読み込み系」も「なぜそれが必要なのか」と悩む。
例えば「#include<stdio.h>」とか
「public static void main(String[] args){} 」は最初
「そういうものだ」と受け入れるしかないだろう。
「読み込み」は「それ自身で何か実行している」訳じゃないが、
「間接的に何かの実行の前提」となっているから厄介だと思う。
あと「例外処理」みたいな「何かあった時の予防処理」も覚えるの
が大変だと思う。何か「実行できた感」が得られないから。 >>1-2みたいな糞スレ立てるバカはいなくならねーかなと思いながらプログラム書いてます 哲学やると脳が腐るからな可哀そうに
プログラミングが彼の病気を癒してくれるといいが だいたい世代でどこまでのレイヤーを理解してるか違うよな
最近の子はフレームワークから上
その前は素の言語
そして年寄りになるほど
ビット
ハードウェア
分子レベルの理解になっていく よく分かんないけど理想的なオブジェクト志向ではヒューリティクスとやらは存在しないんじゃないの？
例えば何か画面に表示したいときはOSに属してる標準出力に文字列を送るわけだからOSに相当するSystemっていうクラスの標準出力に相当するoutのメソッドにありそうって推理できるわけじゃん？
んでもってリファレンスで相当のメソッドを調べて書くわけじゃん
どっちかっていうとクラス設計のときの思考について考えたほうが有意義だと思う >>7
それは「名前」を手掛かりにそう「推測」しているだけであって
厳密な論理レベルで確証を得ているのとは違う。
「OS」が「Operating System」だと推測する人が多いと思うが、
「名付けた人の意図」が「Ossan Surume」の略だったらどうする?
「System」とは何のことを指している？
どこかに推測を入れないと読めないだろ。
「名づけた人の意図」と「使う人のが推測した意図」がずれていたら・・？
もし推測が勘違いだったらそのメソッドは「作者の意図通りに」
使えないかもしれない。 >>8
人間厳密な論理で物事を考えていくなんて無理だぞ
そもそもドキュメントが文章になってる時点である程度の曖昧さは残るわけで
だからこそ利用者が困惑しないようにデザインパターンとかある程度のお約束が用意されてるわけだよ
人間が文章読むときだっていちいち文法レベルで理解しながら読んでないだろ >>9
ではレビューなんかで他人のソースを見て「よい/わるい」
「これじゃバグになる(なりそう)」
「きれい/汚い」これはどう判断している？
感情か...? 論理的に説明できないとしたら
なにを以てそう直感するんだろうか？？
「自分が良いと思っているお約束と違う」だろうか。
「長い」「くどい」だろうか。 リファレンス読むだけじゃなくガイドも読めよ。
目的に応じた適切な使い方、たいてい書いてあるぞ。 「プログラミングしているときの死相について話そうぜ。」
「マ板でやれ。」 天から降りてきて
ピーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
ーーーーーーーーーーーーーーーーー
ｼｯｶﾘｼﾛ!( ‘д‘⊂彡☆))Д´) ﾊﾟｰﾝ
( ﾟдﾟ)ﾊｯ! プログラムの読んだり書いたりする順序っていつもどうしてる？
読む順序はよく言われるのは「ネストの一番深いところから読む」
のが効率がいいって聞くからそうしてるんだけど
つまり「一番最初の }」が出てくるまで読み飛ばして、
「}」が出てきたところから「内側 -> 外側」にさかのぼって処理を
読んいく。
全然関係ないけど「カレー作る順序」ってどうしてる？
「皮をむいてから切る」のと「切ってから皮をむく」なら
「皮をむいてから切る」ほうが正解だよな。
「ニンジンの皮をむいてから」「ジャガイモの皮をむいて」
「ニンジンを切って」「ジャガイモを切る」ほうがいいか
「ニンジンの皮をむいて切って」
「ジャガイモの皮をむいて切る」ほうがいいのかは
前者のほうがいい気がするなニンジンもジャガイモも
複数あって処理が似ている。
ニンジンもジャガイモもあとでまぜる訳だから混ざっても困らない。
でももしこれらが「混ざってはいけない」モノだったら
慎重に後者のやり方をするな。 自分は自明な結果を操作してくっつけてから逆算でコード化していく。
1+1=2は多分自明なので2から1+1を想像する。 両方とも皮をむいてから切るんだったら
まな板の上があふれちゃうから
1個ずつ個別に片づけて鍋に入れる >>14
書くときは特に考えることないかな
モジュールに分けて個別に作って繋ぐだけ
読むときが難問なんだけど
まず、大まかな目次を頭の中に作って
どれか一つを開けて見てどの程度信頼できるコード能力の人が書いたかをざっくりと見て…
その出来によって、どれだけコードの記述を信用するか、信用ならないからロジックを追うかを決める
カレーの話はマジレスする気にならんがｗ
玉ねぎを切って炒めてる間に、じゃがいもの皮を剥いてから切って水に晒す、人参の皮を剥いてから切る
理由は、皮を剥いたものを一時領域に置くのが無駄だだし、ニンジンを切る間にジャガイモを水に晒せるから
あと、同じ「切る」だけど、ジャガイモとニンジンでは切る大きさや形が違うから、並べたときに結局別のものと認識して切らなければいけないし プログラムのように未知の課題に取り組む場合に
あんまり効率的に行動しようとしたら頭ごちゃごちゃにならんか？
カレーのその例だけ見ても
玉ねぎ炒めてる間にジャガイモの皮むけとかタイムライン破綻してる気がするが
少なくとも俺は無理だ ■ このスレッドは過去ログ倉庫に格納されています
