河野真治 @ 琉球大学情報工学です。

In article <opsmds7eq7e5o5lm@news.media.kyoto-u.ac.jp>, 神戸隆行<kando@nerimadors.or.jp> writes
> 独自仕様が論理学のメジャーな方言のどれかと
> 構造がちゃんと一致して単純な一対一対応がつくような仕様なら
> プログラミングにおける「アダプタ」に当たるものを作るのも
> 簡単な仕事だからコミュニケーション上の問題比較的小さいのですが…。

そう、どうも、問題が大きくなる場合があるんですよね。

      できるはずだと繰り返す(無理だと言っているのに〜)
      バグがあっても、対処法がわからない
      エラーメッセージを無視する

とかって、なんか、もうコミュニケーションできないっていうか...

> でも、論理と集合って互いに相手を記述する道具になるので
> 一方が理解できていればもう一方を理解するのがかなり楽になる関係にあります。
> ワザワザ「勉強したくないよー」って気にならないくらいではないかと。

マニュアル読まないのとねっこは同じなんじゃないかと。

> 論理的な思考ができればヨシという話もありましたが、
> 論理の理解が形式的体系を介さずに日常語だけを媒介にしていると
> 定義の曖昧さや流動性から「アダプタ」を作る難度があがる気がします。

仕様は、特に、論理記述であることが多いんですよね。それが理解
出来ないから、仕様記述ではなくて、実装記述になっちゃう。仕様
記述でアルゴリズムまで指定する羽目になるのは、そういう

     論理的な語彙あるいは構成法を共通に持つフレームが出来てない

からなんじゃないかなぁ。

    for(i=0;i<100;i++) {
        sum = hoge(i);
    }

みたいなものと、

    Σ hoge(i)

みたいなものに、どこに差があるのか?

あるいは、

    public class XMLDocumentProvider extends FileDocumentProvider {
    }

とか書いたときに、

    XMLDocumentProvider は、FileDocumentProvider の持つ性質をすべて含む

みたいなものを理解するためには、∀とか∃とかを理解する必要が
あるんじゃないかってことです。

それ抜きに、モジュールプログラミングとかアイタレータとか使えないと
思う。
    
---
Shinji KONO @ Information Engineering, University of the Ryukyus
河野真治 @ 琉球大学工学部情報工学科