いい知り合いさんだと思うのだけどなぁ、な機械です。
> 知り合いに、1回しか呼んでいないのに何でもかんでも外に追い出す
> VBの中の人がいましてね…。
>
> 「何書いてあるんだかわかんねーんだよ」と文句言ったら、「ファンク
> ションとサブプロシージャは違うのじゃ、その違いがわかって言って
> いるか?」と煙に巻かれました。
>
> これ、絶対、煙に巻かれてますよね? 悔しいです。
どんな処理についてそう言われたのかわからないので、はっきりとは言えませんが、
私はPascalで独習してたこともあって、「手続き(プロシージャ)」と「関数(ファン
クション)」は、はっきりと意識して使い分けています。
関数と手続きの違いは、時々「戻り値があるか無いか」の違いだけ、とか言われたり
しますが、実際には「あるコード群」が、「命令(操作?)」に置き換えられるのが「
手続き」、「値(あるいはオブジェクト)」に置き換えられるのが関数です。
手続きは「命令」ですから、コードの中から外の何か(機器や、外部変数など)を操
作するのが目的です。
ですから、例え戻り値があっても、それがその関数の本質でない場合は、手続きと考
えた方がいいでしょう。
たとえば、Cのprintf関数なんかは、成功/失敗の結果が返されますが、分類的には
完全に手続きになります。
それに対し、関数は関数の中でコードが完結しています。
引数が入り口になり、戻り値が出口で、それ以外は原則ありません。
余談ですが、よく手続き型と比較されるオブジェクト指向プログラミング言語ですが、
関数と手続きの分類でいくと、オブジェクト操作はどちらかといえば殆どが手続きです。
> 「万年初心者はなにゆえに万年初心者なのか?」ということの解の
> 1つには、抽象化とかオブジェクト化とかの高尚なお話以前に、
> 「あっちこっち飛んだらわからなくなる」というのが絶対あると
> 思います。
ここでメタファが重要になります。
サブプロシージャはブラックボックス化された手続きですので、「その中身」を考え
ることなく「何が起こるのか」を理解すればいいわけです。
関数も同じく、結果の値(オブジェクト)と置き換えられると考えれば問題ありませ
ん。
まぁ、それでフローが見え難くなるようなコードは、抽象化とは別次元の問題を抱え
ている可能性がありますが(苦笑)
> 特に、if とか whileとかで 「〜である間」と「そうでなくなった時」
> が出てきて急に飛び出して行く場合。
これも、ifブロックやwhileブロックを、一つの塊として見ると、そんなに問題無い
んですけどね。
あと、ファンクション/プロシージャコールの場合は、コメントとか、ちょっと書い
てあると分かり易いですよね。
> で、入門書で、「デバッグの仕方」とか「そのときどんな値が入って
> いるのかを、状況遷移の一段階ずつを追って知る方法」を明示的かつ
> 超重要としてハッキリ書いてくれているものには出会ったことがあり
> ません。
……必要なトコでprintをかませるか、ログに出力させればいいかと思うのですが……
違うんですか?
オブジェクト指向言語であれば、変更のプロシージャに手を加えて、全ての遷移を見
ることが出来ます。
……そういえば、HSPのデバッガって、変数の変更状態、全部出してくれるんですよ
ね(笑)
> バッチのラベルジャンプに対する理解と、if とか whileとかの
> 明示的ループ回し、非明示の暗黙的な } からの飛び出しへの理解
> との間には、深い深い溝があると思います。
???ラベルジャンプは基本的にGOTOですよね。
ダイクストラの構造化プログラミングは勿論ご存知でしょうが、彼の思想は、単に単
純ジャンプを排してコードを見やすくしたのみならず、処理をおおまかなブロックにわ
けて理解しやすくしたり、考え易くしたりする(これを抽象化というなら抽象化です
が……)ことにも重点が置かれていた筈です。
デバッグでは勿論、変数の遷移を追って行くのは時には必要でしょうが、コードが何
を目的とし、そしてその目的の通りに書かれているかをチェックするほうが、多分わか
りやすいと思います。
……まぁ、プロでない素人の戯言ですから、聞き流してください。