訃報：石田晴久氏逝去 117
ストーリー by kashibat-svt
お悔やみ 部門より
お悔やみ 部門より
あるAnonymous Coward 曰く、
日本のコンピュータ界、ネット界の先駆者であり、その礎を作られた石田晴久氏が本日午前7時に逝去されたそうです（サイバー大学のプレスリリース）。
書籍「プログラミング言語C」など、様々な書籍の翻訳者としても活躍され、その仕事のお世話になった方も多い(C使いならほぼ全員？)と思います。
思い出話を語りながら故人を偲ぶストーリーになればと思い、タレコミます。
石田先生と教育 (スコア:5, 参考になる)
このページ [hp.com]の左上の写真で、アラン･ケイ博士の後ろに写っているのが石田先生です。
これは日本HPのSqueakによる社会貢献活動を紹介した2004年のニュースリリースで、石田先生は会場に来賓としていらしていました(私はスタッフ)。当時は多摩美術大学のメディアセンター長を務められていましたが、Squeakを使った子供の教育に多大な関心を寄せられ、アランさんとも熱心に情報交換されていたのを覚えています。その後、情報デザイン学科の須永先生と共にSqueak Labの設立に尽力され、私も研究員として呼んでいただきました。Squeak Labではアートとコンピューティングを組み合わせた子供のためのワークショップを開催し、大きな成功を収めています。
サイバー大学設立の折には、打ち合わせ場所として使っておられた新宿中村屋に私を呼び出され、教養科目としてSqueakを使った講義 [cyber-u.ac.jp]を行うことを提案されました。サイバー大学には世界遺産学部とIT総合学部という異なった学部がありますが、どちらの学生も習得すべき基礎的なリテラシとして、プログラミングを取り入れたいとのお考えでした。
石田先生というとUNIXやC言語の印象が強いですが、パソコン黎明期にはTiny BASICやUCSD Pascalを紹介されており、現在もさまざまな言語や環境について研究されていました(先生が担当されていた「パソコンの歴史」と「コンピュータ進化論」 [cyber-u.ac.jp]は当時を知る上で大変興味深い内容です)。 先生からの最後のメールは日本におけるOLPC普及に関するもので、最後にお会いしたのはMIT Media LabでMindstormsやScratchを開発したミチェル・レズニック教授との会食の席でした。
入院の直前までSkypeを使っておられたという話もあり、いかにも先生らしいと思う一方で、もっとご自愛いただけていたらと思うと残念でなりません。
コンピュートないと (スコア:3, 興味深い)
Re:コンピュートないと (スコア:3, 参考になる)
お悔やみ申し上げます (スコア:2)
ちょっと難しかったけれど凄く参考になりました。
もうIT系の仕事はしていませんが、いまでも教科書は持っています。
いまから読み返して喪に服したいと思います。
書痴の森へようこそ。
ご冥福をお祈りいたします (スコア:2)
こんなところからで申し訳ございませんが、ご冥福をお祈り申し上げます。
お悔やみ申し上げます (スコア:2)
こういった方がまだご存命だったんですものね・・・
この業界まだまだ伸びしろがあるはずです。
ITに携わる人の数は爆発的に増えていますが、
我々の時代に、果たして先生の時代ほどの変化をもたらすことができるか・・・
身が引き締まる思いです。
ご冥福をお祈りします(-人-) (スコア:2)
当時、せいぜい X-BASIC くらいしか知らなかった自分にとって、最初は難しく思えてしばらくの間は積読状態になっていたものの、結局本棚に数ある本のなかでも特にこの1冊だけは手垢で真っ黒になってしまっており、特別な1冊であったことを物語っています。
思えばCを書くとき常に傍らにあった1冊であったわけで、座右の書、人生を変えた1冊と言っても過言ではないでしょう。
この場を借りて石田先生に感謝の気持を贈りたいと思います。
uxi
IPSJ-DSM研究会初代主査 (スコア:2, 興味深い)
「大学や企業の計算機システムなど大規模分散システムの構成技術や管理運営に関する研究発表の場を提供するため」 に、情報処理学会にDSM研究会がつくられた（1996年）のだけれど、その初代主査を務めていただいたのが石田先生でした。
実際、「定義があって補題があって定理があるものじゃなければ論文じゃない」みたいな雰囲気だったんだよ～。 DSM研究会（今ではIOT研究会）ができて、助かってます。
ご冥福をお祈りいたします。 (スコア:2)
私は、K&R 第一版でプログラミングを始めました。
自分でノートに整理しながら問題も全問トライして、プログラミングを学びました。
いまも、システム開発で生きていけているのは、あの本と格闘したからこそだと感謝しております。
ありがとうございました。
ご冥福をお祈りいたします。
K&Rは (スコア:1)
ご冥福をお祈りします。
/* pegiminh (aka .thx) */
卒論 (スコア:1)
きっと卒業できてなかったと思います。
本当にお世話になりました。いまだにお世話になっているようです．．．
# 木村泉先生のソフトウェア作法にも非常にお世話になりました。
# っていうか今も役に立ってます。
=^..^=
Enjoy Computing, Skiing, as much as Horse Racing.
日本のインターネットの祖父 (スコア:1, 興味深い)
Re:日本のインターネットの祖父 (スコア:5, 興味深い)
インターネット 歴史の一幕：JUNETの誕生 [nic.ad.jp]より
#ご冥福を心からお祈りいたします。
So long, (スコア:1)
「バイブル」とか呼んでた学生の時分、あの手の書籍はなかなか手が出なかったな…
UNIXプログラミング環境 (スコア:1)
ご冥福をお祈りいたします。
って、「UNIXプログラミング環境」買って全然読んでなかったorz
明日から読むかな？
Re:UNIXプログラミング環境 (スコア:2)
Re:UNIXプログラミング環境 (スコア:1)
「UNIXプログラミング環境」って確かガッコの教科書で使ったような...と思って探したら、石田先生が監訳されていたのですね。
あれにはお世話になりました。
石田先生の訳された本には、K&Rや独習C++などでプログラムの基礎を学ばせてもらいました。
心より御礼を申し上げるとともに、ご冥福をお祈りいたします。
こんなところでも (スコア:1)
嘘ニュースサイト「bogusnews」も哀悼の意 [bogusne.ws]を表しております。
……あのサイトなりのやり方で、ですが。
マイコンBASIC入門 (スコア:1, 興味深い)
大先生と知ったのはずいぶん後です。石田晴久というお名前は、明治の人が意味も
分からずに漢文を素読したように、僕の中では意味や偉さがよくわからなかった
1980年代初期のマイコン時代の著作者として「高橋はるみ」さんと同じフレームに、
セピア色の記憶のひとこまとして残っています。
大学でお顔を拝見しに理系の講義に潜り込んだのがいい思い出です。
石田先生、ありがとうございます。単位も何ももらってないけど、書店でも、図書館でも、
僕は「石田晴久」という著者名を見るといまでも「おお」と思って必ず手にします。
僕の人生のひとつの方向性を決定つけたという意味で、タイミング的に、K&Rよりも
先であり、上です。
上のほうでも書いている方がいらっしゃいましたが、そういう意味でも、ほんとうに
いい先生、啓蒙者だったと思います。誰かそういう思想史書かないかな。
私淑っていういい言葉があったのを思い出しました。
UNIX (スコア:0)
プログラミング言語C (スコア:0)
プログラミング言語Cといえば、ポインタの章が理解できずに何度も読みすぎてそのページだけ黒くなっていました。
ご逝去の報に接し、謹んで哀悼の意を表します。
Re:プログラミング言語C (スコア:2)
借りっぱなしで2版が出る頃には同じように黒ずんでました。
当時は(今も？)訳が読みづらいと評判でしたが、別に苦にならなかったなあ。
あれがなければこっちの世界に踏み込む事はなかっただろうと思います。
ありがとうございました。
Re:プログラミング言語C (スコア:1)
ありませんでした。謹んで先生のご冥福をお祈りいたします。
同世代的経験か・・・ (スコア:1)
私自身はPascalとModula-2とFortranの経験しかない段階で
Ver.2.1のWindowsからWindowsのプログラミング本だけを片手にイキナリC言語に入ってしまったので
メモリはリニアじゃなくて切れ切れだわ、ポインタじゃなくてハンドル（実体はポインタへのポインタだけど使用前にはロック必須）だわ、標準ライブラリは使えないわ、とひどい目にあいましたｗ
（とはいえ仕事じゃなくて学生が趣味でやってただけなので、ひどい目といっても知れてましたが。）
K&Rはそのずっと後、卒論・修論でC++をさんざん使った後に古典として読んだので、
世代的には「K&Rでプログラミングを覚えたぜ」世代の範囲内なのにこのトピックではあまり熱く語れないという…。
Re:プログラミング言語C (スコア:2, すばらしい洞察)
Cの前に、マシン語をやっていたので
多分同じようなもんだと思いますが、
int* i;
は私にはしっくりきましたよ。
Javaやってる人は
int[] i; // 配列型のiという変数
という書き方をするので、同意してもらえるかも。
変数名とその振る舞いは分離しておきたい、というだけです。
/* なんにせよ、ポインタ変数なのか、普通の変数なのかがよく分かるように
* 命名していれば混乱の問題は無いと思うんですが、
* a,b,i,j,kで使われる例ばっかりなのがよくないのかなぁ、と・・・
*/
Re:プログラミング言語C (スコア:1)
>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をやり直し！
Re:プログラミング言語C (スコア:1, 興味深い)
pint_t a, b, c;
…わかりやすいでないですか。
と、いうのは全然嘘です。
私もその書き方が気に入ってません。
int* i;
と書かなければ気が済まない人というのは、
「ポインターなのは型だろー、型は型として書かせてくれよ。」
って思ってる人たちなんです。
きっと型名にスペースを含んでいるのが許せない人達なんです。
または、* が型名に含まれていない事が我慢できない人達なんです。
そう思ってる人たちは決して、
int* i, *j, *k;
とは書かない/書けないみたいですね。
そんなに嫌なら、typedef しやがれですよ。> 各位
Re:プログラミング言語C (スコア:2)
考え方の１つにすぎませんが，型宣言でも数式解釈と同様に，両辺の型が釣り合っていると思えばわかりやすいかも知れません．
int *i;
は
int = *i; （この式はコンパイラに通りませんが概念的なものです）
というように両辺の型が釣り合う関係になっていて，アドレス（ポインタ） i が指す先の値にアクセスする演算子 * を付けたもの (*i) は，int 型でなければなりませんよ，という意味です．コンパイラの視点で言うと，代入式を解釈するときの左右の型の一致判定と同じロジックで変数宣言が出来ることになりますし，変数への演算子の付け方が許容されうる限り，それは変数宣言でも同じように使えることになります．
double (*a)[3];
とかでも同様に，左からでなく，最も内側（変数名の部分）の a から外向きに辿っていけば理解しやすいのではないでしょうか．
「a はポインタで，その指す先は３要素の配列で，その配列の各要素は double 型」であるということになりますから．
そう考えると，
型名 変数名;
という単純なとらえ方だけでなく，変数名を修飾することが変数宣言でなぜ利用できるのかが理解しやすいかも知れません．
また上のような解釈をしているので，私の場合 C++ 流の int* i; のような書き方は気持ち悪くて仕方ないです．
Re:プログラミング言語C (スコア:1)
> ...
> char (*(*f)())[10];
> f = ((*(*)())[5])g;
charが抜けてませんか?
f = (char(*(*)())[5])g;
でもって f がこの型で定義されているなら、
> (*(*f)())[5] = 'a';
は(*)が1つ多いですな。(多い分はOKなので問題ないですが)。
(*f())[5] = 'a';
でよいですよ。(理由は()演算子(関数呼出し演算子)は暗黙のうちのdereferenceをやるから。想像するに、K&Rの時代にfが関数ポインタのときに、(*f)()でなく、f()でOKとしていた仕様に合せたんでしょうね)
ただし、型宣言やキャストのときは暗黙のdereferenceはありませんから(*(*))のように2つ要ります。ご注意を。
多い分にはOKと言うのは、例えば
(*(*(*(*(*(*(*printf)))))))("Hello, world!\n");
とか
(******************printf)("Hello, world!\n");
というのがOKということです。興味のある人はHello worldのプログラムの一部をこれで置き換えてコンパイルしてみると良いでしょう。
> 非常に分かりやすいですね。
間違うくらいだし、あまり分かりやすいとは言えないですね。IOCCC読み慣れている身としては苦はないですが。
実際問題としてなら、私は
struct a { char data[5]; };
struct a *(*f)();
f = (struct a*(*)())g;
f()->data[5] = 'a';
のような感じにしますかね。たぶんこういうことしたい時って、あとから
struct a { char data[5]; int data2[5]; };
みたいに変えたくなるような気がしますし。
# 変数名やタグ名はこんなショボくしません。あくまで例ですので...。
Best regards, でぃーすけ
Re:プログラミング言語C (スコア:1)
なるほど! そういう考えをすればこの変なルールも納得できるかも。しかし、個人的にはK&Rの怠慢 -- 「(*)」を略したい -- をもとにANSIが矛盾しないルールを作った結果、1. 使用時はdereferenceは1個少なくするのが基本 2. 余計なdereferenceは許可、という変なルールが関数ポインタに関してだけ出来たと想像しています。
> 私は(*f)()と書くことが多いです。さすがに(*s->f)()は煩雑ですし関数ポインタであるのが明白なので書きませんが。
全員がそうであればよかった(K&Rと非互換だけどすっきりしたルールを作ってもよかった)のでしょうけど、不幸なことにK&Rと同じく怠慢な私のようなf()としか書かないやつらが蔓延してしまったので現在のルールになったのでしょう。
> ルールが分かりやすいという意味です。人間には厳しいですね。
概ねそうなんですが、関数ポインタだけはルールも変です。すくなくともコンパイラを実装する上では上記を理解していないと駄目です。
> 単項*演算子がPascalの^ように後置であれば、
Cには馴染まないですね。Cでの後置演算子と言えば、++と--の後置バージョンですが、2項演算子と区別するとしてポインタを**の後置とすると、
ポインタのポインタはp** **とか書く羽目になってよろしくないですね。
Best regards, でぃーすけ
Re:プログラミング言語C (スコア:1)
> 関数へのポインタの配列を返す関数
などの型が理解できない、という意味だと思っていたのですが、最近になって違うことが分かってきました。
それは置くとして、私は読む分には
int*i;
int *i;
int* i;
int * i;
どれでも一緒です。たぶん最後は私は書かないけど上の3つは気分によってどれも書くかも。
寧ろポインタ変数の名称がiであるのが少しだけ気持ち悪いかな(コメント主はそこは問題にしていないと思うけど)。
とはいいつつ、それもそこまで気にしないです。
int* i, *j, k[5];
とかでも平気です。
Best regards, でぃーすけ
Re:プログラミング言語C (スコア:2)
私の場合、Z80世代からパソコンをはじめて、今の本職はC++ですが、
int *p;
の書き方じゃないと落ち着きません。その変数がポインタであることが見た瞬間に理解できるような書き方をしたいので、*と変数名はつなげて書きたいです。
初期のCを飛ばして、C++やJavaから入った人だと、
int* p;
と書くようです。
そういう人は、 unsigned char* p; とか書くんでしょうか？
unsignedとcharの間にスペースが入っているのに、charと*の間が詰まってるのって、気持ち悪くないですかね？
こういうのを見る度に、こっそり書き直したくてそわそわします。しかし、バージョン管理システムに履歴が残ってしまうので、迂闊に書き直すわけにもいきません。まったく困ったものです。
Re:プログラミング言語C (スコア:1)
以下の C++ における char* p; なコードは、char *p; 派としてはどのように書くと一番しっくり来ますか?
C++ は char *p; より char* p; だと思いますよ。
Re:プログラミング言語C (スコア:2)
私は個人的にconstは後ろ寄りに書く習慣でやっていますので、
const char *p; ではなく、 char const *p; と書きます。
従って、 const char* const str = "ABC"; は、 char const *const str = "ABC"; になります。
まあ「*const」の部分はちょっと微妙なので、間にスペースを入れても入れなくてもいいかなと思います。
そんなわけで、やっぱり C++ でも char* p; より char *p; だと思いますよ。
Re:プログラミング言語C (スコア:1)
"const str" に * を付ける、という感じですか。なるほど。
しかし個人的には *const はかなり座りが悪い感じがするので、それならいっそ char * p; でいいようにも思えますね。
Re:プログラミング言語C (スコア:1)
「pはポインタである」が真っ先に関連づけられることから、*pと書くのが理にかなっていると思うのですが。
話はそれますが、WindowsのAPIでよく現れるような、LPDWORD p;の様な、わざとポインタを隠蔽するような書き方は、愚の骨頂だと思うです。
Re:プログラミング言語C (スコア:1, 興味深い)
の人は、pはint型を指す「ポインタ」だから、という感じだと思いますが、
C++でテンプレートだとか無名引数とか使うと、pはint型を指す「ポインタ型」と、
型全体に着目する事が増えるので int* pの方が自然に感じてくるだけです。
私にとっては
typedef Class1< int *, int * > IClass1;
より
typedef Class1< int*, int* > IClass1;
の方が、テンプレート引数の型が「int型を指すポインタ型」だとわかりやすいと
感じるので、変数の宣言にも同様のルールを当てはめるわけです。
ポインタ型の無名引数の場合も同様です。
あと、const int* const p = &a;
みたいな、constオブジェクトを指すconstなポインタは、*pな場合書き辛いってのもあります。
Re:プログラミング言語C (スコア:2)
いっそのこと、複数の変数をまとめて宣言できるってのを廃止するってのは？
int a;
char b;
int* c;
char* d;
としか書けなくすれば万事解決です。
Re:プログラミング言語C (スコア:1)
別にポインタを特別視はしていません。
「pはポインタである」→ *p
「*pはintである」→ int *p
と読み下せます。（と多くの方が同様な主張をされていると思います）
同じ理屈で、
「funcはポインタである」→ *func
「*funcは関数である」→ (*func)()
「(*func)()はintを引数にとる」→ (*func)(int)
「(*func)(int)は結果を返さない」→ void (*func)(int)
故に、funcはintを引数にとり、結果を返さない、関数へのポインタである。
のように自然に読み下せます。
だから、*と変数名はつながっていないと、様々な型宣言で破綻します。
Re:プログラミング言語C (スコア:1)
C言語の構文解析上は「int *p」も「int* p」も同じですから、
どっちで書くかは、文法の話ではなく「コーディングスタイル」の問題じゃないですかね。
まあ、スタイルの問題だからこそ、どちらも派閥も譲れないんだと思いますが
私は「int *p」と書く方ですが、そう書くようになったきっかけは「K&R で int *p と書かれていたから」です。
ちゃんと文法を知ってからは、「ポインタの * は右結合なので、*pとくっつける」と、スタイルの意味は理解しましたが、それは後付けです。
そういう構文解析が行われるからといって、「int* p」と書くことが文法違反になるわけじゃありませんし。
その後、 Stroustrup を読んで「int* p」と書く流儀の存在を知りましたが、あまりなじめず、
C++でも「int *p」と書くのを貫いてます。
#「ifやwhileなどの予約語の後(の間にはスペースを入れる」「関数とその後の(の間にはスペースは入れない」
#「ifやwhileと同じ行の終わりに { を入れる」など、基本的なコーディングスタイルはK&Rで通してるんですが、
#インデントが5タブなのだけは、さすがに真似できなかった…
Re:プログラミング言語C (スコア:1)
Re:プログラミング言語C (スコア:1)
「深い」って「判りにくい」の別名だと思うので、あんまりプログラミング言語に積極的に求められる性質ではなく、肯定的に捉えられる性質でもないんじゃないかなと思います。
特に、その時代の技術では代替の効きにくい重要必須なコンセプトやメカニズムならともかく、単なる構文的な判りにくさにはあまり入れ込むのはどうかなーと。
ポインタ型の観念や機構は重要だろうけど構文はそれに比べてそれほど重要でないんじゃないかと思います。
それでもCぐらいだと構文の瑕疵まで含めて完全に理解しようと思えばできなくはないのでしょうが、C++あたり使ってると「ギリギリまで使い切れる完全な理解に基づいて書く」ではなくて「より限定的だけど読みやすく、瑕疵には触れず安全目な理解の範囲で書く」へと段々割り切りがｗ
（で、ギリギリのことをしなければならない羽目に陥ったらそのときはあきらめてリファレンスを読み直す。)
まぁ、「C実践プログラミング」本とか「MISRA C」規約的な方向性ですね。（とはいえ私個人はそこまでストイックではないですが。）
Re:プログラミング言語C (スコア:1)
carとcdrが理解できずにポインタの道に進んだ人も多いのではないでしょうか？
OS/2 (スコア:0)
Re:朝日新聞の訃報 (スコア:1, 興味深い)
そういえばアンチな人が先生にいた (スコア:3, 興味深い)
10数年ほど昔、私が大学生の頃、教わった先生の一人がPL/I大好きの大型機Loveのヒトで「アンチ石田」だって公言してたなぁ。彼の目の黒いうちは計算機センターにUNIXは入らないとも。
･･･しかしそのたった数年後、彼の目がどころか髪さえも黒いうちにUNIXが動くマシンがセンターに現れたのだった。
それが昨今ではUNIXどころかWindowsが動こうかという･･･
（「メインフレームでWindowsが動く「z/VOS」」
http://srad.jp/article.pl?sid=09/03/06/0133248 [srad.jp]）
関数型言語は嫌いですといいながら入院した先生の代打でLISPを教え、prog形式に妙に時間を割いていたあのセンセイは今頃どうしてるかなぁ。
Re:朝日新聞の訃報 (スコア:1)
うちの大学ができる時に文科省に「40代後半くらいのインターネットに詳しいデータ通信の専門家のを用意できんのか？」と言われて困ったそうだし。1950年代生まれの通信屋はみんな電話のひとばかり。『それって村井先生を連れて来いってのとほぼ同義だよなー。(2000年の時点で)40代後半のインターネットの専門家の研究者なんて他に居ないし。無理難題言われても困るよな～』なんて言ってた。
Re:朝日新聞の訃報 (スコア:5, 参考になる)
日本のコンピュータ・サイエンスの先駆者
「ネット研究」っていうと、なんか、軽すぎる。
それに、インターネット絡みのものは研究者から指導者にクラスチェンジした後の業績だし・・・
Re:朝日新聞の訃報 (スコア:2, すばらしい洞察)
UNIXとかCとかインターネットとかオープン系（っていうのかな？）とかデファクト系？にちゃんと取り組んだ大学人としては先駆者に違いない。
Re:ご冥福をお祈りします (スコア:1, おもしろおかしい)
本物のプログラマーはパスカルを使わないのだよ。