スラッシュドット・ジャパン

「UNIXプログラミング環境」って確かガッコの教科書で使ったような...と思って探したら、石田先生が監訳されていたのですね。
あれにはお世話になりました。

石田先生の訳された本には、K&Rや独習C++などでプログラムの基礎を学ばせてもらいました。
心より御礼を申し上げるとともに、ご冥福をお祈りいたします。

考え方の１つにすぎませんが，型宣言でも数式解釈と同様に，両辺の型が釣り合っていると思えばわかりやすいかも知れません．

int *i;

は

int = *i;　（この式はコンパイラに通りませんが概念的なものです）

というように両辺の型が釣り合う関係になっていて，アドレス（ポインタ） i が指す先の値にアクセスする演算子 * を付けたもの (*i) は，int 型でなければなりませんよ，という意味です．コンパイラの視点で言うと，代入式を解釈するときの左右の型の一致判定と同じロジックで変数宣言が出来ることになりますし，変数への演算子の付け方が許容されうる限り，それは変数宣言でも同じように使えることになります．

double (*a)[3];

とかでも同様に，左からでなく，最も内側（変数名の部分）の a から外向きに辿っていけば理解しやすいのではないでしょうか．
「a はポインタで，その指す先は３要素の配列で，その配列の各要素は double 型」であるということになりますから．

そう考えると，

型名 変数名;

という単純なとらえ方だけでなく，変数名を修飾することが変数宣言でなぜ利用できるのかが理解しやすいかも知れません．
また上のような解釈をしているので，私の場合 C++ 流の int* i; のような書き方は気持ち悪くて仕方ないです．

>void (*po[])()
を
int* (*po[])()
としてみると、
・(*po[])() は、int*である
以下、void→int*で置換して終了。

うむ、応用が効きそうだ、とか言ってみる。

この場合逆に
int *(*po[])()
と書いたら最初の「*」がどちらに付くか迷いそうな気もしないでもない。

けど
int (*p)[5];
のような場合は int* だと書けないっぽいね。

＃void func(int **p); int a[5][10]; func(a);
＃の間違いが分からなければもう一度プログラミング言語Cをやり直し！

以下の C++ における char* p; なコードは、char *p; 派としてはどのように書くと一番しっくり来ますか?

const char* const str = "ABC"; // 当然 const char const *str とは書けません

C++ は char *p; より char* p; だと思いますよ。

「pはポインタである」が真っ先に関連づけられることから、*pと書くのが理にかなっていると思うのですが。

話はそれますが、WindowsのAPIでよく現れるような、LPDWORD p;の様な、わざとポインタを隠蔽するような書き方は、愚の骨頂だと思うです。

別にポインタを特別視はしていません。

「pはポインタである」→ *p
「*pはintである」→ int *p

と読み下せます。（と多くの方が同様な主張をされていると思います）

同じ理屈で、

「funcはポインタである」→ *func
「*funcは関数である」→ (*func)()
「(*func)()はintを引数にとる」→ (*func)(int)
「(*func)(int)は結果を返さない」→ void (*func)(int)
故に、funcはintを引数にとり、結果を返さない、関数へのポインタである。

のように自然に読み下せます。

だから、*と変数名はつながっていないと、様々な型宣言で破綻します。

いっそのこと、複数の変数をまとめて宣言できるってのを廃止するってのは？
int a;
char b;
int* c;
char* d;
としか書けなくすれば万事解決です。

「深い」って「判りにくい」の別名だと思うので、あんまりプログラミング言語に積極的に求められる性質ではなく、肯定的に捉えられる性質でもないんじゃないかなと思います。
特に、その時代の技術では代替の効きにくい重要必須なコンセプトやメカニズムならともかく、単なる構文的な判りにくさにはあまり入れ込むのはどうかなーと。
ポインタ型の観念や機構は重要だろうけど構文はそれに比べてそれほど重要でないんじゃないかと思います。

それでもCぐらいだと構文の瑕疵まで含めて完全に理解しようと思えばできなくはないのでしょうが、C++あたり使ってると「ギリギリまで使い切れる完全な理解に基づいて書く」ではなくて「より限定的だけど読みやすく、瑕疵には触れず安全目な理解の範囲で書く」へと段々割り切りがｗ
（で、ギリギリのことをしなければならない羽目に陥ったらそのときはあきらめてリファレンスを読み直す。)
まぁ、「C実践プログラミング」本とか「MISRA C」規約的な方向性ですね。（とはいえ私個人はそこまでストイックではないですが。）

10数年ほど昔、私が大学生の頃、教わった先生の一人がPL/I大好きの大型機Loveのヒトで「アンチ石田」だって公言してたなぁ。彼の目の黒いうちは計算機センターにUNIXは入らないとも。

･･･しかしそのたった数年後、彼の目がどころか髪さえも黒いうちにUNIXが動くマシンがセンターに現れたのだった。

それが昨今ではUNIXどころかWindowsが動こうかという･･･
（「メインフレームでWindowsが動く「z/VOS」」
  http://slashdot.jp/article.pl?sid=09/03/06/0133248 [slashdot.jp]）

関数型言語は嫌いですといいながら入院した先生の代打でLISPを教え、prog形式に妙に時間を割いていたあのセンセイは今頃どうしてるかなぁ。

うちの大学ができる時に文科省に「40代後半くらいのインターネットに詳しいデータ通信の専門家のを用意できんのか？」と言われて困ったそうだし。1950年代生まれの通信屋はみんな電話のひとばかり。『それって村井先生を連れて来いってのとほぼ同義だよなー。(2000年の時点で)40代後半のインターネットの専門家の研究者なんて他に居ないし。無理難題言われても困るよな～』なんて言ってた。