議論をするならその対象を注意深く取り扱うべき
kwatch氏のやりとりを見ていて気づいたことがある。
kwatch氏は「本質的でない事柄」という表現をダブルスタンダードで使っている。
http://d.hatena.ne.jp/Nagise/20080504
と書いたが、どうも狙ってやっているというわけではなさそうだ。
kwatch氏の一連の発言からすると、kwatch氏は対象範囲の境界に無頓着と捉えるとよいようだ。
この部分は、Java屋*3に対する侮蔑でしかない。
http://d.hatena.ne.jp/Nagise/20080504侮辱ねえ・・・自分たちがCOBOLやPHPを侮辱していることには気づいてないらしい。
http://d.hatena.ne.jp/kwatch/20080505/1209963066
ここで重要なのは、私が「COBOLやPHPを侮辱」したわけではないことだ。
私はkwatch氏が何を主体として使っているのかは知らないが、例えばkwatch氏がPHP屋だったとして、kwatch氏への批判を理由に「これだからPHP屋は」というような拡大解釈をしただろうか？*1
しかし、kwatch氏はJava屋(私も含まれる)の中に「COBOLやPHPを侮辱」した人がいた(どこでとは聞かないが、たぶんそう言う発言をする人もいよう)ことをもって、Java屋全体が「COBOLやPHPを侮辱」していると解釈しているように思う。
だから、「COBOLやPHPを侮辱」していない私にそのような文句をつけてくると捉えると合点がいく。境界値に対して無頓着ゆえに、同一視しているという説が非常に説得力を持つことだろう*2。
Javaの一部の欠点をあげつらって、Java屋はこれらを問題にしない、と侮蔑するのは議論の妨げにかなるまい。Javaという複雑で精緻な言語にはいくらかの欠点も当然含まる。欠点があることをもってユーザが許容していることにはならない。論理の飛躍である。
http://d.hatena.ne.jp/Nagise/20080504いやいや、飛躍してるのはそちらですから。それに、ほんとうに許容していないなら『大規模開発で云々』という言い訳はしませんから。
http://d.hatena.ne.jp/kwatch/20080505/1209963066
この部分もそう。なぜかkwatch氏 VS Java屋という構造を想定して話している。別にJava屋っていう一枚岩の勢力があるでもなし。「そちら」って私個人？文脈的には「Java屋」だよね。私も「大規模開発で云々」とは言ったかもしれないが、それは「本質的でない事柄」の誤解に基づく発言だ。誤解に基づく発言をとりあげて、誤解でない事物に適用してどうする。「本質的でない事柄」に静的型の表記は含まれないことを理解した上で、アクセッサの記述に対して「大規模開発で云々」と言った人がいるだろうか？当然そんな奴はいないわけで、アクセッサの言い訳に「大規模開発で云々」なんてでっちあげもいいところだ。
「本質的でない事柄」を誤解した発言も、把握した上での発言もいっしょくたにして扱うから、把握した上で「大規模開発で云々」と言われているように誤解することになる。まずは、対象物を正確にカテゴライズするようにすべきだ。
対象物を適当に扱うから的外れな批判が多い。kwatch氏が自身で行った的外れな発言も、その後で再度使ったりするから余計に混乱する。誤解に基づく発言は議論の俎上から外さなければならない。
こうした、一部を見てそれに対する批判を、総体に向けて行うという「いわれのない批判」を続ける限り、主題とは関係のないところでの反発は絶えないことだろう。いわれのない侮辱を受けたなら、その対象に向かって文句を言えばいい。私に言われても困る*3。
進化の過程を追って、進化して困ったことを聞かれても…
Java における本質的でない記述がどのように大規模開発に役立つのか - kなんとかの日記での質問の仕方もおかしい。
さきのエントリで、私はkwatch氏が
本質的でない事柄に関する記述があったときに、スクリプト言語屋は「めんどくさい」と感じ、Java 屋はそれを感じないか、または「これは必要な冗長性だ」と本気で思い込んでいる。
http://d.hatena.ne.jp/kwatch/20080426/1209230638
と発言していることに対して、Java屋も当然そんなことは問題だと認識しているということについて述べた。
ところが、Java における本質的でない記述がどのように大規模開発に役立つのか - kなんとかの日記の設問は
というものだった。喧嘩を売っているとしか思えない。
他に矢野勉氏もkwatch氏に対して反応をしているが、Javaの欠陥部分については当然認めている。
むしろ、そこは欠陥じゃない！と主張するJava屋などいないことだろう。矢野氏のhttp://d.hatena.ne.jp/t_yano/20080503だってFileReaderにエンコード指定ができないことを釈明しているわけではなく、ストリームを多段に重ねなければいけない煩わしさに対しての考察だ。
曖昧な用語に基づいた質問だと誤解されると思ったので、アクセッサ定義、FileReaderでの文字コード、シンタックスシュガーの3つを具体例として使った質問をしたんですけど、それでもだめですか?
http://d.hatena.ne.jp/kwatch/20080505/1209963066
と言っているが、その点に対して、「欠陥じゃないと思うんでしょう、どうして欠陥じゃないかいってみな」なんて設問を立てるのは、具体的ではあるけども、設問の立て方としては間違っている*4。Java屋は当然ながらそうした欠陥を考慮しているし、それに対しても対策を考えているわけだ。そこを確認するのが本来の議論の流れだろう。その欠陥で得してんの？なんて設問を立ててどうする。
それは、PHPでパッケージが扱えなかった問題をPHP陣営が考慮し、対策を立てたのと同じだ。
- PHPでパッケージが扱えないことで開発にどう役に立っていますか？
なんて質問をわざわざやって喧嘩を売るようなことをしてどうするんだ。
いずれにせよ、これら3つの問いに対しては答えは出されている。Java屋はそれを欠陥だと知っているし、無関心でもない。なので、新たな論点がない限りはこの問いには触れる気はない。
Java屋の感性
ちょっとお尋ねしたいんですが、NagiseさんはJavaを日常的に使っていて、面倒と感じることはないですか。なければ結構ですが、もしありましたら思いつく限り列挙してみていただけますか。Javaの言語仕様だけでなく、ライブラリ、規格、フレームワーク、その他Javaに関することならなんでも結構です。もし列挙していただけたら、Java屋さんがどのようなことを面倒と思い、また思わないかというのが実に鮮明に分かり、ひいてはJava屋さんとそれ以外の人との考え方の違いがはっきりすると思います。
http://d.hatena.ne.jp/kwatch/20080505/1209963066
とリクエストされたわけだが、当然ながら網羅できないことをあらかじめ断っておく。そして、これは私の感性であってJava屋全体に共通するとは考えない方がいいだろう。
また、私の考察はようするにフレームワークを作る側の視点のものである点も注意されたい。
私が思うに、「一部のスペシャリストと多数の凡庸なプログラマで金を稼ぐ」というシステムにする必要があると考えている。
http://d.hatena.ne.jp/Nagise/20071128
などと述べるているように、私は職業プログラマが一律だとは考えていないし、システム設計ができるプログラマとできないプログラマがいる中で仕事をしなくてはいけない現状もそれなりに容認している。
エンジニアリングでは失敗をどう反省するかが重要だ
エンジニアリングというのは目的の達成のための研究過程では当然ながら失敗も発生する。そしてやってみなければ分からないという事項もたくさんあり、だからこそ各種実験が実施されるわけである。
提唱し、実験によって実践し、そしてそれを分析評価して、欠陥があればまたこれらを繰り返すのである。ここで実験するでもなく実例があればそれは貴重なサンプルとなる。サンプルがなければ実際に実験を実施なければならない。
JavaはOOPをシステム開発に浸透させた言語である。そうした中でpublicフィールドの問題もいろいろ具現化し実例を持って対策を考えることとなり、それはC#のプロパティとなっただろうし、Java7でのプロパティともなった。Javaが提唱し実験し評価して修正したわけだ*5。
publicフィールドというものの問題を洗い出せたという点で、Javaがなしたエンジニアリングとしての功績は大きいだろう*8
http://d.hatena.ne.jp/Nagise/20080504アハハ、これってどんな欠陥でも使える、言い換えのテクニックですね。
* 人権と武力弾圧というものの問題点を洗い出せたという点で、中国がなした国家としての功績は大きいだろう。
http://d.hatena.ne.jp/kwatch/20080505/1209963066
* 年金制度というものの問題点を洗い出せたという点で、社会保険庁がなした官公庁としての功績は大きいだろう。
* 本質的でない冗長な記述というものの問題点を洗い出せたという点で、kwatchがなしたプログラマーとしての功績は大きいだろう。
エンジニアリングとして功績があるのは提唱〜分析評価する側である。実験の部分を実例で補うことがあるが、実例の当事者が理論の提唱〜分析評価をするわけではないところがポイント。
中国の社会制度は当然、その手の学者の貴重なサンプルであろう。年金制度もサンプルとしては貴重である。そして、kwatch氏が罵倒交じりにJava屋全体を同一視してJava界隈では既知の問題点を指摘したら、本質的な議論以外でさんざん釈明することになったのも貴重なサンプルと言えよう。
このように、どのような欠陥をも功績と言い換えているわけではない。もちろん、どのような欠陥も他山の石としての価値はもつし、それを「失敗学」などと無駄にしないようにしようという試みもある。
エンジニアリングの過程としての実験は正否はともかくやってみることに意義があるし、失敗も想定にある。そして、失敗が想定される実験に対しては「うまく失敗すること」が理想的だ。「こういう風にしたらうまく動かないだろう」を実証するような実験などは狙ってうまく失敗させなければならない。
そうした目的を持たずになされた失敗はサンプル以上にはなりえない。チェルノブイリの事故は貴重なサンプルではあるが、あの事故が起きてよかったということにはならない。しかし、起きてしまった以上は単になかったことにするのではなく、貴重なサンプルとして生かすというのがエンジニアリングである。
*1:私が議論するときは対象を正確に捉えることに注意を払うようにしている。〜屋は、みたいな発言をするとしたら電球ジョークのような時だ。
*2:私は人の行動をプログラムのようなものとして捉えるが、工学的実用性からはほどほど成功している
*3:そして私はkwatch氏にJava屋と一括りにしていわれのない侮辱をうけたので何屋とかにではなく、実際の発言を行ったkwatch氏に苦言を呈している。ターゲットは逸れていないことだろう。
*4:いや、喧嘩を売るというのが目的なのなら成功していると言える:-P
*5:Javaのsetter,getterなんてのはpublicフィールドに対する置き換えの工夫で、1回目であるpublicフィールドの失敗を修正すべく行われた2回目の提唱に相当する。さらにC#のプロパティ構文が解として提唱され、そこで一定の成功を収めたと言えよう。
