Ognacの雑感

木漏れ日々

目次

Blog 利用状況

書庫

ギャラリ

本物の基準とは

頂いたコメントの中に「cの使い手の中には、他言語使いを軽視する。人がいる。」と解釈できる文がありました。
同意できる部分をあるので、なんでだろう。と思ったのです。
「人は平等である」と建前で言っていても、上下関係を築いて保身に走ろうとする弱い面がありますね。
福田首相の「あなたとは違う」発言は顰蹙を買ってますが、自分に選民意識があることを露呈しましたね。
個人の得意分野と不得意分野と比べたら、不得意分野が圧倒的に大きいものです。「私はできるんだ」と言ったところで、「極小の部分で優秀なだけ」に過ぎません。
開発者等のプロ得意分野ので勝負するのは当然な事ですが、得意分野か優秀だからといって、「不得意分野の人の評価を低く見る」のは意識が幼いと思うのです。自分ができないことを出来る人には敬意を払いたいものです。
そうしないのは、差別意識に通じるものを感じます。本物だけがすべてと考えている節を感じます。しかし、本物って何でしょう。何を持って本物と定義しているのか聞いてみたいものです。

・ブランド品が本物と主張する人
  ・コーヒーは「ブルマン」より「キリマン」だ。
  ・米は「ささにしき」より「コシヒカリ」だ。
  ・肉はグラム1000円以上でなくちゃダメだ。
  ・ウナギは国産に限る。
  利き酒テストしたらボロボロになるので、あちこちの番組で取り上げられてネタになってます。
  「似非本物指向者」と呼んでます。
・ブランドにこだわらず、自分の味覚、眼力で本物と確証する人で且つ、他の存在も同等に評価する人。
・自分の味覚、眼力で本物と確証するが、それが唯一で、他は「ダメ」とする人。
うーん。寛大さというか、  人間性がでるのでしょうね。技術力以前の問題だと思うのですが。
C関係の知識は、プロである開発者は、知って欲しい、という思いは私もありますが、必要とは考えません。「知った方が造詣が深まるよ」程度です。
職業プログラマでも、OSや言語自体が好きな人や、単なる道具と認識している人もいます。
業務アプリ開発者の何割かは、仕事関係の開発スキル以上を望まない傾向があります。それでも職業としては仕事は成立します。会社も本人も不満が無ければ、他人がとやかく言える問題ではありません。その人たちに、「c」はとか、「ポインター」とかを説いても、ピント外れな感がします。
 必要な技術は、必要な場所で発揮します。不釣り合いな場所に優秀でも不用な技術を持ってきても困ります。

自分の知識が本物で、新技術は否定する人も類型かも知れません。こちらの人は結構いますが、良さが解れば、変節するので害にはならないでしょう。
・パソコンが登場してきたときは、汎用機系の人は、「こんなのはおもちゃに過ぎない」と酷評してました。
・電子レンジが出てきたときは、「そんな安直なものは調理器ではない」
・乾燥機がでてきたときは、「主婦の手抜きを助長する悪しき道具だ」
・デジカメがでてきたときは、「おもちゃだ、スティールカメラは不滅だ」
・オートマチック車がでてきたときは「ミッション操作ができないと、運転者としては致命傷だ」
 その他多し
いずれも、登場した製品が席捲しているのは周知の通りです。
否定してたことを忘れて、恩恵に預かっているのでかわいいものです。中には否定していたことを否定する人もいます。
「本物」というモノは存在しないのかもしれません。

投稿日時 : 2008年9月8日 0:08

Feedback

# re: 本物の基準とは 2008/09/08 5:04 れい

うーん…?
珍しく文章があちこち飛びすぎな印象を受けました。

本物は何か、という話。

新しいものがなかなか受け入れられない話。

自分が他人より優れている、と思いたがる人間の習性の話。

一部のC使いの傲慢さについての話。

Ognacさんの中では「本物」というキーワードを持つ関連した話なのだと思いますが、私にはよくわかりませんでした。
いつか暇があったらもう少しわかりやすく説明してくれたらうれしいです。

# re: 本物の基準とは 2008/09/08 8:37 裏口

れいさん>そうかなあ。私はわかりやすいと思います。
多分、多少アルコールが入った状態で書かれたんだと思いますよ。
# 自分も酔ってると論点が飛びまくるしねえw

>・パソコンが登場してきたときは、汎用機系の人は、「こんなのはおもちゃに過ぎない

私もその一人。
でも今ではマルチタスクどころかマルチCPUが標準なところまで来て完全に逆転してるしw

# 個人的には「本物」の話ではなく「本物に対する感性」の
# 話だと思いましたけど。

# re: 本物の基準とは 2008/09/08 13:38 Ognac

>Ognacさんの中では「本物」というキーワードを持つ関連した話なのだと思いますが、私にはよくわかりませんでした。
>れいさん>そうかなあ。私はわかりやすいと思います。
>多分、多少アルコールが入った状態で書かれたんだと思いますよ。
補足、痛み入ります。ありがとうございます。。

>個人的には「本物」の話ではなく「本物に対する感性」の 話だと思いましたけど。
個々人で、「本物」の定義がことなるし、永遠不変の物と考えている人も居れば、優れたものが現れたら、本物像を置換する人もいます。
これが「本物だ」と主張したところで、個人の思い入れの範囲を出ないね...... という視点で書きました。 私のなかでは、話は飛んでないのですが、
受け取られ方が二分しましたね。(サンプルが2例ですが。 話題の列挙の仕方なんでしょうか、年台の差なんでしょうか解りません。裏口さんとは、同年代が幸いして、通じたのかなぁ。
 個々のケースを考えても、エントリーできそうなので、後日起してみます。

# re: 本物の基準とは 2008/09/08 15:11 みきぬ

> 福田首相の「あなたとは違う」発言は顰蹙を買ってますが、自分に選民意識があることを露呈しましたね。

すみません。ここで読むのをやめました。

# re: 本物の基準とは 2008/09/08 17:37 uskz

上に同じ

# re: 本物の基準とは 2008/09/08 17:44 Ognac

>すみません。ここで読むのをやめました。
>上に同じ

う! 何か不快感を与える、若しくは誤解を生む記述がありましたでしょうか。私は気付いてません。
良ければ、御指摘頂ければ幸いです。

# re: 本物の基準とは 2008/09/08 19:30 Pasie.

私もよく分からなかったのですが一言。
> C関係の知識は、プロである開発者は、知って欲しい、という思いは私もありますが、必要とは考えません。「知った方が造詣が深まるよ」程度です。
 あえて過剰反応しますが、結局C至上主義ですよね。造詣が深まると言うだけであれば、アセンブラだって他の言語だって、非言語だっていいはずです。
 にもかかわらずなぜCなのでしょう?C以外に勧めるべき言語は見あたらないのでしょうか?それともいろいろな言語を見た結果、やはりCなのでしょうか?仮にそうだとしても、C関係の知識とは現在のC(C++含む)と古典のC(K&R)は(極論ですが)別物だと思いますが、どちらを指しているのでしょう?そういった面をすべて考慮にいれて、C関係の知識は知って欲しい、と述べているのでしょうか?
 しかし私にはそういった考慮の結果ではなく、Cerが単に自分たちがもつ知識こそ必要かつ本物であり、他はそれに倣うべきだ、と吠えているだけなのではないでしょうか?そしてそういう態度を選民的というのだと思いますが…

# re: 本物の基準とは 2008/09/08 19:51 Ognac

>私もよく分からなかったのですが一言。
顔あらってでなおしてこようっと。

>C関係の知識は知って欲しい、
・高級なアセンブラとして、CPUの動きが理解しやすいので、CPUからみた、メモリの使い方が見える。
・相対アドレスと型によるアロケーションが理解できる。
・関数ポインタの原理が直感できる
・アルゴリズムの教科書が豊富....最近はJAVA系も豊富ですが....(CやJAVAを知らない人は読もうともしない現実)
等の理由で、知って欲しいな.........程度てす。「知ってどうする」的な世界ではありますが。

>Cerが単に自分たちがもつ知識こそ必要かつ本物であり、他はそれに倣うべきだ、...選民的というのだと思いますが…
そうだとしたら、偏狭すぎますよね。対峙位置にある VBerも違う面で偏狭感がありますが。  
プログラマは言語に左右されるな....が何故通じないのだろう。

# re: 本物の基準とは 2008/09/08 20:46 Pasie.

あえて言おう、不要であると(極論-_-;)

>・高級なアセンブラとして、CPUの動きが理解しやすいので、CPUからみた、メモリの使い方が見える。
 多くの場合、必要ありません。
 CPU回りで言う場合、レジスタやスーパーパイプラインやキャッシュの動きを意識したりしないのと同じように、使用する言語の範囲でメモリ管理のあり方を知ればいいのであって、それがCを知ることで解決できるとは思いません。
>・相対アドレスと型によるアロケーションが理解できる。
 同上
>・関数ポインタの原理が直感できる
 必要ですか?
 (.net系の場合)ポリモフィズムとかイベントとかデリゲートとかあるわけで、関数ポインタを"関数ポインタとして"あえて理解する必要はない気もします。

>・アルゴリズムの教科書が豊富....
 かつてはpascal記述とかありましたが、最近はjavaが多い気が。ところでjavaの文書をCerは積極的に読んだりするんでしょうか。読まないような気がする…
 そもそも最近はアルゴリズム辞典の内容はライブラリ化されているから必要がないという意見も耳にしますが…

> VBerも違う面で偏狭感
 偏狭ですか?Cerに比べれば知ったかぶりは少ない気がします。だって純粋にしらない場合が多いんですもん…

>プログラマは言語に左右されるな....
 極論だと思います。
 ボールペンで字が書けるからといって毛筆で字が書けないのと同じです。同じ文字を書く場合でも基本が違う場合があったりします。
 もしも言語非依存の知識として知っておくべき事だと言いたいのであれば、それは特定の言語に絡ませて話すべきではないと思います。(もっとも動物を継承して犬と猫ができる、みたいなのは勘弁して欲しいところですが)

# re: 本物の基準とは 2008/09/08 21:54 Ognac

>あえて言おう、不要であると(極論-_-;)
極論でしょうが、説得力ありますねぇ。......小声で反論.....

>言語の範囲でメモリ管理のあり方を知ればいいのであって、それがCを知ることで解決できるとは思いません。
Cでは解決しませんがもしれませんが、メモリ管理が見やすい言語は限られれるのでは、JAVA/VBでも知るほうが良いが、見えにくい感じがします。


>>・関数ポインタの原理が直感できる
> 必要ですか?
知っている方が、 OOPの実展開展開か想像しやすくありませんか?......だからどうした...の問題なのですが。

>読まないような気がする…
結局読まないのかぁ。

>偏狭ですか?Cerに比べれば知ったかぶりは少ない気がします。だって純粋にしらない場合が多いんですもん…
大きな問題だと想うのですが、当のVBerはそう感じていないものねぇ。

>同じ文字を書く場合でも基本が違う場合があった
言語不問は言い過ぎです。修正します。コボル/Fortran/RPG/C ETC,,言語文化は確かにあります。
しかし、CLI下では、 VBもC# も同一に見えませんか。  VBerが C#を読もうとしないのが解らない。C#erはVBソースを読もうとするのに........

知らなくても良いことだが、知った方が有利....でもないか...「楽しいよ」ですね。不要と結論づけるの少しだけ引っかかります。。

一部のCerは自分しか見えないってことなのかなぁ。

うん! 私は何を主張してたんだっけ?....ずれてきたような。......人によって信じるものが本物であって、本物は不変ではない..... 変化と他人を認めよ..........

# re: 本物の基準とは 2008/09/08 23:14 Pasie.

>JAVA/VBでも知るほうが良いが、見えにくい感じがします。
 私はオブジェクト指向についてはc++ではなくjavaで理解したこともあり、c++ではなくjavaとかで習得した方がよいと思っています。主な理由はImplementsの有り無しですが。インターフェイスの概念が多重継承なC++erに通じなかったのが痛い経験として記録されています。-_-;
 あとメモリを知りたいならC以前にアセンブラをお勧めします。特にバイトオーダーとか他機種との通信では必須の知識ですが、Cerでも割と知らない人がいます。

>知っている方が、 OOPの実展開展開か想像しやすくありませんか?
 実装展開を理解する必然性はないような…
 Cでも引数のスタックの積み方とか、A+++++bがなぜ解釈できないかとか知る必要はないと思いません?(当然理解すべきと言われたら困るが…^_^;)

>しかし、CLI下では、 VBもC# も同一に見えませんか。
 同一に見えないことにしています。x86で動く言語がすべて同一に見えないのと同じように。

>VBerが C#を読もうとしないのが解らない。C#erはVBソースを読もうとするのに........
 それは局地的な話ではないかなあ>C#erがVBを読む
 VBerでCやC#読む人もいますよ。

>「楽しいよ」ですね
 そうですね。知っているとそれだけで楽しいですからね。
 なんで酒の席ではVBerでCを知らない人にヒープの概念を伝えるのに云々、とか言う話は結構しますが、その話の最後は、人によってベースや関心事は違うんだから、伝える方法を考えないといけないんだろうね、自分たちが知っていることは知っていて当然だって態度だと平行線だよね、ってことでオチます-_-;

# re: 本物の基準とは 2008/09/09 0:31 Ognac

>インターフェイスの概念が多重継承なC++erに通じなかったのが痛い経験として記録されています。-_-;
私は、C++から入ったので、「多重継承ができる」前提がなかなか抜けなかったです。
>あとメモリを知りたいならC以前にアセンブラをお勧めします。
アセンブラも、汎用機系(S/360系)とインテル系/モトローラ系そのたCPU毎に異なるので、面白いのですが、仕事にするにはチト辛いのが本音。Z80系の裏レジが好きだったし、68系が好き..インテル系のL/H逆転が未だに嫌い......のは内緒です。
>Cでも引数のスタックの積み方とか、A+++++bがなぜ解釈できないかとか知る必要はないと思いません?
必要はありませんが、興味深いです....ってマニアの世界の話になるのかなぁ。

>同一に見えないことにしています。x86で動く言語がすべて同一に見えないのと同じように。
同一視しますね。しかし、一部言語固有の構文があり、C#が優位に見えますが。

>それは局地的な話ではないかなあ>C#erがVBを読む
プロジェクト依存というか、確保した要員依存かな。

>知っていることは知っていて当然だって態度だと平行線だよね、ってことでオチます-_-
伝える事の難しさ。しかし、伝えないと前進しないし...

# re: 本物の基準とは 2008/09/09 12:56 みきぬ

※注:uskzさんと、理由まで同じかどうかはわかりません。

> う! 何か不快感を与える、若しくは誤解を生む記述がありましたでしょうか。私は気付いてません。
> 良ければ、御指摘頂ければ幸いです。
>
ただ福田首相を叩きたくて、例になってないものをわざわざ持ち出してきたように見えました。

# re: 本物の基準とは 2008/09/09 13:34 Pasie.

>同一視しますね。しかし、一部言語固有の構文があり、C#が優位に見えますが。
 こういうちょっとした優越感(?)が蔑視的(?)になっていくのではないかなあと。
 そもそもVBとC#が現在は似た位置にいたとしても、今後も類似して進化していくと決定しているわけではないのだから、同じ物だと思わない方がよいと思っています。
 同じ物だとおもった瞬間に、VB≒C#、VB≦C#(Cer視点)、∴C#上等、VBくだらねえ。みたいな論議になりやすいです。

# re: 本物の基準とは 2008/09/09 14:09 Ognac

>こういうちょっとした優越感(?)が蔑視的(?)になっていくのではないかなあと。
うーん。潜在的にその思いがあるのかなぁ。VBシンパなんですけどねぇ。
VB6文化を継承した構文・文法があるぶん、OOP開発では、C#が向いているかなぁ。っと......向き・不向きで言及すべきでしたね。優位の表現は不適切....でしたね。
匿名Delete/Yeield文が好きなんですが、それは。優れているわけではないが、VBに比べて便利機能?....表現に窮します...orz;

>同じ物だとおもった瞬間に、VB≒C#、VB≦C#(Cer視点)、∴C#上等、VBくだらねえ。みたいな論議になりやすいです。
深いい話です。区別意識の根源の気がします。

>ただ福田首相を叩きたくて、例になってないものをわざわざ持ち出してきたように見えました。
タイミングよく、「君たち..」発言があったので、引き合いにだしただけで.....はなしの骨子に無関係な引用は良くないですね。
>例になってないもの
 書いて読み返した時は、例になっていたのに....<=-言い訳は見苦しい
今回は、話の運びがボロボロでした。

# re: 本物の基準とは 2008/09/09 17:05 Pasie.

>VB6文化を継承した構文・文法があるぶん、OOP開発では、C#が向いているかなぁ。っと
 ちょっと納得いかないので追加で質問。
 C++は多重継承が使えて、C#は使えないですよね。OOP開発で適しているのはどっち?
 delegateの使えるC#と使えないjavaではどっちがOOP開発に適してる?
 もう少し平たくすると、構造化プログラミングをするのに、Cと(構造化)Fortranと(構造化)Basic、どれが一番適してる?
 私にはどうしても一連の発言がC#を持ち上げるために、その理由になるようなものを拾ってきているようにしか読めないのです。今回はラムダ式を挙げていますが、もしこれが.vs2002の頃なら、オペレータオーバーロードあたりをあげていたのかなあと邪推してしまうのです。

# re: 本物の基準とは 2008/09/09 19:18 Ognac

>C++は多重継承が使えて、C#は使えないですよね。OOP開発で適しているのはどっち?
面白く組めるがトリッキーになりがちなC++。見通しよく、保守性やビジネス的にはC# 、同列でVBでは。

>delegateの使えるC#と使えないjavaではどっちがOOP開発に適してる?
Delegate好きなのですが、 純OOP開発でみれば、JAVAでしょう。
OOPの学習にはJAVA系の解説書が適していると思ってます。言語面に囚われずに書かれてるの多いですね。

>構造化プログラミングをするのに、Cと(構造化)Fortranと(構造化)Basic、どれが一番適してる?
1.Basic 2.Fortran( 今のFortranを知らないのですが) 3.C になるかなぁ。


>私にはどうしても一連の発言がC#を持ち上げるために、その理由になるようなものを拾ってきているようにしか読めないのです。
VB/C#/JAVAは背景や製品戦略が異なるので、出来る出来ないの比較自体無意味で、ましてや、優劣云々のものではありません。
解っていながら、そのような印象を与えたのは何故か....自問してみたら....
c#にあり、VBには実装されてない構文や機能を羨ましく眺めていました。OOP一辺倒になり、非OOP要素の多いVB構文を煙たがっている自分がいました。OOPがすべてではないのにね。
そこに、偏見の余地があった気がします。危ない危ない。Pasieさんありがとうございます。

私の発言にスッキリ感がないのは、開発者のスキル問題と言語仕様問題の区別がアヤフヤだった事に気付きました。道具を的確に使い分けるのは使用者の能力だと言っておきながら、道具に責任転嫁しようとしてましたね。
VBに関しては、自由度が高い分、VBの方が、スキルを要すると考えています。....ってこれも、差別視線になるのかなぁ。「開発者のスキル意識」という平凡なオチでいいのだろうか。我々がもっと啓発すべきでしょうね。....これは上から目線?

# re: 本物の基準とは 2008/09/09 23:36 Pasie.

 自由度が高い分スキルを要求される、というのはまさにCやアセンブラに当てはまる話なので、間違いはないと思います。C#よりVBが自由度が高いかどうかは?と思いますが。
 啓発というよりはより、よくなる方向を模索するつもりのほうがよいのかもしれません。弱気ですが -_-;

 あと蛇足ですが、私はOOPは手段だと思っているので別に非OOP構文が多いことについて不満じゃありません。むしろ利点だと思っています。delegateをJAVAerが蛇蝎のごとく嫌っても"ほめられたと思っておこう"です。^_^; Linqやラムダ式も同様。
 制限されることが美しいなら、まずは変数名を8文字までにしろと叫びたいです。あとOOPもSP(構造化プログラミング構文)も禁止。ええ。あの時代に戻りましょう。(つーかそういうのも今現時点で保守してんだよ。たすけてくれよって感じ T_T)でも、そうなったら猛烈に嫌ですが。-_-;
 自由度が広いと保守するのに困るじゃないか。と言われれば、保守するメンバーでよりよい規約を策定すればよいだけです。別に言語仕様で縛る事なんてないと思ってます。
 そして私はプロジェクトが複数言語から構成できるようになって、VBのサブルーチンから、Perl記述のクラスのメソッドを呼んで正規表現回りの文字列処理をして、その結果を戻しVBで処理を続けられる日が来ることを願ってやみません。マイクロソフトさん、是非クラスシート毎に使う言語を選択できるようにしてくださいよ-_-;
 ところで、perlの while(<>){print;} ってかける柔軟性は行き過ぎです。業務では絶対禁止!と思いますが言語仕様でしばって欲しいとは思わないです。

 長文とりとめもなく失礼しました。

# re: 本物の基準とは 2008/09/10 1:06 Ognac

自由度の解釈も微妙に違うのかな。人それぞれですね。
OOPが手段というのは同意です。非OOPが向いている分野もあります。それにVBが向くか否かは別として。
JAVAerさんも、頑なにならないで欲しいです。
Perlの簡略差は極端まで要ってます。昔1行プログラムがはやりましたが、それ上回る短さ。可読性を犠牲にする価値があるのか疑問です。

# re: 本物の基準とは 2008/09/10 9:54 れい

Cerはこう言うとか、VBerはこういう傾向にあるとか、C#erはXXとか…

人をたくさん見てきた経験があるという見方もできますが、その分偏見に満ちてるという見方もできますよねぇ。

そーゆー話はどこまで語っても「アルアル!」とか「それはあなたが思ってるだけ」とか、その程度で終わっちゃうような気がしますが。

と、自分以外のプログラマが近くにいない私が僻んで見ました。
自分が何erなのかもよくわかりません。

> ところで、perlの while(<>){print;} ってかける柔軟性は行き過ぎです。

普通ですよ。無いと困ります。
禁止されたら泣きます。

> 可読性を犠牲にする価値があるのか疑問です。

「読める人には簡単に読める」のです。
一見さんお断りというやつで。

だからって、先斗町を潰せって、誰もいわないでしょう?

# re: 本物の基準とは 2008/09/10 11:42 Ognac

>そーゆー話はどこまで語っても「アルアル!」とか「それはあなたが思ってるだけ」とか、
井戸端会議の域を出ないってことですよね。

>自分以外のプログラマが近くにいない私が僻んで見ました。
意外! 勝手に、開発者集団のリーダー格だと想像してました。人は見かけ(文調?)では判断できませんね。

>「読める人には簡単に読める」のです。
>一見さんお断りというやつで。
「ForLoopの挙動は、VBとC#では異なる 」のRe.に書いたのですが、業務アプリでは「タブー」とされてますね。
職人意識との妥協点が求められる局面です。

>先斗町を潰せって、誰もいわないでしょう?
面白いテーマ。ありがとうございます。1本書きたくなりました。

# re: 本物の基準とは 2008/09/10 18:30 Pasie.

>「読める人には簡単に読める」のです。
 読める人には簡単に読めればよいのです。
 自分すら読めないのはだめなだけです。-_-;

 あえて例に出しましたwhile(<>){print;}ですが、結局、$_がどこで変わるかをプログラム全域で見る必要があって、全体のバランスが崩れるとそれが元でバグりやすく原因がつかみにくい(特に他人が改造するとき)という問題があるね、ということが言いたかったことでしょうか。Cでもif () logic();ってやっているところに、if () Logic2(); logic()ってやっちゃったら終わっちゃうのと同じように。可能なら、if () {logic()} にしとこーよって話です。
 逆に、いわゆるjavaでいう30秒ルールに従っているなら、その点、なんでもありありだと思います。

# re: 本物の基準とは 2008/09/11 11:21 Ognac

>javaでいう30秒ルール
これ、マジで有効なんですか?、コードを理解するのに、時間で区切るというのが、理解できないです。
一目に解るとか、数回読み返せば解る.....でなく、30秒で判断するのはどうも....
1行でも{}が必要とか、簡略記法はダメとすると、Default Propertyが問題になりませんか?、一時的にカオス状態になりますが、徹底したら、完全記述のほうが良いような気がします。

# re: 本物の基準とは 2008/09/11 14:17 Pasie.

 うーん。杓子定規すぎます。別に隣でストップウォッチで計るわけではないのです。
 一目、数回読み返せば、30秒、みんな言っていることは同じです。
 一目といっても一瞬(0.1秒)コードを見せてさあ理解しろとか、4回目で理解出来ても3回以下(数回の範囲)で理解できなかったからだめだとか、そうはならないですよね。

 30秒ルール
 http://www.alles.or.jp/~torutk/oojava/codingStandard/javacodingstyle_c3.html#doc1_id480

# re: 本物の基準とは 2008/09/12 0:01 Ognac

>杓子定規すぎます
示された頁を読み、真意が解りました。表皮的でしたね。
この手の資料はJAVA系のほうが説得力を感じるのはなぜだろう。MS系の資料は、言語依存度が高いからかなぁ。
ただ、引っかかったのは、「理解可能な人が読む」ということですか。「理解できない人に対する解説はいかに」というと、話が振り出しに戻ってしまうので、止めますが。
くどくなりますが、非職人型開発者への啓蒙も、私たちの範疇だろうか、と思ってしまったエントリーでした。

# re: 本物の基準とは 2008/09/13 12:21 Pasie.

>非職人型開発者への啓蒙も、私たちの範疇だろうか
 その仕事が自分の責任なら、それも仕事の範疇でしょうね。
 もちろん教育するということだけでなく、(あらゆる意味で)あきらめるという選択肢も含めてですが。

タイトル
名前
Url
コメント